Custom displays in high resolution

[orthodox]

One question comes up regarding the upcoming hi-res update.

Custom displays use a virtual coordinate system, which is usually chosen to match the current (low) resolution. It should scale without any problems. The display graphics, which mostly consists of line drawings would not look bad if blown up. But sometimes custom displays use a background picture, which is specified in the same virtual coordinates, i.e. in low resolution pixels, and it is sometimes deliberately made to align with the surrounding backgrounds. Now with the hi-res update, the regular background resources will look crisper, but the custom display backgrounds will remain low res.

I could of course start writing custom displays in new hi-res geometry, but wouldn't that affect the graphics performance in low resolution? As usual, there's not much we can do about it, but anyways, what do you think?

[pongasoft]

I have always wondered the same thing myself. As far as I know the SDK does not let you provide a hi-res image for custom display background, so until that happens, I am not sure what we can do...

[Billy+]

This is sounding like a potentially big problem for older no longer developed RE's - I thought that the RE SDK was supposed to deal with all and any of these issues before they were ever an issue.

From my limited understanding RE's are submitted to the server for final build and deployment but I'm guessing now that this is not the case and every developer would need to submit a new hi res build?

Again I'm guessing but does this mean that we could end up loosing older 3rd party devices from version 12 if developers don't rebuild?

Or are we going to see 2 versions of reason12?

I would assume not but I still can't fully understand what hi res is actually for? Oled 4K 8k higher than 1920x1080 displays or 50" screens I mean who's sitting in front of that.....

How many people are actually going to benefit from hi res?

I mean it looks better but so what, I like the way Reason looks but I don't spend any time admiring the devices I use them, I definitely can't see myself sticking a monster monitor on my desk just so I can view Reason devices on an oled screen, I've not seen any below 40 plus inches.

[buddard]

This is sounding like a potentially big problem for older no longer developed RE's - I thought that the RE SDK was supposed to deal with all and any of these issues before they were ever an issue.

Custom display background images is the only special case where an asset is in low res.

They will most likely add the option to replace it with a hi res image, and I'm guessing existing low res images will be upscaled automatically.
So the worst case is that some custom display backgrounds might appear slightly blurry when zoomed in, and that's it. It probably won't even be noticed in most cases.

So I don't think this is a big deal.

[orthodox]

I didn't check it yet, but I guess the SDK allows for using a high resolution virtual coordinates for custom displays already. Still it's not clear how it would impact the performance if the background image is downscaled together with the drawing on each display update.

It's a pity we can't specify the display background image in device_2D.lua, where it should really belong. It would then be scaled automatically, like the other images. Now the "{path=}" image specified there is only used to get the display area dimensions and its contents gets ignored, because the custom display currently has no option to be reset to that image, it's either filled black or cleared with that other image specified in virtual pixels.

[buddard]

I didn't check it yet, but I guess the SDK allows for using a high resolution virtual coordinates for custom displays already. Still it's not clear how it would impact the performance if the background image is downscaled together with the drawing on each display update.

It's a pity we can't specify the display background image in device_2D.lua, where it should really belong. It would then be scaled automatically, like the other images. Now the "{path=}" image specified there is only used to get the display area dimensions and its contents gets ignored, because the custom display currently has no option to be reset to that image, it's either filled black or cleared with that another image specified in virtual pixels.

You can use floating point coordinates in the display.
Actually, the integer parts of the coordinates refer to the "corners" of each display pixel, so if you're drawing a line 1 display pixel thick, you should add/subtract 0.5 pixels, or the line will look blurred due to anti-aliasing.
We should still think about displays in low res (for backwards compatibility), the difference will rather be visible in that text, curves and diagonal lines appear much sharper.
This is similar to how we should always align widgets to coordinates divisible by 5.

[jam-s]

This is sounding like a potentially big problem for older no longer developed RE's - I thought that the RE SDK was supposed to deal with all and any of these issues before they were ever an issue.

I don't think it's that big of an issue at least if the dev has the custom display clearly styled like an integrated display. The Display may look a little bit retro then, but that's OK as (older) rack hardware has rather low res displays in real life as well.

[pongasoft]

Sorry for the very low resolution,

Screen Shot 2021-04-23 at 08.41.02.png (45.08 KiB) Viewed 4786 times

but this is an example of a custom display where the background melds with the surrounding

This is the custom display background image


and obviously it is only low resolution. So the knob will probably look really bad when the rest of the device is hi-res (yes the knob is a custom display for technical reasons)

Has anybody tried the hi-res build? Can you check A/B 12? How does it look? I have not signed up for the beta yet...

Yan

[buddard]

Sorry for the very low resolution,


Screen Shot 2021-04-23 at 08.41.02.png


but this is an example of a custom display where the background melds with the surrounding

This is the custom display background image


and obviously it is only low resolution. So the knob will probably look really bad when the rest of the device is hi-res (yes the knob is a custom display for technical reasons)

Has anybody tried the hi-res build? Can you check A/B 12? How does it look? I have not signed up for the beta yet...

Yan

OK, yeah, this is a bit of an extreme case, maybe, as it's not something I think you would typically use a background image for.

Are you drawing something on top of this image in your display?
If not, you're probably better off drawing a static decoration on top of the display instead, since those are always defined in hi res.
That's what we did with the circular displays on Auto-Tune, Processed Pianos and Pattern Mutator, and also with the Run/Rec buttons on Sequences.
A tried and tested trick!

I don't want to comment too much on the beta (since we've been asked not to), but I guess there's no harm in saying that no 3rd party REs are shown in hi res yet. It makes sense since they would all have to be rendered in hi res on RS servers, repackaged and resynced again...

[pongasoft]

OK, yeah, this is a bit of an extreme case, maybe, as it's not something I think you would typically use a background image for.

Are you drawing something on top of this image in your display?
If not, you're probably better off drawing a static decoration on top of the display instead, since those are always defined in hi res.
That's what we did with the circular displays on Auto-Tune, Processed Pianos and Pattern Mutator, and also with the Run/Rec buttons on Sequences.
A tried and tested trick!

I don't want to comment too much on the beta (since we've been asked not to), but I guess there's no harm in saying that no 3rd party REs are shown in hi res yet. It makes sense since they would all have to be rendered in hi res on RS servers, repackaged and resynced again...

Yes I draw a semi-transparent/dark circle to simulate pressing the button. When you say "you are better off drawing a static decoration", it might be the right (or better way) to do it, and I may not disagree (I think I did it this way because the logic of pressing the button was complicated and needed to change other properties and unclear if a static decoration could work).

The point of this thread though, was about custom display backgrounds and how bad they might look. I believe this is a case where it will probably not look very good and even if using a static decoration "fixes" the issue, without any rebuild, it will not happen. I do not know if Reason Studio has any plan on how they are going to deal with this (a way to have hi-res custom display background, which would require a new sdk maybe?), but AFAIK there has been no word so far.

Yan

[Loque]

Sorry for the very low resolution,


Screen Shot 2021-04-23 at 08.41.02.png


but this is an example of a custom display where the background melds with the surrounding

This is the custom display background image


and obviously it is only low resolution. So the knob will probably look really bad when the rest of the device is hi-res (yes the knob is a custom display for technical reasons)

Has anybody tried the hi-res build? Can you check A/B 12? How does it look? I have not signed up for the beta yet...

Yan

I think the devs should try to join the beta:
viewtopic.php?f=4&t=7522775

Not sure, if the devs get some kind of early access, but it would make sense.

[buddard]

The point of this thread though, was about custom display backgrounds and how bad they might look. I believe this is a case where it will probably not look very good and even if using a static decoration "fixes" the issue, without any rebuild, it will not happen. I do not know if Reason Studio has any plan on how they are going to deal with this (a way to have hi-res custom display background, which would require a new sdk maybe?), but AFAIK there has been no word so far.

Agreed!

I just pointed out that it might be an extreme use case of a background image to make it represent a widget, compared to say a gradient or a grid or something like that, that you usually paint over with something else. So I don't think that many devices will be affected, and even for those it will probably be a minor cosmetic issue.

I suggested the static decoration workaround since it's a solution that's available right now, and implementing it means that your device will look good from day 1, without having to wait for an updated SDK -- And it's a solution that's guaranteed to be backwards compatible, and we don't know if that will be true for the next SDK...

A trick that we often use when we mask a custom display "button" is that we make two static decorations: One for the pressed button, and one for the released button.
Then we use a stepped GUI property + visibility switch to change the look of the button when you press it.
Anyway, it's just a suggestion.

[pongasoft]

The point of this thread though, was about custom display backgrounds and how bad they might look. I believe this is a case where it will probably not look very good and even if using a static decoration "fixes" the issue, without any rebuild, it will not happen. I do not know if Reason Studio has any plan on how they are going to deal with this (a way to have hi-res custom display background, which would require a new sdk maybe?), but AFAIK there has been no word so far.

Agreed!

I just pointed out that it might be an extreme use case of a background image to make it represent a widget, compared to say a gradient or a grid or something like that, that you usually paint over with something else. So I don't think that many devices will be affected, and even for those it will probably be a minor cosmetic issue.

I suggested the static decoration workaround since it's a solution that's available right now, and implementing it means that your device will look good from day 1, without having to wait for an updated SDK -- And it's a solution that's guaranteed to be backwards compatible, and we don't know if that will be true for the next SDK...

A trick that we often use when we mask a custom display "button" is that we make two static decorations: One for the pressed button, and one for the released button.
Then we use a stepped GUI property + visibility switch to change the look of the button when you press it.
Anyway, it's just a suggestion.

Thank you for the tip. When I get a chance I will try to see if I can change my RE to use it. Can I draw a static decoration on top of a custom display? In this case I really need the logic associated to the button (which touches multiple properties) and of course display the button. If only a custom display could return the name of an image to render...

Yan

[buddard]

Agreed!

I just pointed out that it might be an extreme use case of a background image to make it represent a widget, compared to say a gradient or a grid or something like that, that you usually paint over with something else. So I don't think that many devices will be affected, and even for those it will probably be a minor cosmetic issue.

I suggested the static decoration workaround since it's a solution that's available right now, and implementing it means that your device will look good from day 1, without having to wait for an updated SDK -- And it's a solution that's guaranteed to be backwards compatible, and we don't know if that will be true for the next SDK...

A trick that we often use when we mask a custom display "button" is that we make two static decorations: One for the pressed button, and one for the released button.
Then we use a stepped GUI property + visibility switch to change the look of the button when you press it.
Anyway, it's just a suggestion.

Thank you for the tip. When I get a chance I will try to see if I can change my RE to use it. Can I draw a static decoration on top of a custom display? In this case I really need the logic associated to the button (which touches multiple properties) and of course display the button. If only a custom display could return the name of an image to render...

Yan

Yes, a static decoration can cover any widget(s) without interfering, even when they have a visibility switch.
A normal use case for them is to add reflections to custom displays, for example.

Just be careful to specify blend_mode = “normal” for every decoration in hdgui_2D.lua, because apparently this is not the default setting, and transparency will NOT look good unless you do this.

[pongasoft]

@bubbard: Thank you for the info. I tried what you suggested and it works like a charm... with the latest sdk...

I then tried to backport it to the SDK that I originally used for the RE (2.2) and I am getting this error:

Code: Select all

HDGUI2D.HDGUI2DFormatError: RE2DRender.py: Error in hdgui_2D.lua: Setting 'visibility_values' unexpected for widget type 'static_decoration'

After digging through the release notes, it looks like visibility_switch was added in 2.5.

So the dilemma is sdk 2.2 makes my RE work on Reason 7.1 and up. But if I use sdk 2.5 it will work only on Reason 9.2 and up. And if I understand correctly, the shop does not offer a way to say: "offer this version of the plugin to users with this version of Reason"... I assume all users of the plugin can still use it. It will only affect new users that have Reason 7 or 8...

Should I care? How do you handle this?

Yan

[joeyluck]

After digging through the release notes, it looks like visibility_switch was added in 2.5.

So the dilemma is sdk 2.2 makes my RE work on Reason 7.1 and up. But if I use sdk 2.5 it will work only on Reason 9.2 and up. And if I understand correctly, the shop does not offer a way to say: "offer this version of the plugin to users with this version of Reason"... I assume all users of the plugin can still use it. It will only affect new users that have Reason 7 or 8...

Should I care? How do you handle this?

Yan

Since your REs are free (and if remaining free), I think it would be perfectly reasonable to release updates as separate products. If it's free, nobody would be missing out on a discounted upgrade price or anything like that.

The other option would be to just give people a heads up before updating. Again, your REs are free, and the concern is for those who are on earlier versions, which in my eyes, means they have been exposed to your products for a long time. These REs have been available to them for free for a while. So thinking about that plus giving a heads up for any of the stragglers, I think is also very reasonable.

I think either approach would be fine in your situation. If they were paid products, I think it would involve a little more thought.

[pongasoft]

After digging through the release notes, it looks like visibility_switch was added in 2.5.

So the dilemma is sdk 2.2 makes my RE work on Reason 7.1 and up. But if I use sdk 2.5 it will work only on Reason 9.2 and up. And if I understand correctly, the shop does not offer a way to say: "offer this version of the plugin to users with this version of Reason"... I assume all users of the plugin can still use it. It will only affect new users that have Reason 7 or 8...

Should I care? How do you handle this?

Yan

Since your REs are free (and if remaining free), I think it would be perfectly reasonable to release updates as separate products. If it's free, nobody would be missing out on a discounted upgrade price or anything like that.

The other option would be to just give people a heads up before updating. Again, your REs are free, and the concern is for those who are on earlier versions, which in my eyes, means they have been exposed to your products for a long time. These REs have been available to them for free for a while. So thinking about that plus giving a heads up for any of the stragglers, I think is also very reasonable.

I think either approach would be fine in your situation. If they were paid products, I think it would involve a little more thought.

Thank you for the feedback. Clearly having a separate product would be the most user friendly way to upgrade. But this is kind of going around what I think is an issue with the way Reason Studios handle the products in the shop (which they could change if they really wanted to). I would need to come up with a different name for the product which would also create confusion in the shop, since now a Reason 11 user would see 2 versions. I definitely have to think about it more...

Thanks

[DaveyG]

Since your REs are free (and if remaining free), I think it would be perfectly reasonable to release updates as separate products. If it's free, nobody would be missing out on a discounted upgrade price or anything like that.

The other option would be to just give people a heads up before updating. Again, your REs are free, and the concern is for those who are on earlier versions, which in my eyes, means they have been exposed to your products for a long time. These REs have been available to them for free for a while. So thinking about that plus giving a heads up for any of the stragglers, I think is also very reasonable.

I think either approach would be fine in your situation. If they were paid products, I think it would involve a little more thought.

Thank you for the feedback. Clearly having a separate product would be the most user friendly way to upgrade. But this is kind of going around what I think is an issue with the way Reason Studios handle the products in the shop (which they could change if they really wanted to). I would need to come up with a different name for the product which would also create confusion in the shop, since now a Reason 11 user would see 2 versions. I definitely have to think about it more...

Thanks

I don't think it is unreasonable to drop support for Reason 7 and 8. They are very old now. You'd have to check with RS but I would expect the shop to not let you update an RE if it would make it incompatible with the version of Reason you are on, in the same way that you cannot buy an RE that requires a later version. So someone on R7 who has not yet "bought" your free RE will no longer be able to do so but if that person already has it then it will carry on working and the update will not be available. But do check.

[joeyluck]

Since your REs are free (and if remaining free), I think it would be perfectly reasonable to release updates as separate products. If it's free, nobody would be missing out on a discounted upgrade price or anything like that.

The other option would be to just give people a heads up before updating. Again, your REs are free, and the concern is for those who are on earlier versions, which in my eyes, means they have been exposed to your products for a long time. These REs have been available to them for free for a while. So thinking about that plus giving a heads up for any of the stragglers, I think is also very reasonable.

I think either approach would be fine in your situation. If they were paid products, I think it would involve a little more thought.

Thank you for the feedback. Clearly having a separate product would be the most user friendly way to upgrade. But this is kind of going around what I think is an issue with the way Reason Studios handle the products in the shop (which they could change if they really wanted to). I would need to come up with a different name for the product which would also create confusion in the shop, since now a Reason 11 user would see 2 versions. I definitely have to think about it more...

Thanks

Gotcha. Yeah I guess it depends on what your version numbers are and if you might want to consider using those in the names. Such as ABL2 and ABL3 or Crapre and Crapre No. 2. Those were separate products, which superseded the previous versions which were discontinued though. I can't think of any examples off the top of my head of separate releases of the same RE existing in the shop at the same time...

Again, I think it's a mess with paid REs, because then you have someone buying the older version when they are compatible with the newer version. But with free REs, there isn't much risk there. Just an annoyance of ending up with multiple versions of the same RE in your account. But hopefully that will be remedied soon with a selective sync all option.

I agree, being able to download versions of one product would be handy.

[DaveyG]

I agree, being able to download versions of one product would be handy.

100% this. If you own an RE you should be able to opt to install any version of it that has been released as long as it is compatible with your Reason version. That can't be that hard to do if the will was there.

[buddard]

@bubbard: Thank you for the info. I tried what you suggested and it works like a charm... with the latest sdk...

I then tried to backport it to the SDK that I originally used for the RE (2.2) and I am getting this error:

Code: Select all

HDGUI2D.HDGUI2DFormatError: RE2DRender.py: Error in hdgui_2D.lua: Setting 'visibility_values' unexpected for widget type 'static_decoration'

After digging through the release notes, it looks like visibility_switch was added in 2.5.

So the dilemma is sdk 2.2 makes my RE work on Reason 7.1 and up. But if I use sdk 2.5 it will work only on Reason 9.2 and up. And if I understand correctly, the shop does not offer a way to say: "offer this version of the plugin to users with this version of Reason"... I assume all users of the plugin can still use it. It will only affect new users that have Reason 7 or 8...

Should I care? How do you handle this?

Yan

Reason 8 is really old by now, I would just ditch support for it. Customers that are still running it can keep using the existing version. You’re only changing it to work better in hi res, so it’s not like they need the update anyway.

When we upgraded our utility devices last year we upgraded the SDK versions on Select, Compare and Metrotone. I don’t think we received a single complaint about backwards compatibility. We received one complaint about the GUI change on Select, I think.

And Metrotone went from SDK 2.0 (Reason 7.1+) to SDK 3.0 (Reason 10.2+)! We did it so we could use the new transport properties for loop points and bar start, in order to support time signature automation.

[pongasoft]

I agree, being able to download versions of one product would be handy.

100% this. If you own an RE you should be able to opt to install any version of it that has been released as long as it is compatible with your Reason version. That can't be that hard to do if the will was there.

Since It is very obvious that Reason+ subscription is what Reason Studio wants for everybody, the "will" will never be there...

[pongasoft]

Reason 8 is really old by now, I would just ditch support for it. Customers that are still running it can keep using the existing version. You’re only changing it to work better in hi res, so it’s not like they need the update anyway.

When we upgraded our utility devices last year we upgraded the SDK versions on Select, Compare and Metrotone. I don’t think we received a single complaint about backwards compatibility. We received one complaint about the GUI change on Select, I think.

And Metrotone went from SDK 2.0 (Reason 7.1+) to SDK 3.0 (Reason 10.2+)! We did it so we could use the new transport properties for loop points and bar start, in order to support time signature automation.

Happy to hear. That makes my decision easier

Yan