Reason 10.3 public beta is open!

[EnochLight]

you realize Reaper has had the ability to freely route audio from anywhere to anywhere and modulate any signal with any other signal since years ago right? maybe you mean that Reapers gui will never be as complicated as Reason's given the hardware paradigm? i'm not sure how you get any more "complicated" in terms of functionality (without going completely modular like Usine and all the recent Eurorack sims like vcv and vm) than the ability to route anything to anything else and modulate anything with anything else - it's also semi-adopted the Podium paradigm of hierarchical audio routing. Reason is simpler in every way except graphical presentation imo.

Reaper weighs in at a paltry 11 MB. The. Entire. DAW.

Reason weighs in at 3.6 GB - it's literally 335% larger than Reaper in content and code (18x larger if just counting the DAW portion), and that's not including the additional content in the romplers, drum loop supply, etc.

I'm saying Reason is more complicated because it is by definition a more complicated ecosystem, there are more lines of code, hosting not only its own native devices, but 3rd party plugins, and now VST, as well as including an astronomically huge amount of content in plugins and samples compared to Reaper - all which include code. And yes, I know of all the routing and modulating that Reaper is capable of - I used it for years (much to my dismay).

[jam-s]

this is purely speculative, and it's not very logical that the performance of Reason should be affected by using retina displays or not.
Reason only uses a display layer to render UI graphics and it doesn't affect the performance of the application itself if you render the graphics on a retina display or not.

As Reason is using a software renderer for its rack it does matter if it's got to paint 1M (720p), 2M (fullHD), 5M (Retina, 15"MBPro) or almost 10M (4k) pixels during scrolling and every few hundred samples to update the meters of any rack devices.

Add colour profiles (correction) to this and the CPU gets even more workload on top while it still has to manage to fill the output buffer in time.

[miscend]

I know this isn't the purpose of this thread, but..

I wouldn't say it's a Mac only thing, and I agree there was a noticeable drop in performance. I was on PC running v6.5 absolutely flawlessly, but after upgrading to v9.5 performance was noticeably poorer on the same machine. I'm now running a 2018 Macbook and the "run in low resolution mode" hack is essential.

Wow, interesting. My original question stands then I guess, will Reason 10.3 bring us back to Reason 6/7 levels of performance with stock devices I wonder?

AFAIK levels of performance changed after Reason 6 that’s when even the system requirements changed. Reason 5 and earlier were super low CPU.

[scratchnsnifff]

I regular came back here to read about the new beta and all i can read here is about other stuff...

Any news about the beta which can be shared?

literally in the same boat haha was expecting some wows and maybe some woes? but just dolphins, bats, and casio recorders.

[selig]

I regular came back here to read about the new beta and all i can read here is about other stuff...

Any news about the beta which can be shared?

literally in the same boat haha was expecting some wows and maybe some woes? but just dolphins, bats, and casio recorders.

Just like every other beta, I can only assume there are some of both. But you won’t find any talk of dolphins or bats in the beta, which is sad IMO.


Sent from some crappy device using Tapatalk

[antic604]

So how and why does it also improve the overall, non-VST performance? I remember this wasn't an assumption or even expected (although I'm super happy about it, because I disabled VSTs in Reason altogether).

This is explained in the blog post.
They had do rewrite large parts of the audio engine, which had positive effects for the regular playback and operations in Reason as well as the VST specific operations.
They probably did a much needed, rather substantial refactoring and optimization of the old code base, having the positive side-effect of enhancing general performance.

"rewrite", "refactoring" and "optimisation" literally mean nothing without context & details, at least for a technical person who understands code, algorithms, data structures, etc. But sure - I shouldn't expect Props to disclose all of their technical details & know-how just because some random guy on ReasonTalk was curious

[seqoi]

This thread gone kinda offtopic (arguing about past versions and content). I'll try to to fix it by asking:

Does anyone in the beta 10.3 can confirm at least some other fixes? Like fixed Kontakt libraries. AFAIK some Kontakt libraries have problem with long loading time. Happens only in Reason and PH confirmed that to me. Also some VST fx had weird gui glitches. They said (6 month ago) that they will fix this. I signed for beta few days ago so still waiting my download links.

Asking here maybe someone tried it. Did you notice any improvement?

[guitfnky]

This is explained in the blog post.
They had do rewrite large parts of the audio engine, which had positive effects for the regular playback and operations in Reason as well as the VST specific operations.
They probably did a much needed, rather substantial refactoring and optimization of the old code base, having the positive side-effect of enhancing general performance.

"rewrite", "refactoring" and "optimisation" literally mean nothing without context & details

they literally mean you can expect the code to be more efficient, and potentially, a performance increase for the software. you literally don’t need more information than that to expect those things.

literally.

[Kenni]

Indeed, it is well known by all that I routinely ignore logic AND facts. Why else would I hang out at a place like this?

Hah, I intended to give the impression that I might actually be "worse" in that regard, not that you ignored logic and facts.

[reddust]

Indeed, it is well known by all that I routinely ignore logic AND facts. Why else would I hang out at a place like this?

I do personally have a REASON to ignore LOGIC, if you know what I mean

[reddust]

Great, just applied for the beta

Make sure you duplicate current projects before opening and saving them with the beta. Just a best practice to use separate projects for beta testing.

Thanks a lot, didn't think of that

This thread gone kinda offtopic (arguing about past versions and content). I'll try to to fix it by asking:

Does anyone in the beta 10.3 can confirm at least some other fixes? Like fixed Kontakt libraries. AFAIK some Kontakt libraries have problem with long loading time. Happens only in Reason and PH confirmed that to me. Also some VST fx had weird gui glitches. They said (6 month ago) that they will fix this. I signed for beta few days ago so still waiting my download links.

Asking here maybe someone tried it. Did you notice any improvement?

I did this same question yesterday, testers are supposedly not allowed to share any information publicly yet, so all we have for now is to guess and offtopic for now

[antic604]

they literally mean you can expect the code to be more efficient, and potentially, a performance increase for the software. you literally don’t need more information than that to expect those things.

literally.

I get that, but I'm curious what exactly was inefficient? Like we know now that the problem with VSTs was the fixed 64-sample communication buffer.

My day job is literally focused around looking for optimisations, efficiency, synergies, etc. so perhaps that's why I'm asking for details, instead of just being happy I can add few more tracks or REs to my music. Also if I'm honest I'd never call myself "hobbyist music producer" but rather something like "music production tools enthusiast", because it's the process - and ways, and tools, and their features - of making music what I enjoy the most

[EnochLight]

You guys!

[attachment=0]literally-acol8j.jpg[/attachment]

[Breach The Sky]

On my system I have better performance with lover buffer sizes. I noticed that behavior since i got windows 10 but it seems to be even more so now. I think 10 got new audiodrivers right? Is that why? Not that i complain or anything!

[ScuzzyEye]

I get that, but I'm curious what exactly was inefficient? Like we know now that the problem with VSTs was the fixed 64-sample communication buffer.

My first guess would be anything using SIMD. It's always going to improve performance if you let the loop run for more than 64-samples without switching away to do something else. That's the whole point of repeting the same operation on an aligned buffer. Keep the CPU pipeline completely filled processing easily pre-fetched data that nicely fill an arithmetic register. The longer you can run the same loop the less percentage of the time will be spent setting up the next bit of processing. The trade-off is latency.

[Creativemind]

VST3 support would be nice.

Sorry folks, only just read the previous comments (as I posted previously on this thread about whether we'd see VST 3 support as did npinero1) and it doesn't appear likely.

What I would like to ask though, would VST 3 support require another big rewrite of code or just adding something in to the previously existing code? if the latter, then hopefully we'll see VST 3 support in Reason 11.

Can anyone shed any light on this at all?

[ScuzzyEye]

Sorry folks, only just read the previous comments (as I posted previously on this thread about whether we'd see VST 3 support as did npinero1) and it doesn't appear likely.

What I would like to ask though, would VST 3 support require another big rewrite of code or just adding something in to the previously existing code? if the latter, then hopefully we'll see VST 3 support in Reason 11.

Can anyone shed any light on this at all?

Adding support for VST3 on top of VST2 would be less work than initially adding VST2 support from nothing. VST3 adds more features to the host interface that would have to be included.

These include an actual API for MIDI I/O, which would require Reason to support MIDI filter VSTs. There's no official way to do it in VST2, it's more of an agreement with plug-in makers and DAW designers.

Sample-accurate automation, rather than MIDI-clocked automation. Reason is somewhere between that; automation events are sent once per batch, which is sample-based, not MIDI-based, but you can't change a parameter every sample.

VST3 instruments can offically receive audio, rather than being an effect that receives MIDI notes. Reason already set up for this type of audio routing, so it wouldn't involve any big changes.

So yeah, adding VST3 support wouldn't be as large an undertaking as adding/improving the initial VST2 support. The VST3 spec was mostly to formalize a lot of things VST2 developers and DAW companies were already making work, but weren't officially part of the spec.

Will Reason one day support VST3? I'd like to think so. Will it be in 10.3? No.

[guitfnky]

they literally mean you can expect the code to be more efficient, and potentially, a performance increase for the software. you literally don’t need more information than that to expect those things.

literally.

I get that, but I'm curious what exactly was inefficient? Like we know now that the problem with VSTs was the fixed 64-sample communication buffer.

My day job is literally focused around looking for optimisations, efficiency, synergies, etc. so perhaps that's why I'm asking for details, instead of just being happy I can add few more tracks or REs to my music. Also if I'm honest I'd never call myself "hobbyist music producer" but rather something like "music production tools enthusiast", because it's the process - and ways, and tools, and their features - of making music what I enjoy the most

I getchu man, I was just being snarky and pedantic (a good night’s sleep coupled with an abundance of coffee can have that effect on me ).

[antic604]

I get that, but I'm curious what exactly was inefficient? Like we know now that the problem with VSTs was the fixed 64-sample communication buffer.

My first guess would be anything using SIMD. It's always going to improve performance if you let the loop run for more than 64-samples without switching away to do something else. That's the whole point of repeting the same operation on an aligned buffer. Keep the CPU pipeline completely filled processing easily pre-fetched data that nicely fill an arithmetic register. The longer you can run the same loop the less percentage of the time will be spent setting up the next bit of processing. The trade-off is latency.

Thanks! That's exactly the kind of info - or speculation, to be more precise - I was looking for I'd imagine that the core of Reason's audio engine hasn't changed in years whereas the technology advanced a lot, with much higher IPC, wider adoption of OoOE, probably more robust allocation of jobs in multi-core and multi-threaded CPUs, advancements in cache management, etc. There must be quite a few places where the old code could be improved. I'm very happy it's finally happening

[plaamook]

I regular came back here to read about the new beta and all i can read here is about other stuff...

Any news about the beta which can be shared?

literally in the same boat haha was expecting some wows and maybe some woes? but just dolphins, bats, and casio recorders.

Bit of a shot in the dark but maybe it's because dolphins and bats and recorders are more interesting than loads of people saying they can't discuss the Beta publically?

[selig]

Can anyone shed any light on this at all?

Adding support for VST3 on top of VST2 would be less work than initially adding VST2 support from nothing. VST3 adds more features to the host interface that would have to be included.

These include an actual API for MIDI I/O, which would require Reason to support MIDI filter VSTs. There's no official way to do it in VST2, it's more of an agreement with plug-in makers and DAW designers.

Sample-accurate automation, rather than MIDI-clocked automation. Reason is somewhere between that; automation events are sent once per batch, which is sample-based, not MIDI-based, but you can't change a parameter every sample.

VST3 instruments can offically receive audio, rather than being an effect that receives MIDI notes. Reason already set up for this type of audio routing, so it wouldn't involve any big changes.

So yeah, adding VST3 support wouldn't be as large an undertaking as adding/improving the initial VST2 support. The VST3 spec was mostly to formalize a lot of things VST2 developers and DAW companies were already making work, but weren't officially part of the spec.

Will Reason one day support VST3? I'd like to think so. Will it be in 10.3? No.

This is what I think of when I read stuff like this (from the excellent The Patriot):

Sent from some crappy device using Tapatalk

[Magnus]

Why can't another member of the forum speculate based on facts - is it not exactly the same thing you are doing?

Don't know specifically what you're referring to here, but sure, speculate all you want.
The world will be a better place when we can start to ignore logic and facts and start spreading rumors based on coincidence and opinionated reasoning.

There's no problem in the world you can't spin around and make it sound like the root cause for it was factor X with some help of the internet.
Always some other users out there who has experienced something similar, so it must be a connection there, even if there's not a shred of logic backing it up.

Roger Out.

Hey CloudsOfSound, I know it's rubbish when things are going bad in the real world and you despair for the species and all that; but the aggression in your response to me was completely irrational and certainly not in keeping with the spirit of the community here.

My speculation is based on real-world experience of performance on HiDPI Macs where this checkbox is not ticked (and I believe it is unticked by default for Reason on HiDPI Macs):



This entire thread is about an update that explicitly addresses performance in Reason. It's perfectly reasonable to discuss personal experiences with performance across different versions, operating systems and computers and see if there is a common ground that explains perhaps why myths have become established around Reason's performance in later versions.

Here's hoping that the 10.3 update re-establishes Reason's reputation for being one of the most CPU efficient DAWs for making music on both Windows and Mac!

[mcatalao]

It will never run as lean as Reaper. Reason is way more complicated than Reaper ever has been or likely will be (but that's a topic for another thread)...

you realize Reaper has had the ability to freely route audio from anywhere to anywhere and modulate any signal with any other signal since years ago right? maybe you mean that Reapers gui will never be as complicated as Reason's given the hardware paradigm? i'm not sure how you get any more "complicated" in terms of functionality (without going completely modular like Usine and all the recent Eurorack sims like vcv and vm) than the ability to route anything to anything else and modulate anything with anything else - it's also semi-adopted the Podium paradigm of hierarchical audio routing. Reason is simpler in every way except graphical presentation imo.

Reaper can "freely" route audio but always in the context of tracks and mixer channels. Yes you can route from channel A to B, you can double route, from a to b to c, and so on. But Reason routes infinitely freely outside of the context of a mixer channel because you can route anything to anything (whereas repear only almost does any to any - you cannot rout vst 1 to vst 2 without the context of the track channel and even an effects chain needs to be inside a track ).. To make things clear, you end up having context on a mixer channel because you need the audio to be routed to a channel. But the context of reason, is a device. The context of reason and routing is basically from an output to an input (same for CV). On any kind of device. On any type of channel. On any context. Input to output, output to input.

Mixing all the stuff in a single kind of track (reaper) it makes the freaking software SO CONFUSING that most of my friends that try to work with it cannot grasp it and the simple context of making a send for them is well... hideous! Trying to explain the context of a send to someone that only worked with Reaper is a tremendous effort, almost as odd as creating a send in Reaper. For a send in reaper, you have to create a track and route everything to that track. To define the send amount, you have to enter inside the routing section and define the routing volume. This is so convoluted, that imho, this is hideous to work with.

In reason, you have 8 sends always available in front of your nose. You want to modulate cv, you turn your stuff back and drag something from one place to another. You want to save 17 nn XT's in a patch, you toss them in a combi and have a new instrument. You want a vocal processor that you use on most of your vocals, you toss 10 devices in a combinator and you are a happy man and reuse whenever you need.

As for modulation i don't even know (or care tbh) for how reaper does it. Reaper has the sad characteristic of being one of the DAWS that evolves very quickly, responds to most of their user base needs with lack of criteria. In result and to respond to as much requests as possible, my feel is that it is a complete confusing mess.

I don't claim reason is the Best DAW in the world, but at the moment it is the best and most creative daw for me.

That being said, i kind of question if we should be discussing reason vs other daws in this thread. I'll try to refrain from it now on.

[EnochLight]

Reaper can "freely" route audio but always in the context of tracks and mixer channels. Yes you can route from channel A to B, you can double route, from a to b to c, and so on. But Reason routes infinitely freely outside of the context of a mixer channel because you can route anything to anything (whereas repear only almost does any to any - you cannot rout vst 1 to vst 2 without the context of the track channel and even an effects chain needs to be inside a track ).. To make things clear, you end up having context on a mixer channel because you need the audio to be routed to a channel. But the context of reason, is a device. The context of reason and routing is basically from an output to an input (same for CV). On any kind of device. On any type of channel. On any context. Input to output, output to input.

Mixing all the stuff in a single kind of track (reaper) it makes the freaking software SO CONFUSING that most of my friends that try to work with it cannot grasp it and the simple context of making a send for them is well... hideous! Trying to explain the context of a send to someone that only worked with Reaper is a tremendous effort, almost as odd as creating a send in Reaper. For a send in reaper, you have to create a track and route everything to that track. To define the send amount, you have to enter inside the routing section and define the routing volume. This is so convoluted, that imho, this is hideous to work with.

In reason, you have 8 sends always available in front of your nose. You want to modulate cv, you turn your stuff back and drag something from one place to another. You want to save 17 nn XT's in a patch, you toss them in a combi and have a new instrument. You want a vocal processor that you use on most of your vocals, you toss 10 devices in a combinator and you are a happy man and reuse whenever you need.

As for modulation i don't even know (or care tbh) for how reaper does it. Reaper has the sad characteristic of being one of the DAWS that evolves very quickly, responds to most of their user base needs with lack of criteria. In result and to respond to as much requests as possible, my feel is that it is a complete confusing mess.

I don't claim reason is the Best DAW in the world, but at the moment it is the best and most creative daw for me.

That being said, i kind of question if we should be discussing reason vs other daws in this thread. I'll try to refrain from it now on.

All great points. I'll add that, while I'm sure Justin Frankel is a great guy, it's clear that his experience in creating a file-sharing app (Gnutella, which was mostly used to pirate music) and a music player (WinAmp, mostly used to play said pirated music), didn't prepare him for the intricacies of creating a proper DAW ecosystem that's... inspiring. While he and John Schwartz respond to user requests and update Reaper frequently, you can tell that it was from a couple of guys that didn't really have the experience necessary to create an environment as easy to get around and produce in compared to most other DAW on the market. John's experience in plugin creation helped Justin a great deal, though (IMHO).

I know Reaper has its legions of fans, but I just couldn't get into it. I tried, though. Man how I tried.

[CloudsOfSound]

Hey CloudsOfSound, I know it's rubbish when things are going bad in the real world and you despair for the species and all that; but the aggression in your response to me was completely irrational and certainly not in keeping with the spirit of the community here.

I apologize for being so harsh, it was not called for, and I realize now that I was stretching the limits of what should be tolerated on this forum.

I had a really, really bad day, but that doesn't justify behaving like an ass in any way.

Hope you and Selig can accept my apology. I'll think twice before burping out like that again.