So what's on the horizon for REs?

This forum is for discussing Rack Extensions. Devs are all welcome to show off their goods.
User avatar
SA Studio
Posts: 411
Joined: 19 Nov 2015

11 Aug 2017

JiggeryPokery wrote:
10 Aug 2017
SA Studio wrote:
10 Aug 2017
there is no inherent difference between the two formats that's even worth mentioning.
Sorry, SA. That's just not true. There is at least one that's definitely worth mentioning. But you know, NDA and all that prevents a detailed discussion.

But the short version: graphics and custom displays.

I suggest you compare the draw rate of Proton with its basic GUI custom display lines to that of, say, Serum, which is vastly more complex. There's no lag manipulating the GUI in Serum.

But hit the mod page display button on Proton for the first time after instancing (subsequent redraws do seem a bit faster, probably because it's not initialised until it's first called) and you can see Reason struggling to draw basic boxes: it's not drawn instantly, it probably takes a good quarter second, and bare in mind I'm on an 8-Core Ryzen with a Geforce 1070 so I'm sure it's going to be very noticeable for users on some older machines. (There may have been a workaround (other than not using that many boxes :puf_wink: ) that would have made Proton's draw a bit faster that we suspect is not in place, but it's hard to tell). And we've tested this ourselves.

Reason's graphics are so far behind what is possible in a dedicated VST it's not funny. We've been working on one of—quite possibly the most—complex draws of any RE yet published, and it's been painful, and very difficult to test in the SDK's logging version of Reason, so that we have to upload everything to the server to test it in Reason Actual, just to stand a chance of giving it a proper test. The last SDK update was useful in that it [redacted#1] but then bizarrely didn't [redacted#2] to actually allow [redacted#1] to be as useful as it should be. And also passing data from the custom display code to the C++ code or vice versa forces a lot of compromise and loss of functionality.

The upshot: you're wrong. 100%. Sorry.
The upshot is you're going FAR out of your way to be corrct here and we're actually talking about two entirely different things.

Did you just point out the graphical differences, bud? :lol: :lol: That's great. I'm talking about functionality.

And no, I'm not wrong in the slightest = EQ VST's behave and have "workflow" just like EQ RE's. Stop trying to mince words into a disagreement. I'm not trying to argue, but you're talking about something completely different than I am all in effort to end it with "you're wrong".

I'm not. The two formats aren't drastically different in terms of usability, workflow, or functionality. If you want to point out graphical GUI differences...LOL....go ahead.
Last edited by SA Studio on 11 Aug 2017, edited 3 times in total.

User avatar
SA Studio
Posts: 411
Joined: 19 Nov 2015

11 Aug 2017

joeyluck wrote:
10 Aug 2017
SA Studio wrote:
10 Aug 2017


Joey, realize, I've used sooo many RE's as well as VST's that no, there is no inherent difference between the two formats that's even worth mentioning.

EQ plugs all work and "flow" like EQ plugs = Same thing with an RE or VST compressor. All concepts are totally the same and no, I'm not crazy by any remote stretch. I literally have 1000's of hours using various plug-ins from VST to RE and on the whole, it's just not even worth arguing about.

You're even pointing out that some devices/plugs have some feature...and other just do not. That's how it is.

VST's are no harder to use or have any kind of drastically different "workflow" or scheme than RE's. I'm not sure why you wouldn't want to listen to me about these things, Joey. There's really no reason to think of RE's being drastically different from VST any different than someone would compare AU to VST or RTAS to VST. See what I mean?
Perhaps I'm just confusing something here? But the workflows are quite different, very often. Again, for all of the reasons I mentioned. REs are consistent, as they are a proprietary format and are required to work a specific way and integrate in numerous ways with the host. VSTs are not. I guess what you are saying is that VSTs, for the most part can have many of the same behaviors of REs? And I can agree with that. But when I use a VST that can't have it's actions be undone, another which works well with undo, and then use another VST which undoes every incremental step... or which the knobs require circular mouse drag to turn them rather than vertical, some that don't support precise knob adjustments and fly all around... not being able to use one central browser for all plugins, and using the various different internal VST browsers that act differently between one another. The workflows for the various plugins are in fact very different and great for some plugins and crappy for others. If we are talking about 'VST' the format and not the various 'VST' plugins, then yes, their workflows could be similar and in some cases are pretty close.
Naaa. We're not on about the same things. Clearly. I don't want to argue. My point of a EQ VST being just as easy to use as a EQ RE stands.

The workflows are not inherently different between the two formats. Just such a silly thing to argue about. Compressor VST's are just as easy to use as Compressor RE's.

Period.

Yes. Reason devices have more CV functionality, but to say the two formats are such incredibly different products and one is easier to use than the other is just silly, imo.
Last edited by SA Studio on 11 Aug 2017, edited 1 time in total.

User avatar
SA Studio
Posts: 411
Joined: 19 Nov 2015

11 Aug 2017

To be very clear:

Professionals who use VST's every single day are in no way hampered by RE's or put at any advantage using RE's over VST.
Same way someone who uses RE's every day will not be left clueless on how to operate a VST.

They will not find an RE easier to use, nor find it more difficult to use. It's a darn plug in. This isn't rocket science, guys. VST's are no harder to figure out than an RE and if you think so, that's a bit scary. They're just plug-ins, and it's the same thing as saying "AU and RTAS have much different workflows than VST" :lol: :lol:

No. No they do not. Sorry. :reason:

User avatar
joeyluck
Moderator
Posts: 11029
Joined: 15 Jan 2015

11 Aug 2017

I'm certainly not saying one plugin format is more difficult than the other. But small things do work towards a more or less desirable workflow. And how a user weighs that is a preference. That is all.

When you're working and making changes constantly, whether a plugin supports undo (and if it does so properly), or supports your host's browser or it's internal browser behaves completely different than any other VST internal browser... how the controls can be reset (or not), the mouse precision of parameters and the control over that... Or dealing with floating windows, which no VST can escape from... All things that add up and can slow workflow when going between one plugin and another.

Yes, it can be dealt with. But that's not to say that they aren't different. It's like saying macOS and Windows have the same workflow. It's like saying all software has the same workflow. You can even take for example the fact that many users love Reason's new Browser and others don't. For many of those that didn't initially, it slowly grew on them. But there are some that will still say they just can't get on with the different workflow. And it's just a Browser...one single host Browser. A browser is a browser right? But sure, it's a different workflow than before.

And not every VST uses skeuomorphism. Interfaces can be quite different. But in the end, we can choose what VSTs work best for us. Whether the workflow differences affect that decision greatly or not is up to the user. And some things grow on you and you get used to them. I along with many others had suggested to Propellerhead to add the revert patch option to the new Browser... A "feature" before that existed as a quirk of the previous browser that we were all used to. I used it often when they added it, but don't even use the revert button much anymore.

User avatar
Exowildebeest
Posts: 1553
Joined: 16 Jan 2015

11 Aug 2017

RE's easy patch management is something I really like vs. VST.

From a professional point of view, my patches and time are important to me, and I've wasted time and lost patches due to VST's saving patches in obscure locations, using their own browsers etc.

Not saying all VST's are guilty of this of course. And RE patch browsing isn't perfect either, Reason's browser is still not very good.

User avatar
Exowildebeest
Posts: 1553
Joined: 16 Jan 2015

11 Aug 2017

SA Studio wrote:
11 Aug 2017

They will not find an RE easier to use, nor find it more difficult to use. It's a darn plug in. This isn't rocket science, guys.
I do find RE's somewhat easier to use (unless they're terribly designed, and some are) because they follow a few universal design principles, some specified by PH, some inherent in the Reason platform, like right clicking, patch saving. Makes things easier than having to remember what's what on a per-VST basis.

Also, from a sound design perspective, it's very easy to extend the capabilities of a RE with CV if it's well supported - this makes sounddesign quicker and easier for me. We won't see CV outs on VST's for a while, probably never :) Of course it's awesome that there's CV input for VST's though, this alone makes Reason a very interesing VST host.

User avatar
Exowildebeest
Posts: 1553
Joined: 16 Jan 2015

11 Aug 2017

SA Studio wrote:
11 Aug 2017
JiggeryPokery wrote:
10 Aug 2017


Sorry, SA. That's just not true. There is at least one that's definitely worth mentioning. But you know, NDA and all that prevents a detailed discussion.

But the short version: graphics and custom displays.

I suggest you compare the draw rate of Proton with its basic GUI custom display lines to that of, say, Serum, which is vastly more complex. There's no lag manipulating the GUI in Serum.

But hit the mod page display button on Proton for the first time after instancing (subsequent redraws do seem a bit faster, probably because it's not initialised until it's first called) and you can see Reason struggling to draw basic boxes: it's not drawn instantly, it probably takes a good quarter second, and bare in mind I'm on an 8-Core Ryzen with a Geforce 1070 so I'm sure it's going to be very noticeable for users on some older machines. (There may have been a workaround (other than not using that many boxes :puf_wink: ) that would have made Proton's draw a bit faster that we suspect is not in place, but it's hard to tell). And we've tested this ourselves.

Reason's graphics are so far behind what is possible in a dedicated VST it's not funny. We've been working on one of—quite possibly the most—complex draws of any RE yet published, and it's been painful, and very difficult to test in the SDK's logging version of Reason, so that we have to upload everything to the server to test it in Reason Actual, just to stand a chance of giving it a proper test. The last SDK update was useful in that it [redacted#1] but then bizarrely didn't [redacted#2] to actually allow [redacted#1] to be as useful as it should be. And also passing data from the custom display code to the C++ code or vice versa forces a lot of compromise and loss of functionality.

The upshot: you're wrong. 100%. Sorry.
The upshot is you're going FAR out of your way to be corrct here and we're actually talking about two entirely different things.

Did you just point out the graphical differences, bud? :lol: :lol: That's great. I'm talking about functionality.

And no, I'm not wrong in the slightest = EQ VST's behave and have "workflow" just like EQ RE's. Stop trying to mince words into a disagreement. I'm not trying to argue, but you're talking about something completely different than I am all in effort to end it with "you're wrong".

I'm not. The two formats aren't drastically different in terms of usability, workflow, or functionality. If you want to point out graphical GUI differences...LOL....go ahead.
He does point out an interesting issue with RE development. And in the end, it does pertain to functionality - if RE GUI's are laggy compared to VST (they are) that could hinder my workflow (I admit, it doesn't really... at this time). That's at least a potential issue and +1 for VST, vs. RE.

User avatar
joeyluck
Moderator
Posts: 11029
Joined: 15 Jan 2015

11 Aug 2017

And another thing I mentioned was dealing with floating windows and it hindering workflow. At the same time being able to make a complex synth full screen (or just larger) is nice for workflow. Pluses on both sides. Differences in workflows.

User avatar
miscend
Posts: 1955
Joined: 09 Feb 2015

11 Aug 2017

VSTs actually have an advantage in that you can enlarge the GUI. Its great for looking at analysers and metering plugins. RE's have tiny GUIs.

scratchnsnifff
Posts: 1423
Joined: 21 Sep 2016

21 Aug 2017

Didn't want to make a new thread, was wondering if anyone knows of any teasers for any up and coming RE instruments im happy as can be about the sdk improvement, I suppose I am excited to see what will be done with the update
Mayor of plucktown :evil:

User avatar
Ahornberg
Posts: 1904
Joined: 15 Jan 2016
Location: Vienna, Austria
Contact:

21 Aug 2017

scratchnsnifff wrote:
21 Aug 2017
Didn't want to make a new thread, was wondering if anyone knows of any teasers for any up and coming RE instruments im happy as can be about the sdk improvement, I suppose I am excited to see what will be done with the update
I'm interested in every RE that makes microtonal tunings possible in Reason. Yes, there's MicroTuner by Ochen K. but I'm thinking far beyond that. Maybe an RE that allows to load tuning files or gives a GUI to design microtonal tunings graphically. Maybe an RE that controls the microtonal tunings of all instruments in a Reason song or gives the ability to change the tuning over time by CV.

User avatar
JiggeryPokery
RE Developer
Posts: 1174
Joined: 15 Jan 2015

22 Aug 2017

SA Studio wrote:
11 Aug 2017


The upshot is you're going FAR out of your way to be corrct here and we're actually talking about two entirely different things.

Did you just point out the graphical differences, bud? :lol: :lol: That's great. I'm talking about functionality.

And no, I'm not wrong in the slightest = EQ VST's behave and have "workflow" just like EQ RE's. Stop trying to mince words into a disagreement. I'm not trying to argue, but you're talking about something completely different than I am all in effort to end it with "you're wrong".

I'm not. The two formats aren't drastically different in terms of usability, workflow, or functionality. If you want to point out graphical GUI differences...LOL....go ahead.
But I'm not doing an EQ, there are plenty of those already. ;)

It's difficult to discuss because of NDA, but I'm gonna risk a bit of a stretch here because maybe it will help you understand the issue. Regardless of whether you think I'm being onery and disgreeing with you just for the sake of disagreeing and trying to prove you wrong, you've stated, adamantly, for the record that VST and RE usability isn't drastically different.

The fundamental method to produce a custom display in RE format can have a massive impact on usability for the end user and on developers ability to create complex displays, because we're forced into making arbitrary limitations that other plugin devs don't have to make.

Sure, for simple EQ curves, it probably isn't that different, I'll grant you that. But not everything that we want to do is a simple EQ curve or other value metering, or a multi-stage envelope. Those are fairly simple to render; but even with those, remember Rack Extension draws are still, afaik, limited to less than 25 FPS (OTTOMH I think it's just 20FPS). [It still cracks a few RE devs up that one guy put an FPS knob on his RE to allow people to, um, crank it up to "60"... ].

As a developer working on Rack Extensions for the past five years, I know your basic tenet isn't true: I can't go into precise details, but broad strokes here, Scuzzy and I are working on a project for the past six months, and because the RE custom display system that does the drawing is not integrated with the C++, value precision is lost transfering data between C++ and LUA, and you can't transfer large amounts of data in one block. And these are both substantial problems that effect what we can draw, how quickly we can draw it, and how well the user can interact with, and then update the values drawn.

With SDK2.5 the single block data size was increased a bit, which was useful, but the problem then was there's no real method of managing when multiple blocks of data are transferred, or notifying the system when next block of data is due, so we end up with draw errors.

The only way to ensure redraws are correct is to literally place a pause between each data block transfer, thereby making the overall draw even slower than 20FPS. So complex custom displays can't ever, in the current SDK, reach 20FPS. Every RE Dev who's done a substantial custom display, one that's more than just a simple line draw, who has just read this is slowly nodding their head and wiping a quiet tear from the corner of their eye.

These fundamental draw issues make thinking outside the box and doing some non-standard RE extraordinarily difficult, and whatever you think, SA, that then impacts on the performance and the usability to end user. We simply do not have the fluidity and scalability of graphic performance compared to other formats.

User avatar
AttenuationHz
Posts: 2048
Joined: 20 Mar 2015
Location: Back of the Rack-1

22 Aug 2017

VST's suffer the same FPS limit. Came across and reported this problem with Blue Cat's Freqanalyst Multi and I'm sure other intensive GUI's suffer the same fate. Reason makes using them useless! In this day and age there should not be any limit for graphics especially if you have a dedicated GPU worth 5 times the price of a Reason update. A 60hz display has trouble, imaging what a 240hz display would do!
Last edited by AttenuationHz on 22 Aug 2017, edited 1 time in total.
It is not too much of an ask for people or things to be the best version of itself!

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

22 Aug 2017

Formats that do not use jbridge ever:
AAX & RE.

-----------------------------------
Formats that do use Jbridge at one point for most vsts:
VST/AU
Last edited by Oquasec on 22 Aug 2017, edited 2 times in total.
Producer/Programmer.
Reason, FLS and Cubase NFR user.

sdst
Competition Winner
Posts: 896
Joined: 14 Jun 2015

22 Aug 2017

So what's on the horizon for REs?

maybe more sample base synth?

I have 45 synth, And can't wait for the next synth

I would be surprised if something different came up

scratchnsnifff
Posts: 1423
Joined: 21 Sep 2016

22 Aug 2017

sdst wrote:
22 Aug 2017
So what's on the horizon for REs?

maybe more sample base synth?

I have 45 synth, And can't wait for the next synth

I would be surprised if something different came up
I'm in hopes of seeing propellerhead make a new synth, I would love it if they made their own take on a modern wavetable synth it feels like it's been a while since they have made a synth
Mayor of plucktown :evil:

EdGrip
Posts: 2343
Joined: 03 Jun 2016

23 Aug 2017

I reckon that with eXpanse in the shop and Serum, Zebra etc now useable directly in Reason, there's not really a modern wavetable gap in Reason to fill. My guess is that PH aren't going to bother with new Reason or PH devices, apart from maybe the odd little device to make a new version interesting.

scratchnsnifff
Posts: 1423
Joined: 21 Sep 2016

23 Aug 2017

EdGrip wrote:
23 Aug 2017
I reckon that with eXpanse in the shop and Serum, Zebra etc now useable directly in Reason, there's not really a modern wavetable gap in Reason to fill. My guess is that PH aren't going to bother with new Reason or PH devices, apart from maybe the odd little device to make a new version interesting.
That would appear to be how it goes :p il keep hoping they make something though. I always thought it would be cool if they made a vst synth. A kind of reason in a box type idea. Something like Thor but if that were to happen it would have to have a CV page :p honestly in my opinion it doesn't matter what they do because I'm just a fan and il take what ever as long as it's quality products :D
Mayor of plucktown :evil:

User avatar
Loque
Moderator
Posts: 11170
Joined: 28 Dec 2015

23 Aug 2017

I would like to see what comes out, if i mix several different synth methods (additive, subtractive, wavetable, phase distortion, FM, AM, RM, resynthesis, physical, and so on...) combined with a bunch of different modifiers... And pls, no limits for modifiers and all should be automatable and a big not-limited mod matrix.
Reason12, Win10

ltbrunt00
Posts: 532
Joined: 10 Jan 2017
Contact:

23 Aug 2017

Would the Props build a new unique synth to fully demonstrate what there SDK can do. Unfortunately I think between Stock, REs and VST we have all synth possibilities covered.

Could a 3rd party developer make a Player RE or are players strictly created by Propellerhead.
Reason, Nuendo, Studio One
https://soundcloud.com/user-404930848

User avatar
Ahornberg
Posts: 1904
Joined: 15 Jan 2016
Location: Vienna, Austria
Contact:

23 Aug 2017

ltbrunt00 wrote:
23 Aug 2017
Would the Props build a new unique synth to fully demonstrate what there SDK can do. Unfortunately I think between Stock, REs and VST we have all synth possibilities covered.

Could a 3rd party developer make a Player RE or are players strictly created by Propellerhead.
Actually Players are not part of the RE SDK.

scratchnsnifff
Posts: 1423
Joined: 21 Sep 2016

23 Aug 2017

Loque wrote:
23 Aug 2017
I would like to see what comes out, if i mix several different synth methods (additive, subtractive, wavetable, phase distortion, FM, AM, RM, resynthesis, physical, and so on...) combined with a bunch of different modifiers... And pls, no limits for modifiers and all should be automatable and a big not-limited mod matrix.
That's also how I see it, sure all the synth areas covered but there's always room for a unique take on a pre-existing idea. We have a whole lot of FM synths in the shop but each one differs from the next and when the next one is out il probably want that one as well
Mayor of plucktown :evil:

User avatar
Ahornberg
Posts: 1904
Joined: 15 Jan 2016
Location: Vienna, Austria
Contact:

23 Aug 2017

scratchnsnifff wrote:
23 Aug 2017
Loque wrote:
23 Aug 2017
I would like to see what comes out, if i mix several different synth methods (additive, subtractive, wavetable, phase distortion, FM, AM, RM, resynthesis, physical, and so on...) combined with a bunch of different modifiers... And pls, no limits for modifiers and all should be automatable and a big not-limited mod matrix.
That's also how I see it, sure all the synth areas covered but there's always room for a unique take on a pre-existing idea. We have a whole lot of FM synths in the shop but each one differs from the next and when the next one is out il probably want that one as well
something like 2CAudio's Kaleidoscope would be interesting

User avatar
kungubu
Posts: 111
Joined: 21 May 2016

23 Aug 2017

The only thing i really find is missing in the RE-formt is a Buchla-like synth, with a complex oscillator with a lot of sweetspots, a lopass gate with a good vactorol emulation and a function generator with control over the slopes. Something like Madrona labs Aalto – http://madronalabs.com/products/aalto. But now when we have vst that will probably never happen.

User avatar
Faastwalker
Posts: 2281
Joined: 15 Jan 2015
Location: NSW, Australia

23 Aug 2017

Ahornberg wrote:
23 Aug 2017
ltbrunt00 wrote:
23 Aug 2017
Would the Props build a new unique synth to fully demonstrate what there SDK can do. Unfortunately I think between Stock, REs and VST we have all synth possibilities covered.

Could a 3rd party developer make a Player RE or are players strictly created by Propellerhead.
Actually Players are not part of the RE SDK.
Would love to see some new players. The 3 that are in there are very useful & fun to play around with.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: Mataya and 21 guests