Application zoom key

[shrop_pat]

Just downloaded V12 and updating my shuttle pro controller. Have looked through the key commands pdf but cannot find mention of a shortcut to zoom in/out.
Any ideas ?

[joeyluck]

It is not intended for that type of workflow. It could also be that they are also reserving key commands for zoom of individual elements, which would fit that workflow better.

That said, if you are on macOS, you can assign keyboard shortcuts for Reason via system preferences for any menu items.

[BananaSkins]

Just downloaded V12 and updating my shuttle pro controller. Have looked through the key commands pdf but cannot find mention of a shortcut to zoom in/out.
Any ideas ?

I’ve been looking at the ShuttlePRO v2 multimedia controller; as I now do a lot of video editing as well as audio work. Have you been using ShuttlePRO v2 with Reason and have you found it speeds up your work flow?

[Loque]

It is not intended for that type of workflow. It could also be that they are also reserving key commands for zoom of individual elements, which would fit that workflow better.

That said, if you are on macOS, you can assign keyboard shortcuts for Reason via system preferences for any menu items.

While i now had time to gamble around with the zoom, i noticed the following:
* i make the whole rack larber when editing, means mostly more than 1 device
* making it smaller when cabling or need an overview
* make it a bit smaller when i need the browser
* make it to 100% when in sequencer

So i find myself switching the size/zoom pretty often...

[joeyluck]

It is not intended for that type of workflow. It could also be that they are also reserving key commands for zoom of individual elements, which would fit that workflow better.

That said, if you are on macOS, you can assign keyboard shortcuts for Reason via system preferences for any menu items.

While i now had time to gamble around with the zoom, i noticed the following:
* i make the whole rack larber when editing, means mostly more than 1 device
* making it smaller when cabling or need an overview
* make it a bit smaller when i need the browser
* make it to 100% when in sequencer

So i find myself switching the size/zoom pretty often...

Yeah because it's not intended. What we need and will hopefully get will be something that isn't application wide zoom.

[shrop_pat]

Thanks for replies, I can see that having the ability to scale individual panels would be good but probably difficult. At present I am only using the shuttle for Premiere but will setup for Reason as well.

[Arrant]

Many of us are very disappointed with the way zoom is implemented at the moment.
But now you have me interested in the shuttle controller, care to share how that setup is working with Reason?

[shrop_pat]

Not setup yet, a bit distracted with other stuff. However I am sure someone else is using it with reason. Plenty of online vids about the controller (I am sure you have looked), any button can be mapped and there is the possibility of sub maps if you can handle it !. Centre dials are easy to setup, outside is spring loaded and can be set to "speed up/down" depending on position. Great for proportional control of playhead position. Top two rows can be annotated with small inserts if you use it primarily for a single application. More expensive than the mini version but the extra buttons and form factor are worth it. Control software a bit quirky but works well, application detects different programmes via link with appropriate .exe file and switches when a recognised program has focus.

[selig]

Many of us are very disappointed with the way zoom is implemented at the moment.

This feature's purpose could have been communicated better - the main request I've seen over the years was for an application wide zoom feature, since some folks could not read the small print on the UI with some high res monitors. That's the request this feature is addressing.
I don't see this as partial implementation, since it's in response to a specific and long running feature request - and there's no more features to be added (just fixing the bugs). It's intended, as I understand it, to be more of a set and forget thing, which isn't going to be able to be fully realized until Rack Zoom (or whatever it will be called) is introduced.
Rack Zoom is another matter all together IMO, as it would not make sense to be a global feature. I can imagine wanting to see the sequencer zoomed out and an effect or instrument zoomed in, both at the same time. It's also something, like Sequencer Zoom, that needs to be more dynamic, hence the need for a key command.
And I like to believe that's still in the works, though I don't see it on the road map (did I miss it?).

[guitfnky]

Many of us are very disappointed with the way zoom is implemented at the moment.

This feature's purpose could have been communicated better - the main request I've seen over the years was for an application wide zoom feature, since some folks could not read the small print on the UI with some high res monitors. That's the request this feature is addressing.
I don't see this as partial implementation, since it's in response to a specific and long running feature request - and there's no more features to be added (just fixing the bugs). It's intended, as I understand it, to be more of a set and forget thing, which isn't going to be able to be fully realized until Rack Zoom (or whatever it will be called) is introduced.
Rack Zoom is another matter all together IMO, as it would not make sense to be a global feature. I can imagine wanting to see the sequencer zoomed out and an effect or instrument zoomed in, both at the same time. It's also something, like Sequencer Zoom, that needs to be more dynamic, hence the need for a key command.
And I like to believe that's still in the works, though I don't see it on the road map (did I miss it?).

I’m curious where you’ve seen that. I’ve seen plenty of the hi res request posts over the years and I don’t recall any of them mentioning application-wide zoom, or having trouble with the size of the transport, for example.

yes, the complaints were about not being able to read the UI elements, which by definition depends on which part of the UI you’re talking about, in a piece of software like this. kind of bizarre to implement a global zoom setting without taking that into consideration, no?

[joeyluck]

Yes, this application zoom was an answer to HiDPI displays. It was for the most part, to resolve "pencil Reason."

While it wasn't a bullet point, they did mention in the roadmap post about improving the zoom.

[selig]

This feature's purpose could have been communicated better - the main request I've seen over the years was for an application wide zoom feature, since some folks could not read the small print on the UI with some high res monitors. That's the request this feature is addressing.
I don't see this as partial implementation, since it's in response to a specific and long running feature request - and there's no more features to be added (just fixing the bugs). It's intended, as I understand it, to be more of a set and forget thing, which isn't going to be able to be fully realized until Rack Zoom (or whatever it will be called) is introduced.
Rack Zoom is another matter all together IMO, as it would not make sense to be a global feature. I can imagine wanting to see the sequencer zoomed out and an effect or instrument zoomed in, both at the same time. It's also something, like Sequencer Zoom, that needs to be more dynamic, hence the need for a key command.
And I like to believe that's still in the works, though I don't see it on the road map (did I miss it?).

I’m curious where you’ve seen that. I’ve seen plenty of the hi res request posts over the years and I don’t recall any of them mentioning application-wide zoom, or having trouble with the size of the transport, for example.

yes, the complaints were about not being able to read the UI elements, which by definition depends on which part of the UI you’re talking about, in a piece of software like this. kind of bizarre to implement a global zoom setting without taking that into consideration, no?

I'm not sure what you mean about what is bizarre to implement.
I'm not suggesting folks were asking that specific of a solution, but I remember plenty of complaining when folks moved to a higher res monitor and suddenly everything in Reason shrunk. Seems pretty much like what I expected to see based on the complaints I heard. Meaning, it's a monitor resolution issue causing the problem across the entire app, so that's the level it should be addressed I would think.
In short, if the problem is the entire UI is shrinking, then the solution is to enlarge everything, no?

[superpop]

Many of us are very disappointed with the way zoom is implemented at the moment.
But now you have me interested in the shuttle controller, care to share how that setup is working with Reason?

Everything from PPH/RS is different. Since Record. Latency compensation, zoom, changing themes, HiRes, hyperthreading on?off?, one song is a monster file ...

[guitfnky]

I’m curious where you’ve seen that. I’ve seen plenty of the hi res request posts over the years and I don’t recall any of them mentioning application-wide zoom, or having trouble with the size of the transport, for example.

yes, the complaints were about not being able to read the UI elements, which by definition depends on which part of the UI you’re talking about, in a piece of software like this. kind of bizarre to implement a global zoom setting without taking that into consideration, no?

I'm not sure what you mean about what is bizarre to implement.
I'm not suggesting folks were asking that specific of a solution, but I remember plenty of complaining when folks moved to a higher res monitor and suddenly everything in Reason shrunk. Seems pretty much like what I expected to see based on the complaints I heard. Meaning, it's a monitor resolution issue causing the problem across the entire app, so that's the level it should be addressed I would think.
In short, if the problem is the entire UI is shrinking, then the solution is to enlarge everything, no?

no—that’s a ham-fisted approach to a complex issue. general complaints about not being able to see as well when using a hi DPI monitor don’t excuse the developers from recognizing there are different levels of readability depending on what part of the UI you’re looking at. the transport text is much larger than much of the text on devices in the Rack, for example. it takes no more than a 30 second look through the app to see there are different levels of readability throughout.

it’s like taking a customer service call about their internet not working and not asking clarifying questions—did you move your router? did your cat knock the modem into the fish tank? customers aren’t supposed to provide the solution, and any good customer support rep will tell you to NEVER take a customer’s explanation of what’s going on and how to fix it at face value. it’s the devs who are supposed to understand the problem and then come up with an appropriate solution.

moreover, the failure to implement that solution for more than one use case is, again, bizarre.

[guitfnky]

to give an example that will maybe make it more clear, the reason global zoom in Reason doesn’t work well, but it does in something like Ableton is, there’s consistency throughout all of Ableton’s UI, even in most third party Max 4 Live devices. there’s no such consistency in Reason. it therefore requires a different approach to implement well.

[selig]

I'm not sure what you mean about what is bizarre to implement.
I'm not suggesting folks were asking that specific of a solution, but I remember plenty of complaining when folks moved to a higher res monitor and suddenly everything in Reason shrunk. Seems pretty much like what I expected to see based on the complaints I heard. Meaning, it's a monitor resolution issue causing the problem across the entire app, so that's the level it should be addressed I would think.
In short, if the problem is the entire UI is shrinking, then the solution is to enlarge everything, no?

no—that’s a ham-fisted approach to a complex issue. general complaints about not being able to see as well when using a hi DPI monitor don’t excuse the developers from recognizing there are different levels of readability depending on what part of the UI you’re looking at. the transport text is much larger than much of the text on devices in the Rack, for example. it takes no more than a 30 second look through the app to see there are different levels of readability throughout.

it’s like taking a customer service call about their internet not working and not asking clarifying questions—did you move your router? did your cat knock the modem into the fish tank? customers aren’t supposed to provide the solution, and any good customer support rep will tell you to NEVER take a customer’s explanation of what’s going on and how to fix it at face value. it’s the devs who are supposed to understand the problem and then come up with an appropriate solution.

moreover, the failure to implement that solution for more than one use case is, again, bizarre.

Not sure where you're coming from here, are you suggesting different parts of the app should zoom automatically, or to give the user total control over each text block or groups of text blocks?
I'm assuming there's a zoom feature still in the pipeline, or at least in the wish list for a future version of Reason, I hardly think applicant zoom solves all the zoom issues as I've already mentioned. But without knowing what's coming I don't think I can say the current implementation was done poorly. Time will tell.
I also don't get the assumptions about the process used to decide how to implement this feature. I certainly have no private insight into this subject so can't comment on whether or not this was the case.
Seems we may be talking past each other...sorry if I'm not getting your points here.

[joeyluck]

This is what was said in the blog post about zoom. Take from it what you will...

"To put it in perspective, we estimate this investment was on par with building the whole RE-technology. There’s still room for improvement in how Reason handles application zooming, but it’s a huge leap for us to have this out".

I agree some things are disproportionate, but I find that to be more within the rack itself between devices and the freedom some RE devs have had.

That said, the "application zoom" is exactly that. While many of us definitely agree the transport (among other things like window bars) shouldn't be made larger, it would be inconsistent if the app zoom didn't handle all elements 1:1 and then there would be some users who would complain because "Why does the app zoom not affect everything? Why is it called application zoom?"

I'm hopeful that eventually we will have individual zoom for different elements, and then app zoom used on top of that would scale the app with those ratios intact.

[guitfnky]

no—that’s a ham-fisted approach to a complex issue. general complaints about not being able to see as well when using a hi DPI monitor don’t excuse the developers from recognizing there are different levels of readability depending on what part of the UI you’re looking at. the transport text is much larger than much of the text on devices in the Rack, for example. it takes no more than a 30 second look through the app to see there are different levels of readability throughout.

it’s like taking a customer service call about their internet not working and not asking clarifying questions—did you move your router? did your cat knock the modem into the fish tank? customers aren’t supposed to provide the solution, and any good customer support rep will tell you to NEVER take a customer’s explanation of what’s going on and how to fix it at face value. it’s the devs who are supposed to understand the problem and then come up with an appropriate solution.

moreover, the failure to implement that solution for more than one use case is, again, bizarre.

Not sure where you're coming from here, are you suggesting different parts of the app should zoom automatically, or to give the user total control over each text block or groups of text blocks?
I'm assuming there's a zoom feature still in the pipeline, or at least in the wish list for a future version of Reason, I hardly think applicant zoom solves all the zoom issues as I've already mentioned. But without knowing what's coming I don't think I can say the current implementation was done poorly. Time will tell.
I also don't get the assumptions about the process used to decide how to implement this feature. I certainly have no private insight into this subject so can't comment on whether or not this was the case.
Seems we may be talking past each other...sorry if I'm not getting your points here.

again, this is asking the customer to solve the problem--I'm not suggesting a solution, I'm suggesting an approach. complex problems require complex solutions, and the approach they took didn't fit the task. the fix they ended up with is a one-size-fits-all solution that doesn't actually fit the complex problem it should be solving (except in a single use case, where a user is upset that they can't read the entire UI).

is it an assumption that they didn't give a good deal of thought to the complexities involved? absolutely. as I see it though, there are two possibilities--1) my assumption--they didn't think it through well enough, or 2) they did, and decided it was okay to put out in its current extremely limited state. sure they may add it in the future--I hope they do, but I know I'm not alone in being tired of giving RS the benefit of the doubt when it comes to maybe getting the features we want down the line. I'm disappointed in what we have now, because what we have now is disappointing (IMO).

and I don't think the current implementation was done poorly--it works just fine--for a single use-case. it's not a good holistic solution though, for the wide variety of other use cases. the fact that many are upset with how it works is all the evidence we need to know that's the case.