Reason 10 too slow with VST

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

08 Dec 2017

make a copy of regular vst folder, by using jbridge and copy the bridged stuff a different location then scan as one workaround.
Producer/Programmer.
Reason, FLS and Cubase NFR user.

househoppin09
Posts: 536
Joined: 03 Aug 2016

08 Dec 2017

avasopht wrote:
08 Dec 2017
One thing worth clearing up. DAWs don't have "audio engines." I guess you could call the scheduler an "audio engine." Not sure why though.

How VSTs and REs work is that the DAW says: "render me x frames of audio". The VST / RE renders x frames of audio. That is it. VSTs / REs render audio exactly like any other program does. Then the DAW passes that audio along to either the next device in the chain, or the mixer. There is no "audio engine" involved in actually processing the VST / RE.

As for evidence: the 64 frame buffers can be verified by creating a processing loop by feeding audio from a device's output back into it's input. You can do this in Thor. You will see that a processing loop incurs a 64 frame delay.

If the VST itself is using more CPU, it will most likely be due to the lower buffer sizes.

I'm not going to say there are no other possible areas for contention, but without any data to demonstrate that Reason is underutilizing VSTs at 64 frame buffers (specifically 64 frame buffers), it's pointless to question Reason's management of VSTs with regards to performance.
Very informative post, thank you. Although, to be clear, I wasn't denying that Reason runs all VSTs at 64, I consider that well established. What I'm questioning is the assumption people keep making that CPU utilization can be compared apples-to-apples between different DAWs, regardless of load level. Even aside from audio scheduling concerns, I don't see how that could be the case? Each DAW has various tasks to attend to at any given moment, and each one will manage its CPU overhead differently. It just seems nonsensical to think that anyone who doesn't have intimate familiarity with the internals of the DAW would be able to peer at a bunch of CPU figures and divine a simple 1-to-1 comparison from them. It's possible that I'm overcomplicating this in some way and it's actually much simpler to make these comparisons than I suspect. I'm not claiming to be an expert, but I don't really see how it could be otherwise.

As far as the whole question of what is the proper way to compare performance between DAWS... I mean, isn't it obvious? You do it where the rubber meets the road. You load up instances of (e.g.) Diva in DAW 1 and see how many you can get before audio dropouts start to occur. Then you do the same in DAW 2, and see what the ratio of possible instances is. Then, you do that for a wide range of other VSTs. You end up with a clear and useful profile of what the actual performance differential is, in practice. Now, if it turns out that the resulting ratio you get corresponds perfectly to the per-instance CPU utilization ratio in every case, then I'll happily admit to having been wrong in my skepticism of using the CPU figures. And hey, maybe that is indeed the case! Again, I'm not claiming to be an expert. It just seems like using the CPU figures is open to significant doubt, whereas the process I just described is open to none whatsoever.

User avatar
Psuper
Posts: 524
Joined: 29 May 2016

09 Dec 2017

househoppin09 wrote:
08 Dec 2017
avasopht wrote:
08 Dec 2017
One thing worth clearing up. DAWs don't have "audio engines." I guess you could call the scheduler an "audio engine." Not sure why though.

How VSTs and REs work is that the DAW says: "render me x frames of audio". The VST / RE renders x frames of audio. That is it. VSTs / REs render audio exactly like any other program does. Then the DAW passes that audio along to either the next device in the chain, or the mixer. There is no "audio engine" involved in actually processing the VST / RE.

As for evidence: the 64 frame buffers can be verified by creating a processing loop by feeding audio from a device's output back into it's input. You can do this in Thor. You will see that a processing loop incurs a 64 frame delay.

If the VST itself is using more CPU, it will most likely be due to the lower buffer sizes.

I'm not going to say there are no other possible areas for contention, but without any data to demonstrate that Reason is underutilizing VSTs at 64 frame buffers (specifically 64 frame buffers), it's pointless to question Reason's management of VSTs with regards to performance.
Very informative post, thank you. Although, to be clear, I wasn't denying that Reason runs all VSTs at 64, I consider that well established. What I'm questioning is the assumption people keep making that CPU utilization can be compared apples-to-apples between different DAWs, regardless of load level. Even aside from audio scheduling concerns, I don't see how that could be the case? Each DAW has various tasks to attend to at any given moment, and each one will manage its CPU overhead differently. It just seems nonsensical to think that anyone who doesn't have intimate familiarity with the internals of the DAW would be able to peer at a bunch of CPU figures and divine a simple 1-to-1 comparison from them. It's possible that I'm overcomplicating this in some way and it's actually much simpler to make these comparisons than I suspect. I'm not claiming to be an expert, but I don't really see how it could be otherwise.

As far as the whole question of what is the proper way to compare performance between DAWS... I mean, isn't it obvious? You do it where the rubber meets the road. You load up instances of (e.g.) Diva in DAW 1 and see how many you can get before audio dropouts start to occur. Then you do the same in DAW 2, and see what the ratio of possible instances is. Then, you do that for a wide range of other VSTs. You end up with a clear and useful profile of what the actual performance differential is, in practice. Now, if it turns out that the resulting ratio you get corresponds perfectly to the per-instance CPU utilization ratio in every case, then I'll happily admit to having been wrong in my skepticism of using the CPU figures. And hey, maybe that is indeed the case! Again, I'm not claiming to be an expert. It just seems like using the CPU figures is open to significant doubt, whereas the process I just described is open to none whatsoever.
Yes, his post said the same thing I proved and also stated. I also included the test and how-to that anyone with Reason can perform with any of their own VSTs. "If the VST itself is using more CPU, it will most likely be due to the lower buffer sizes." Yes, exactly, then the wrapper, then the PC in order of performance hit, also laid out by me.

Haven't you been following the performance threads in forums since VST was added? Everyone already knows instances of plugins are paltry compared to how many you can load up in Reason , and still apologists like you try poo-pooing those people and their tests.

In fact the last thing you said before I finally got tired of hearing the same old apology shit and proved you wrong was:
househoppin09 wrote:"That seems consistent with normen's claim that the 64 sample buffer size for VSTs may or may not cause problems depending on how the VST is coded."
You apologized for Reason and blamed VST coding.

End of story - Reason is shit VST performance, everyone knows it, everyone now has their own way to verify it. Shoot the messenger all you like, but you've done nothing to help others understand how to test for themselves while being surrounded by said apologists. I provided an accurate way that anyone can test for themselves , despite your lack of understanding why.
Reason needs to DAW.viewtopic.php?f=6&t=7504985

househoppin09
Posts: 536
Joined: 03 Aug 2016

09 Dec 2017

Dude, what in god's name are you on about? I've never said or implied that Reason's VST performance is good, much less acted as an apologist for it in any way. I can assure you that I'm quite dissatisfied with the VST performance. I thought I had made that clear earlier; if not, I'm making it clear now, so you've really got no further excuses to make up nonsense about the simple and consistent position I've adopted here, which is: yes, the VST performance sucks, yes that's presumably due in large part to the fixed 64-sample buffer and the various ways that each particular VST's code is impacted by that buffer size, but simplistically comparing per-instance CPU utilization between DAWs is unlikely to be the smartest way to get a fully accurate and well-contextualized assessment of just how bad Reason's VST performance truly is. To my way of thinking (which I fully admit could be misguided), the method I described above seems obviously superior. Would you like to bother actually trying to explain why you think it's not, or will another session of shrieking semi-coherent accusations be forthcoming? (Also, I already apologized for my poor wording in that original comment of mine that's got you so enraged, and explained what I actually meant by it which was fully in agreement with what you were saying, so your continuing obsession with that comment and misrepresentation of it are very weird... :?)

User avatar
Psuper
Posts: 524
Joined: 29 May 2016

09 Dec 2017

househoppin09 wrote:
09 Dec 2017
Dude, what in god's name are you on about? I've never said or implied that Reason's VST performance is good, much less acted as an apologist for it in any way. I can assure you that I'm quite dissatisfied with the VST performance. I thought I had made that clear earlier; if not, I'm making it clear now, so you've really got no further excuses to make up nonsense about the simple and consistent position I've adopted here, which is: yes, the VST performance sucks, yes that's presumably due in large part to the fixed 64-sample buffer and the various ways that each particular VST's code is impacted by that buffer size, but simplistically comparing per-instance CPU utilization between DAWs is unlikely to be the smartest way to get a fully accurate and well-contextualized assessment of just how bad Reason's VST performance truly is. To my way of thinking (which I fully admit could be misguided), the method I described above seems obviously superior. Would you like to bother actually trying to explain why you think it's not, or will another session of shrieking semi-coherent accusations be forthcoming? (Also, I already apologized for my poor wording in that original comment of mine that's got you so enraged, and explained what I actually meant by it which was fully in agreement with what you were saying, so your continuing obsession with that comment and misrepresentation of it are very weird... :?)
I like when people speak their mind and stated I understood your misunderstanding, and thought we were beyond it. Yet you kept on with poo-pooing a method of testing anyway in some odd attempt at delegitimizing one of the few accurate ways to test. I want to see progress, thats the ONLY reason I post in these threads, especially when they are misleading and giving Props an undeserved pass. Not a discussion between you and I on something you don't understand - Pm me if you really want my advice - let others decide for themselves if it makes sense testing the way provided.

You confuse explicit clarity with some random raging. I'm making 100% sure we're clear how we got to this point. I laid out everything clear from my first post in this thread, anyone can read back and make sense of it. Yet I keep seeing your dissatisfaction at how I was able to show fellow Reasoners how to test for themselves, and test well the VST performance in and out of Reason with a consistent methodology.

If it doesn't make sense to you, fine. It makes sense to most of us.
Reason needs to DAW.viewtopic.php?f=6&t=7504985

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

09 Dec 2017

avasopht wrote:
08 Dec 2017
It's not about CV fidelity. CV fidelity could remain the same at different buffer sizes. What the 64 buffer size changes is the behaviour of feedback loops.
Nah, CV and automation - especially for VSTs - can only happen at the buffer size rate, it very much is about CV "fidelity" (i.e. max frequency).

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

09 Dec 2017

normen wrote:
09 Dec 2017
avasopht wrote:
08 Dec 2017
It's not about CV fidelity. CV fidelity could remain the same at different buffer sizes. What the 64 buffer size changes is the behaviour of feedback loops.
Nah, CV and automation - especially for VSTs - can only happen at the buffer size rate, it very much is about CV "fidelity" (i.e. max frequency).
EDIT: Oh snap, just double checked, ... the capability in the spec I was thinking of is capped just shy of making that a possibility. That being said, devices being called to render successively might see similar speed increses to longer batches depending on the overhead cost of parameter / buffer interactions.

For future devices they could provide an extension to the spec providing CV offsets to allow longer batches (at multiples of 64), which could provide speed ups in the absence of feedback loops.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

09 Dec 2017

avasopht wrote:
09 Dec 2017

EDIT: Oh snap, just double checked, ... the capability in the spec I was thinking of is capped just shy of making that a possibility. That being said, devices being called to render successively might see similar speed increses to longer batches depending on the overhead cost of parameter / buffer interactions.

For future devices they could provide an extension to the spec providing CV offsets to allow longer batches (at multiples of 64), which could provide speed ups in the absence of feedback loops.
Well they won‘t make all VST developers change their code either, its simply how those plugins work, a parameter set per batch.

The possibility I see is having an option for a longer buffer size for all or certain VST plugins, obviously that would result in them always having (buffer size - 64) samples latency though.

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

09 Dec 2017

normen wrote:
09 Dec 2017
Well they won‘t make all VST developers change their code either, its simply how those plugins work, a parameter set per batch.

The possibility I see is having an option for a longer buffer size for all or certain VST plugins, obviously that would result in them always having (buffer size - 64) samples latency though.
Personally I don't think that would be much of a problem with PDC.

The way I see VST is more a case of, they shouldn't be in the rack but we have them as an uber bonus. So I either get a delay that may be compensated for, or a likely performance hit. I can live with that.

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

09 Dec 2017

avasopht wrote:
09 Dec 2017
normen wrote:
09 Dec 2017
Well they won‘t make all VST developers change their code either, its simply how those plugins work, a parameter set per batch.

The possibility I see is having an option for a longer buffer size for all or certain VST plugins, obviously that would result in them always having (buffer size - 64) samples latency though.
Personally I don't think that would be much of a problem with PDC.

The way I see VST is more a case of, they shouldn't be in the rack but we have them as an uber bonus. So I either get a delay that may be compensated for, or a likely performance hit. I can live with that.
Delay comp on the back of a mixer channel can already compensate for that. If say, you increase the buffer on a VST to 128 or 256 you can add 64 or 192 to the mix channel(s) which have the native devices or RE connected. They are still spitting out at 64 just getting delayed to match the increased buffer! If there is something to be compensated i.e. a lookahead on a compressor/gate/limiter one solution could be to Direct Out to a new mix channel to compensate.

64 samples is not that much 1.3ms (256 5.3ms) Human brain can only pick delays of over 6 ms iirc. So you would not even realise the delay.
If that was to be the case I think I'd rather have DC do that automatically though instead of setting each mix channels delay comp around back

As for the automation well that is where a nudge +/- would come in handy on the sequencer for the VST. Modulation I'm not sure, would it be the same way? In any case surely you could modulate first then buff up for the VST no!?
It is not too much of an ask for people or things to be the best version of itself!

rpowers9
Posts: 18
Joined: 20 Jul 2015

10 Dec 2017

i pretty much gave up on mixing vst with reason this major version. It just doesn't compare to the other major DAWS performance wise that I have tried, on multiple machines. Not even close. I was bummed at first, but I pretty much just kept on trucking with reason anyway. Have enough rack extensions and not enough time where I just let it go. I hope it will improve over time.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

10 Dec 2017

avasopht wrote:
09 Dec 2017
The way I see VST is more a case of, they shouldn't be in the rack but we have them as an uber bonus.
I can't feel this way. The moment 9.5 appeared and offered the option, it had a fiduciary responsibility to compete/perform either as well or better than every other DAW out there, IMHO. So far, it hasn't hit either mark. As a DAW user considering Reason, I shouldn't have to come into Reason and get worse performance in this experience, IMHO.

That said, I really hope a solution is offered soon.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

10 Dec 2017

EnochLight wrote:
10 Dec 2017
I can't feel this way. The moment 9.5 appeared and offered the option, it had a fiduciary responsibility to compete/perform either as well or better than every other DAW out there, IMHO. So far, it hasn't hit either mark. As a DAW user considering Reason, I shouldn't have to come into Reason and get worse performance in this experience, IMHO.

That said, I really hope a solution is offered soon.
Well why doesn't the modulation rate in other DAWs count there? There Reason does perform better. I don't get why in this forum where people claim to hear the "analogness" of filters nobody seems to give a crap about that and rolls with interpolated filter moves in other DAWs.

EdGrip
Posts: 2343
Joined: 03 Jun 2016

10 Dec 2017

I think, if I'm understanding things right, we'd like the option to say
"I have no need for high rates of CV modulation in this track. I'd rather have some extra DSPs to spend on other things, thanks."

In other words, we'd like the option to use Reason as our main DAW without a huge performance sacrifice because we know it and we like it; but also have the option to use Reason to its full crazy modular sound design CV rack potential if we're in that mood, at the expense of VST performance, if that's a choice we must make. If we're just using a bit of CV here and there for some LFOs or whatever, we don't need clean high-frequency CV powers.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

10 Dec 2017

normen wrote:
10 Dec 2017
EnochLight wrote:
10 Dec 2017
I can't feel this way. The moment 9.5 appeared and offered the option, it had a fiduciary responsibility to compete/perform either as well or better than every other DAW out there, IMHO. So far, it hasn't hit either mark. As a DAW user considering Reason, I shouldn't have to come into Reason and get worse performance in this experience, IMHO.

That said, I really hope a solution is offered soon.
Well why doesn't the modulation rate in other DAWs count there? There Reason does perform better.
Because I'm talking about performance in Reason. Let's not conflate the two. ;) I'm just asking for a solution to the "I can get 50 instances of plugin X in DAW A yet only get 25 instances or less of plugin X in Reason". I'll happily manage the latency introduced if the solution is just not forcing VST's to use 64 samples.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

10 Dec 2017

EnochLight wrote:
10 Dec 2017
Because I'm talking about performance in Reason. Let's not conflate the two. ;)
No, you're talking about instance count. So Logic with 1024 samples buffer is better than Logic with 128 samples according to that paradigm. Or even "more efficient"? ;)

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

10 Dec 2017

normen wrote:
10 Dec 2017
EnochLight wrote:
10 Dec 2017
Because I'm talking about performance in Reason. Let's not conflate the two. ;)
Yes, you're talking about instance count.
Fixed that for you. ;)
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

10 Dec 2017

EnochLight wrote:
10 Dec 2017
avasopht wrote:
09 Dec 2017
The way I see VST is more a case of, they shouldn't be in the rack but we have them as an uber bonus.
I can't feel this way. The moment 9.5 appeared and offered the option, it had a fiduciary responsibility to compete/perform either as well or better than every other DAW out there, IMHO. So far, it hasn't hit either mark. As a DAW user considering Reason, I shouldn't have to come into Reason and get worse performance in this experience, IMHO.

That said, I really hope a solution is offered soon.
Which is why I also said, "So I either get a delay that may be compensated for, or a likely performance hit. I can live with that." The former would have the same performance as other DAWs, but you can't have both.

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

10 Dec 2017

In fairness I hardly ever modulate a VST. That is connect CV into one!

If the option was there which it probably should have been from the get go. I would sacrifice latency for performance when needs be. When needs be though you are probably past the point of engineering/production and onto the engineering/mixing or even mastering stage of a project!
It is not too much of an ask for people or things to be the best version of itself!

chaosroyale
Posts: 728
Joined: 05 Sep 2017

10 Dec 2017

I think EdGrip is onto something here but it would need very careful implementation in a track that uses CV for some devices and not others. Most of my audio effect VSTs - EQs and so on - do not need any CV input, they just process audio. Is is possible to have a switch on each VST wrapper like "use this device without CV inputs for greater CPU efficiency". And then an automatic adjustment to the overall track delay compensation to line up the non-CV devices with the CV devices...?
EdGrip wrote:
10 Dec 2017
I think, if I'm understanding things right, we'd like the option to say
"I have no need for high rates of CV modulation in this track. I'd rather have some extra DSPs to spend on other things, thanks."

In other words, we'd like the option to use Reason as our main DAW without a huge performance sacrifice because we know it and we like it; but also have the option to use Reason to its full crazy modular sound design CV rack potential if we're in that mood, at the expense of VST performance, if that's a choice we must make. If we're just using a bit of CV here and there for some LFOs or whatever, we don't need clean high-frequency CV powers.

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

10 Dec 2017

chaosroyale wrote:
10 Dec 2017
I think EdGrip is onto something here but it would need very careful implementation in a track that uses CV for some devices and not others. Most of my audio effect VSTs - EQs and so on - do not need any CV input, they just process audio. Is is possible to have a switch on each VST wrapper like "use this device without CV inputs for greater CPU efficiency". And then an automatic adjustment to the overall track delay compensation to line up the non-CV devices with the CV devices...?
EdGrip wrote:
10 Dec 2017
I think, if I'm understanding things right, we'd like the option to say
"I have no need for high rates of CV modulation in this track. I'd rather have some extra DSPs to spend on other things, thanks."

In other words, we'd like the option to use Reason as our main DAW without a huge performance sacrifice because we know it and we like it; but also have the option to use Reason to its full crazy modular sound design CV rack potential if we're in that mood, at the expense of VST performance, if that's a choice we must make. If we're just using a bit of CV here and there for some LFOs or whatever, we don't need clean high-frequency CV powers.

Re-Read whatever you thought you read then read my post and repeat that!
It is not too much of an ask for people or things to be the best version of itself!

User avatar
Viscor
Posts: 39
Joined: 25 May 2015

13 Dec 2017

I am not huge into DSP programming so call me out if I see things way too simple.

But couldn't you just automatically increase the buffer size of Reason's VST bridge when there is no CV signal connected?
Really just thinking of some simple if(){}; else(){}; there.

Or maybe Propellerheads just gives us the option to run Reason in general in a higher buffer size. Of course with some warning added that it might cause delay and glitches when using CV.

I know, things aren't always that simple, but who knows. :?

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

13 Dec 2017

Viscor wrote:
13 Dec 2017
I am not huge into DSP programming so call me out if I see things way too simple.

But couldn't you just automatically increase the buffer size of Reason's VST bridge when there is no CV signal connected?
Really just thinking of some simple if(){}; else(){}; there.

Or maybe Propellerheads just gives us the option to run Reason in general in a higher buffer size. Of course with some warning added that it might cause delay and glitches when using CV.

I know, things aren't always that simple, but who knows. :?
I wonder if allowing the buffer size for the VST device to be increased would "break" CV? What about automation? Just thinking out loud...
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

13 Dec 2017

Holy hell, that would be a good explanation. Didn't even consider if CV routing needs that.
Producer/Programmer.
Reason, FLS and Cubase NFR user.

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

13 Dec 2017

EnochLight wrote:
13 Dec 2017
Viscor wrote:
13 Dec 2017
I am not huge into DSP programming so call me out if I see things way too simple.

But couldn't you just automatically increase the buffer size of Reason's VST bridge when there is no CV signal connected?
Really just thinking of some simple if(){}; else(){}; there.

Or maybe Propellerheads just gives us the option to run Reason in general in a higher buffer size. Of course with some warning added that it might cause delay and glitches when using CV.

I know, things aren't always that simple, but who knows. :?
I wonder if allowing the buffer size for the VST device to be increased would "break" CV? What about automation? Just thinking out loud...
Probably would cause havoc but if done in stages, Modulate/automate first when everything is locked in then up the buffer. I'm not sure if it could be done like this but if I was coding this is the way I would look to do it. Delay compensation is there already as I said in previous posts so the increased delay to the VST can be compensated with mix channels that use the native buffer sizes. Automation would have a delay also so that would have to be compensated on the sequencer. (possibly have a blank space at the start of a project to allow clips to move into the bar -0 zone)

Just a theory anyway. I do not code myself but if the problem lies with a VST not being able to use the lower buffer without performance decreasing then the obvious thing to do is give it more juice. Another thing is what if everything was on a higher buffer anyway and then when automation or modulation is detected that device gets a decreased buffer to allow the automation/modulation to be processed. This is more complicated because once a combinator is added or a device is put inside a mix channel or CV connected it would be assumed you intend to modulate. If everything is on the higher buffer and the finale stage of that is just using the 64 buffer for automation/modulation would it not be possible to inject that 64 buffer rate to the stage that has the higher buffer using a delay on the higher buffer! :problem:

Individual buffer for each VST device would be a nightmare, I'd say, if each one had a button on the back for more buffer +64 how would each user determine what is better from device to device.
It is not too much of an ask for people or things to be the best version of itself!

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 32 guests