ReasonTalk.com

Hypothetically speaking...How would all of you react to Reason getting a literal rewrite in later versions.
Is this something Propellerhead should consider doing in later iterations?

Rewriting an application that has grown over more than 10 years is pretty expensive

But refactoring, optimization and so on must happen soon or the product will be outdated and unmaintainable soon, i guess.

Oquasec wrote: ↑

08 Dec 2017

Hypothetically speaking...How would all of you react to Reason getting a literal rewrite in later versions.
Is this something Propellerhead should consider doing in later iterations?

The current usability of Reason is fine imo that is GUI and current feature set, although they could do with some upgrades. However optimization should be the number 1 priority right now. I'd rather be able to have the ability to finish a project without needing to bounce all tracks that have VST's on them and I use VST effects mostly. There is no substitute for having the chain of effects. When you bounce the audio you have to open the previous state of the bounce again to back a compressor ratio off or just take a little bit of feedback on the delay out of this part!

I would not be comfortable with a lot of visual changes.

The question to ask the devs:
"If you were to write Reason (or a DAW like Reason) today, from scratch, around today's hardware and code, would it be significantly different/better/more efficient than Reason 10 as it stands?"

Bitwig and Studio One could be seen as relating to this question.

Don’t think Reason needs a whole re-write, better optimisation with VSTs and upgrades to the graphics and devices (sooner or later) are a must though.


Sent from my iPhone using Tapatalk

Won't happen, Propellerhead can't even add 4 more Combinator buttons.

And Propellerhead never acknowledges any elephants in the room, and there's a lot of elephants.

Agree, won't happen. And personally I think they've been very good at architecture. The code has a clean interface, speaking of the SDK. The devices and the rules to how to design devices are very straight. Overall I think reason is very maintainable and in a good shape. They have been actively looking for devs extending Reason for scripting. Which would be amazing! I'd love to see python as scripting host in reason, as it is the most easy to learn an widely supported language. They tend to use lua, as it has a low performance cost, which I can understand. And they already use it in reason for different things. The most official and obvious the Remote Mapping tech. The only thing left, from my point of view would be an extended SDK for creating custom views. Some API for the Sequencer would be amazing, as well as defining alternative views for the devices. Sometimes it makes more sense to have one kind of control, and sometimes the other. Reason grew up with its hardware like look and feel, yet I wish to sometimes have more modern technologies for touch interfaces, multitouch and so on. To also get more of an instrument, rather then just being a workstation. All in all, I don't think there is a need to rewrite. The most amazing thing that could happen from my point of view is if they add something like Reaktor Blocks, but the reason way, being able to easily script things and design a modular UI.

Perhaps a better question might be: how do you feel about getting no new features while Reason's existing features are being rewritten?

they don't have the balls to write Reason from scratch, Only steve jobs can do that

joke aside Reason need a zoom in the Rack

dioxide wrote: ↑

08 Dec 2017

Perhaps a better question might be: how do you feel about getting no new features while Reason's existing features are being rewritten?

Damn good point mister.

Counterpoint: perhaps Reason doesn't need a full re-write from the ground up? Consider that Reason 1-5 was still probably the most efficient plugin suite on the market, we have little reason to believe that Propellerhead didn't approach Record (which later became Reason 6.0) any differently...

I really hope there's plenty of room for optimization, though, as clearly there is something amiss with VST support performance.

Psuper wrote: ↑

08 Dec 2017

And Propellerhead never acknowledges any elephants in the room, and there's a lot of elephants.

Like lack of VST support

dioxide wrote: ↑

08 Dec 2017

Perhaps a better question might be: how do you feel about getting no new features while Reason's existing features are being rewritten?

If it makes Reason easier for the Props to work on/with over the next 17 years, I'm totally fine with that.
Ableton seem to have spent 5 years making nested track groups, a wavetable synth, and an echo, so, y'know.

But it sounds like Reason is basically in good shape.

Reason Experience could be an answer IMO. Certain things could be the same as making a new bicycle of stuff that should remain being the same still - could be copy/pasted for it. But I think my other thread where I showed up how Reason sounded very nice, when routing it like that, should be an option in the future as well. My mind has visitors who think this too. Though, what should be rewritten and what not for you OP?
I have always been more like trying to sound better, not as much of wanting new conent that does nothing soundwise. (because we have these already now). Anyhow, I'd combine all the step sequencing tools into a massive solution, as example, because if you'd need all in one solution not, you'd just be happy with R10 alreaddy. That Knigh-Rider Kit's extras that Michael calls out, should be under the same roof for every All-InOne-Tool, so you wouldn't need to manually build too much and thinking routing too much either. Not sure why making software costs, when re-writting it - other than the wage of the Team - as CC+ and other tools are already bought.

My 0,2 Cents of Afican money anyway.

EdGrip wrote: ↑

08 Dec 2017

Psuper wrote: ↑

08 Dec 2017

And Propellerhead never acknowledges any elephants in the room, and there's a lot of elephants.

Like lack of VST support

And Propellerhead never acknowledges any elephants in the room, and there's a lot of elephants. Unless it's been at least 6 years since users overwhelmingly demanded it... like Audio In too!

Better?

If Reason 10.5 is only a "major overhaul" of the audio-engine to fix the VST performance (so that it's on-part with all other DAWs), I'd be thrilled.

When I was a Sonar user, they had a major release once where the only major improvement was the "audio engine" stability in perf. It was *awesome* to see VSTs become rock-solid (perf-wise especially). So if Reason did the same, I'd personally be happy. I hope they don't follow-suit on other things Sonar did (like go out of business).

I think it's showing its age pretty badly. This happens to all long-running software projects eventually. It is a testament to how well put together it was that it has made it so far, but it looks so dated now. And I think their inability to really finish any features - VST support, theming etc is indicative of the fact that they are paralysed by the codebase. I doubt they have the finances for a full rewrite, but I hope so.

Could be wrong but didn’t someone post somewhere when the Props announced VST in 9.5 that he was one of the coders that originally programmed VST into Reason and that they did it many years ago but sat on the feature for ages??
Did I dream that?
Could it possibly be that where the VST implementation code is so old now that it isn’t best optimised as it should/could be?


Sent from my iPhone using Tapatalk

Only obvious problem is the locked 64 sample buffer on all VSTs. May be more, but that seems to be Reasons big mistep with VST.

I'm unaware of any other DAWS that purposefully force a VST to a sample buffer to anything other than the host default. Few computers can pull off a consistent 64 sample buffers on any cpu-heavy VST.

stephensmattlee wrote: ↑

08 Dec 2017

Could be wrong but didn’t someone post somewhere when the Props announced VST in 9.5 that he was one of the coders that originally programmed VST into Reason and that they did it many years ago but sat on the feature for ages??
Did I dream that?
Could it possibly be that where the VST implementation code is so old now that it isn’t best optimised as it should/could be?


Sent from my iPhone using Tapatalk

IFAIK I remember reading the re coding from scratch happened when R6 was released. Better faster is always what I want. I don't believe I would "feel" anything. I don't care if GFA Basic 32 will make R11 fly. As long as I am happy using a better product. I doubt PH would want a different outcome for their faithful customers. It would make zero business sense to purposely slow down your product.
Anyway I already set my mind to go hardware (Elektron) if PH dies 150 years from now

Tumble wrote:

stephensmattlee wrote: ↑

08 Dec 2017

Could be wrong but didn’t someone post somewhere when the Props announced VST in 9.5 that he was one of the coders that originally programmed VST into Reason and that they did it many years ago but sat on the feature for ages??
Did I dream that?
Could it possibly be that where the VST implementation code is so old now that it isn’t best optimised as it should/could be?


Sent from my iPhone using Tapatalk

That’s the one. Wow, 10 years ago??! Didn’t realise it was that long ago, would that mean the code was written around the time of Reason v4? Or more realistically was it written to be a feature of Record that was left behind?

Is strange to think they had VST implemented in the code and yet decided to go the Rack Extension route instead not long after.


Sent from my iPhone using Tapatalk

Psuper wrote: ↑

08 Dec 2017

Only obvious problem is the locked 64 sample buffer on all VSTs. May be more, but that seems to be Reasons big mistep with VST.

I'm unaware of any other DAWS that purposefully force a VST to a sample buffer to anything other than the host default. Few computers can pull off a consistent 64 sample buffers on any cpu-heavy VST.

I could be wrong but I think it has to do with this implementation having been coded years ago, so it seems.
Back then it would be coded as such, with a locked sample buffer ?

And now it is obviously a serious issue. F.e. the Air plugins seem very badly affected in reason because of this locked sample buffer, causing major instability. Weirdly in Win7, it seems a lot better, and things like Xpand and Hybrid don't seem to have the same issues...

Nevertheless, I believe props are smart enough to now be focusing on improving the most obvious issues first, which would be the locked 64 sample buffer. I think they'll try to correct that for the 10.5 point release, and that this alone would offer a lot more stability for VST in reason allround.

The next reason should also DEFO be about the best ever DSP at least.

Very curious to see what v10.1 might have in store. I’m sure optimisation must be one of the main priorities but I guess we’ll have to wait and see what Props have in store


Sent from my iPhone using Tapatalk

Honestly I don't want a major rewrite since that is likely going to come with more overhead and computer resource demands.
It would be nice to make the rack look cleaner and 3D but that comes at a cost.
People that suggest a rewrite for something have never coded anything more than "Hello World".