Reason 10 too slow with VST

[househoppin09]

Thanks for reporting back. 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.

[Psuper]

It has nothing to do with how the VST is coded, it has to do with Reason forcing 64 sample buffer size and how efficient Reasons wrapper is, then how powerful your system is. You simply cannot run any beefy VST worth it's salt at a buffer of 64 in 96k+ on most systems, including my last one which was powerful enough. I just built a new Z370 system system with a few cutting edge choice components. Using Pianoteq (Standalone or hosted VST), Reason 9.5, and Antelope Discreet 4 Interface (brand new, killer asio performance btw).

Reason 96k Hosting VST Pianoteq (forced 64 buffer size), playing 30 notes polyphony. CPU on 6 cores at 50%
Pianoteq 96k STANDALONE, buffer size 128, playing 50 polyphony, CPU on 6 cores at 12%
Reason 96k + MIDILOOPBACK PianoTeq, buffer size 128, playing 50 polyphony, CPU on 6 cores at 18%

That's the story right there. If it doesn't make sense, go try midiloopback for yourself. Load up some core temp to watch your heat (new system hit 40c at all cores running about 50%), taskmanager is good enough for CPU stress % if you don't have something in your DAW or app, have fun and learn a little.

I'll give you the quick and easy if you don't know how:

Download midiloopback and run it.
Set up a loopback port call it something like "VSTReason".
Load up Reason.
Add a external midi device.
Click the pulldown in the device and choose your "VSTReason"
Load up your standalone Music App (I use Pianoteq)
Make sure midi is being received via "VSTReason" (or all midi, but this way you have control)
Done - VST in Reason.

Then you can add that audio back into Reason to use it's effects, all kinds of routing you can do. This works far better than Propellerheads VST Wrapper for performance alone, not to mention the additional routing you never thought possible.

[Pi5cEan]

Dang, that's one heck of a work-around. My work around lately has just been using Reaper w/ Reason rewired. I mainly now use Reason as my deep beat-maker. I love Reason, been a paid user since Reason 2, but tired of work arounds or feeling like I need to get a new machine. I don't need a new machine, I'm very happy with the one I have.
Things are super smooth now & the more I learn about Reaper (very unwieldy at first) the more I'm realizing how powerful it is.. & utterly efficient. I haven't even paid for it yet lol, but I'm about to.

Kind of sad but whatever, I just want to make music.

[Psuper]

Yep, Reason was just a rewired instrument like Props designed it to be for years, then slowly became a DAW, sat on it's lazy ass for too long while other DAWs passed it up, and is now back to being a rewired instrument!

Think many of us who use our DAWs often are in that same boat Pi5, we all love Reason for a variety of considerations. However it's hard to justify running as a main DAW unless you just putz around once in awhile in it.

Oh and the workaround is really simple, doesn't take any extra time once you build a template I've been doing that for years dealing with Reasons lack of VST functionality among other reasons. Regardless, it's a solid way for everyone to test and see for their own how terrible VST performance can be in Reason, and work around it if they care to.

[househoppin09]

It has nothing to do with how the VST is coded, it has to do with Reason forcing 64 sample buffer size and how efficient Reasons wrapper is, then how powerful your system is. You simply cannot run any beefy VST worth it's salt at a buffer of 64 in 96k+ on most systems, including my last one which was powerful enough.

For all I know you could be right about this, but it directly contradicts what normen said clearly and repeatedly earlier in this thread (i.e. that it has a lot to do with the particular nature of the workload that the VST is doing, the algorithms it uses and so on). I'm inclined to think that he knows what he's talking about here. What makes you so sure that the particulars of what the VST is doing are irrelevant? Clearly it can't be that all VSTs (or even all "beefy" ones, whatever that could possibly mean) struggle badly at 64, because there are plenty of people happily using all kinds of feature-rich VSTs in Reason, including the OP of this very thread!

I just built a new Z370 system system with a few cutting edge choice components. Using Pianoteq (Standalone or hosted VST), Reason 9.5, and Antelope Discreet 4 Interface (brand new, killer asio performance btw).

Reason 96k Hosting VST Pianoteq (forced 64 buffer size), playing 30 notes polyphony. CPU on 6 cores at 50%
Pianoteq 96k STANDALONE, buffer size 128, playing 50 polyphony, CPU on 6 cores at 12%
Reason 96k + MIDILOOPBACK PianoTeq, buffer size 128, playing 50 polyphony, CPU on 6 cores at 18%

That's the story right there. If it doesn't make sense, go try midiloopback for yourself. Load up some core temp to watch your heat (new system hit 40c at all cores running about 50%), taskmanager is good enough for CPU stress % if you don't have something in your DAW or app, have fun and learn a little.

I mean, okay, but you realize that CPU utilization is hardly a clear-cut metric here, right? The Props themselves have gone out of their way to warn that the Reason engine does things that crank up CPU utilization in ways that can't be assumed to scale linearly with increasing DSP load. They could be BSing about that, but I doubt it. As Mattias and others have said, isn't the proper way to test these things to ignore CPU utilization and simply look at actual performance in the context of everyday production tasks?

I'll give you the quick and easy if you don't know how:

Download midiloopback and run it.
Set up a loopback port call it something like "VSTReason".
Load up Reason.
Add a external midi device.
Click the pulldown in the device and choose your "VSTReason"
Load up your standalone Music App (I use Pianoteq)
Make sure midi is being received via "VSTReason" (or all midi, but this way you have control)
Done - VST in Reason.

Then you can add that audio back into Reason to use it's effects, all kinds of routing you can do. This works far better than Propellerheads VST Wrapper for performance alone, not to mention the additional routing you never thought possible.

It's absolutely mystifying to me that you somehow consider this quick, easy, or convenient. I've done it plenty of times, and I find it nightmarishly annoying. I mean, it's not a big deal if you just want to run a single VSTi, but what happens when you need to use five or ten at once? You're going to micromanage that many separate virtual MIDI cables and virtual (or, god forbid, physical) audio cables? And you don't see why anyone would balk at having to do that? Seriously?

Also, a question of genuine interest: what kind of "additional routings you never thought possible" did you have in mind here? I feel like I can do all of the routings I'd ever need already with the standard Reason VST wrapper (not counting the admittedly important unimplemented features such as multitimbrality), and would love to know what advanced routing possibilities I might be overlooking.

[Oquasec]

You need voicemeter or a loopback interface, or doing it the simpler way by loading up Reason, then a daw after reason and then using the EMI on the second daw to get proper loopback without a loopback interface or voicemeter (If voicemeter doesn't work that way for you of course without audio glitches)

[chaosroyale]

I use VSTs in combinators, maybe 5 or 10 in a single combinator, so the idea of having to use loopback or nested DAWs fills me with horror. I just want VSTs to work better in Reason. Not even to the same level as Studio One or Reaper, even half as good would be a huge improvement.

200 instances in Studio One > 40 instances in Reason.... It's a bit disappointing.

[Psuper]

It has nothing to do with how the VST is coded, it has to do with Reason forcing 64 sample buffer size and how efficient Reasons wrapper is, then how powerful your system is. You simply cannot run any beefy VST worth it's salt at a buffer of 64 in 96k+ on most systems, including my last one which was powerful enough.

For all I know you could be right about this, but it directly contradicts what normen said clearly and repeatedly earlier in this thread (i.e. that it has a lot to do with the particular nature of the workload that the VST is doing, the algorithms it uses and so on). I'm inclined to think that he knows what he's talking about here. What makes you so sure that the particulars of what the VST is doing are irrelevant? Clearly it can't be that all VSTs (or even all "beefy" ones, whatever that could possibly mean) struggle badly at 64, because there are plenty of people happily using all kinds of feature-rich VSTs in Reason, including the OP of this very thread!

I am right about this. A shitty VST will run the same few instances in any DAW. A highly-optimized VST will right the same many instances in any DAW. It's relative. Reason just screws the VST over by forcing it to run at 64 samples regardless - Reason's fault not the VST.

I just built a new Z370 system system with a few cutting edge choice components. Using Pianoteq (Standalone or hosted VST), Reason 9.5, and Antelope Discreet 4 Interface (brand new, killer asio performance btw).

Reason 96k Hosting VST Pianoteq (forced 64 buffer size), playing 30 notes polyphony. CPU on 6 cores at 50%
Pianoteq 96k STANDALONE, buffer size 128, playing 50 polyphony, CPU on 6 cores at 12%
Reason 96k + MIDILOOPBACK PianoTeq, buffer size 128, playing 50 polyphony, CPU on 6 cores at 18%

That's the story right there. If it doesn't make sense, go try midiloopback for yourself. Load up some core temp to watch your heat (new system hit 40c at all cores running about 50%), taskmanager is good enough for CPU stress % if you don't have something in your DAW or app, have fun and learn a little.

I mean, okay, but you realize that CPU utilization is hardly a clear-cut metric here, right? The Props themselves have gone out of their way to warn that the Reason engine does things that crank up CPU utilization in ways that can't be assumed to scale linearly with increasing DSP load. They could be BSing about that, but I doubt it. As Mattias and others have said, isn't the proper way to test these things to ignore CPU utilization and simply look at actual performance in the context of everyday production tasks?

It's the only metric that matters. Feel free to find some other obscure metric to test with, you'll be wasting your time. How in the hell does one "Properly Test Things" by 'looking at actual performance' in the context of everyday production tasks? That's ridiculous, that's called not testing anything at all.

I'll give you the quick and easy if you don't know how:

Download midiloopback and run it.
Set up a loopback port call it something like "VSTReason".
Load up Reason.
Add a external midi device.
Click the pulldown in the device and choose your "VSTReason"
Load up your standalone Music App (I use Pianoteq)
Make sure midi is being received via "VSTReason" (or all midi, but this way you have control)
Done - VST in Reason.

Then you can add that audio back into Reason to use it's effects, all kinds of routing you can do. This works far better than Propellerheads VST Wrapper for performance alone, not to mention the additional routing you never thought possible.

It's absolutely mystifying to me that you somehow consider this quick, easy, or convenient. I've done it plenty of times, and I find it nightmarishly annoying. I mean, it's not a big deal if you just want to run a single VSTi, but what happens when you need to use five or ten at once? You're going to micromanage that many separate virtual MIDI cables and virtual (or, god forbid, physical) audio cables? And you don't see why anyone would balk at having to do that? Seriously?

What's mystifying is your assumptions and apparent lack of context.

1. Propellerhead used to not have VST in Reason, I explained how that could accomplished.
2. Propellerhead now has VST in Reason, performance is far better the old midiloopback way, as proven.
3. I showed exactly how and why you may want to use the old midiloopback way.
4. I showed exactly how so you can test your own system, instead of poo-pooing other peoples experiences with a bunch of excuses (like 'looking at actual performance' in the context of everyday production tasks" Or "Your PC must be the cause!"
4. I've been the one telling Props to fix their shit, no one WANTS to have to do it the old way, myself included.

Learn to fish in otherwords, and if it's too annoying, don't -- I couldn't care less. I'm being helpful to those who use Reason as their DAW, need VST performance, and don't know how to work around it. Thanks Psuper!

[EnochLight]

You know, I rarely agree with Psuper because he's usually wrong about everything, but I have to agree with him here.

[Psuper]

You know, I rarely agree with Psuper because he's usually wrong about everything, but I have to agree with him here.

lol its weird man, we both agree and disagree on most things - how can that even be??!

[EnochLight]

lol its weird man, we both agree and disagree on most things - how can that even be??!

We're probably brothers from another mother.

[Psuper]

lol its weird man, we both agree and disagree on most things - how can that even be??!

We're probably brothers from another mother.

Mama Music baby... Mama Music.

[AttenuationHz]

I would probably take the automation/modulation delay for a bigger buffer alright! Or the option for one anyway... Surely delay comp could work there though!

[EdGrip]

Maybe there could be a preference option to change the buffer size, to prioritize VST performance or CV fidelity, depending?

[househoppin09]

I am right about this. A shitty VST will run the same few instances in any DAW. A highly-optimized VST will right the same many instances in any DAW. It's relative. Reason just screws the VST over by forcing it to run at 64 samples regardless - Reason's fault not the VST.

Okay, I see what you were trying to say now. I thought you were saying that it's not different from one VST to another, which obviously wouldn't have made much sense. I guess my comment was badly worded, when I said it had to do with "the way the VST is coded"--you thought I was blaming VST developers, trying to imply that they needed to step up their game. I can see how it might have come across that way, sorry about that. What I meant was that it depends on what the VST is doing. So we actually agree on this point.

It's the only metric that matters. Feel free to find some other obscure metric to test with, you'll be wasting your time. How in the hell does one "Properly Test Things" by 'looking at actual performance' in the context of everyday production tasks? That's ridiculous, that's called not testing anything at all.

Why is CPU utilization "the only metric that matters"? That doesn't make any sense at all. CPU utilization is only useful insofar as you can infer other things from it. If Reason's actual audio output is breaking up when attempting to run projects that other DAWs can handle just fine (and, yes, I realize that people have indeed been having issues with that), THAT'S the problem to be worrying about. Not some difficult-to-interpret number popping up in Task Manager. I obviously get that they're directly related and that problematically high CPU utilization numbers reflect the same problem that ultimately causes the audio dropouts, but it seems pretty clear that it's not linear or a 1:1 relationship in the way that you seem to be assuming. In other words, I definitely agree that Reason has major issues here, but it's silly to think that the extent of the problem can be measured accurately in the way that you're trying to do it.

What's mystifying is your assumptions and apparent lack of context.

1. Propellerhead used to not have VST in Reason, I explained how that could accomplished.
2. Propellerhead now has VST in Reason, performance is far better the old midiloopback way, as proven.
3. I showed exactly how and why you may want to use the old midiloopback way.
4. I showed exactly how so you can test your own system, instead of poo-pooing other peoples experiences with a bunch of excuses (like 'looking at actual performance' in the context of everyday production tasks" Or "Your PC must be the cause!"
4. I've been the one telling Props to fix their shit, no one WANTS to have to do it the old way, myself included.

Learn to fish in otherwords, and if it's too annoying, don't -- I couldn't care less. I'm being helpful to those who use Reason as their DAW, need VST performance, and don't know how to work around it. Thanks Psuper!

I pretty much agree with all of this, I was just reacting to your "use this quick-and-easy method, nothing to it" attitude. You didn't seem to really be appreciating that it's not always necessarily so quick-and-easy, it depends heavily on the particular use case. As I already said, of course it's doable when wanting to run a single VST, but not so much when wanting to use VSTs for half of the devices in your project (unless you submix in a second DAW, which obviously introduces yet another layer of complications, and doesn't seem to be what you had in mind anyway).

I'm still genuinely interested in knowing what kind of advanced routing possibilities are possible for VST with loopback, that aren't possible when using Reason's VST wrapper, by the way, if you're at all inclined to share...

[EnochLight]

I'm still genuinely interested in knowing what kind of advanced routing possibilities are possible for VST with loopback, that aren't possible when using Reason's VST wrapper, by the way, if you're at all inclined to share...

Oooo me too! I used the loopback method for some time before 9.5, and I always hated the clunkiness of it. I never really explored these mystical "routing possibilities" and would love to know about them.

[Psuper]

I am right about this. A shitty VST will run the same few instances in any DAW. A highly-optimized VST will right the same many instances in any DAW. It's relative. Reason just screws the VST over by forcing it to run at 64 samples regardless - Reason's fault not the VST.

Okay, I see what you were trying to say now. I thought you were saying that it's not different from one VST to another, which obviously wouldn't have made much sense. I guess my comment was badly worded, when I said it had to do with "the way the VST is coded"--you thought I was blaming VST developers, trying to imply that they needed to step up their game. I can see how it might have come across that way, sorry about that. What I meant was that it depends on what the VST is doing. So we actually agree on this point.

It's the only metric that matters. Feel free to find some other obscure metric to test with, you'll be wasting your time. How in the hell does one "Properly Test Things" by 'looking at actual performance' in the context of everyday production tasks? That's ridiculous, that's called not testing anything at all.

Why is CPU utilization "the only metric that matters"? That doesn't make any sense at all. CPU utilization is only useful insofar as you can infer other things from it. If Reason's actual audio output is breaking up when attempting to run projects that other DAWs can handle just fine (and, yes, I realize that people have indeed been having issues with that), THAT'S the problem to be worrying about. Not some difficult-to-interpret number popping up in Task Manager. I obviously get that they're directly related and that problematically high CPU utilization numbers reflect the same problem that ultimately causes the audio dropouts, but it seems pretty clear that it's not linear or a 1:1 relationship in the way that you seem to be assuming. In other words, I definitely agree that Reason has major issues here, but it's silly to think that the extent of the problem can be measured accurately in the way that you're trying to do it.

What's mystifying is your assumptions and apparent lack of context.

1. Propellerhead used to not have VST in Reason, I explained how that could accomplished.
2. Propellerhead now has VST in Reason, performance is far better the old midiloopback way, as proven.
3. I showed exactly how and why you may want to use the old midiloopback way.
4. I showed exactly how so you can test your own system, instead of poo-pooing other peoples experiences with a bunch of excuses (like 'looking at actual performance' in the context of everyday production tasks" Or "Your PC must be the cause!"
4. I've been the one telling Props to fix their shit, no one WANTS to have to do it the old way, myself included.

Learn to fish in otherwords, and if it's too annoying, don't -- I couldn't care less. I'm being helpful to those who use Reason as their DAW, need VST performance, and don't know how to work around it. Thanks Psuper!

I pretty much agree with all of this, I was just reacting to your "use this quick-and-easy method, nothing to it" attitude. You didn't seem to really be appreciating that it's not always necessarily so quick-and-easy, it depends heavily on the particular use case. As I already said, of course it's doable when wanting to run a single VST, but not so much when wanting to use VSTs for half of the devices in your project (unless you submix in a second DAW, which obviously introduces yet another layer of annoying complications).

I'm still genuinely interested in knowing what kind of advanced routing possibilities are possible for VST with loopback, that aren't possible when using Reason's VST wrapper, by the way, if you're at all inclined to share...

Fair enough, I get that I've been there myself at times we're all human.

As for the Metric, what you described before about "just look at it" is cringe worthy, and if it came from Propellerheads mouth I'm beside myself. My CPU test is not only the most accurate method of testing to date, its the only real-world metric that is easily identifiable and reproducible by every single user of Reason specific to the problem at hand.

As for magical routing, don't any of you guys who love Reason for the hardware "look"... ever use hardware? Admittedly I don't do much of that at all anymore, however I did some pretty insane stuff back in the day with that, glovepie, and a few other goodies. But hey... isn't "VST" in Reason prior VST support epic enough?

But man... if anyone of you guys ever did anything kind of routing at all (do you honestly use Reason, cmon... be honest...)... to be complaining about some simple-ass midi routing is making my sides hurt lol.

Is the Midiloop back interface too "intimidating"

[househoppin09]

Well, Propellerhead has said that the engine does things that nonlinearly inflate CPU utilization at relatively low loads, then level off to some extent at higher loads. If that's even partially true, your simplistic CPU load assessments will be misleading to the point of near-uselessness. What exactly is cringeworthy about daring to believe that maybe, just possibly, the Props might not have been lying through their teeth when they made those claims? I mean, I'll admit to having some healthy skepticism there, but the claims are plausible enough in theory. There are lots of things the engine could be doing that would lead to those kinds of nonlinearities. Do you have any actual evidence or argument for why the engine is definitely not doing those things? I'm willing to respect your point of view on this but you haven't really backed it up with anything.

And just to be clear, I'm not complaining about "simple-ass MIDI routing", I'm complaining about the incredible unwieldiness of trying to loopback large numbers of VSTs with Reason all at once. The process of doing that is nothing like tinkering with the rack in Reason, nor anything like using a hardware rack. Apples and oranges. Have you ever actually tried to loopback more than a small handful of VSTs at once? That's not a rhetorical question, if you have I'd love to know any tips and tricks you came up with to make the process more manageable.

[Oquasec]

Reason forces vsts to a set buffer not affected by the audio settings menu?
Damn. I'm a rewire main for good lol

[EnochLight]

As for magical routing, don't any of you guys who love Reason for the hardware "look"... ever use hardware? Admittedly I don't do much of that at all anymore, however I did some pretty insane stuff back in the day with that, glovepie, and a few other goodies. But hey... isn't "VST" in Reason prior VST support epic enough?

But man... if anyone of you guys ever did anything kind of routing at all (do you honestly use Reason, cmon... be honest...)... to be complaining about some simple-ass midi routing is making my sides hurt lol.

Is the Midiloop back interface too "intimidating"

Let's be clear: most of us use a DAW like Reason because it's all "in the box". Same with having VST. I can't speak for househoppin09, but when you said there are so many other routing possibilities going with the loopback method, I assumed you meant in the context of using our DAW ITB. And while I again can't speak for househoppin09, I can speak for myself - I've been using hardware since 1986. Do I still like using hardware, MIDI cables, audio cables, etc? HELL NO. That's why I went with a DAW and produce ITB (although you will never pry my Juno 106 from my cold, dead hands).

So, getting back to the subject at hand, if you're trying to pass off MIDI/audio loopback with running VST externally as a superior method due to that, then I'd say that's quite a laughable stretch, man. I mean seriously, come on... And yeah, you're being disingenuous if you think MIDI/audio loopback isn't a hassle. And that's for people who actually have a soundcard that supports audio loopback!

[Psuper]

Oh come on now, seriously? We were beyond this weren't we?

1. Show me a way to test VST performance in Reason vs when it's Standalone or in another DAW. That's the point of my post.

2. Exactly how does one "Properly Test Things" by 'looking at actual performance' in the context of everyday production tasks? I REALLY wanna hear this one. Feel free to get into great detail.

3. Exactly what did Props Claim? Did it make complete sense to you? By all means explain it to us then cause it sounded like "No way to test performance, live with it." by my estimation.

4. Did props offer a way to test it? Feel free to elaborate, cause the only identifiable issue is a 64 sample buffer, which if you understand audio, is exactly the issue minus whatever code is mangling a VST wrapper. And my test, while maybe supersceded by whatever test you had in mind (I seriously am excited to hear it), is the only one that tests VST in and outside of Reason.

Now as for a billion VSTs, who suggested that? I needed it for my Pianoteq, maybe you need it for some Kontakt, who know who cares I'm not suggesting you route your whole damn house with midiloopback - it's a tool.

That's like someone saying "Hey why did Propellerhead include the Matrix - what a Pain in the ASS having a billion possible routes I can't be bothered with that!! Oh, and those cables in the back, why would I want to take the time to route 50 of those?"

It's a tool, similar to any routing/bussing/etc you learned in a DAW, no more simple or difficult than anything you should already be familiar with. All you're doing is creating one Midi port all your apps can see. What is so hard about that?

And it's for anyone who does Midi, uses Reason, and VSTs. Unless I somehow stumbled upon some other forum, but I'm pretty certain this one is about VST and Reason.

Hello... am I on Candid Camera? AFV? Where's the rickroll.. I know its gotta be somewhere...

[avasopht]

Maybe there could be a preference option to change the buffer size, to prioritize VST performance or CV fidelity, depending?

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.

[EnochLight]

Oh come on now, seriously? We were beyond this weren't we?

Huh? What are you going on about? We're talking about you insisting that running MIDI/audio loopback for VST in Reason is easy and loaded with awesome routing options, and we're all incompetent sods for not being able to wrap our heads around it being such an enjoyable experience, that's all. I actually agree with your testing methods, and agree with your findings. I was merely pointing out that you're being disingenuous about the experience compared to (say for instance) native support.

Hello... am I on Candid Camera? AFV? Where's the rickroll.. I know its gotta be somewhere...

If you are, I'm on it with you, apparently!

[avasopht]

Do you have any actual evidence or argument for why the engine is definitely not doing those things? I'm willing to respect your point of view on this but you haven't really backed it up with anything.

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.

[Psuper]

Oh come on now, seriously? We were beyond this weren't we?

Huh? What are you going on about? We're talking about you insisting that running MIDI/audio loopback for VST in Reason is easy and loaded with awesome routing options, and we're all incompetent sods for not being able to wrap our heads around it being such an enjoyable experience, that's all. I actually agree with your testing methods, and agree with your findings. I was merely pointing out that you're being disingenuous about the experience compared to (say for instance) native support.

That was meant for househop mate, not you.

Candid Camera here we come!