How big of a feat would it be to add MPE and CLAP compability?

[Mr. Rodent]

Now that we're finally getting VST3, these would be some possible next steps (especially MPE) to bring Reason back to relevancy.

Having RRP as a CLAP plugin would allow some sweet polyphonic modulations in Bitwig for example.

Also sadly I'm not using the rack nearly not as much anymore after getting a MPE controller Most likely I won't be updating my Reason 12 or subbing R+ until (if ever) that happens.

What do you think, would these things be a possibility in the future? Or does Reason have too much technical debt? My programming skills limit to printing hello world, so I got no idea.

[Jac459]

I think it is very difficult to know about their technical debt.
The extra high level of modularity you feel in Bitwig is what allow them to be extremely fast and agile in the way they develop. These concepts of modularity are more advanced now (since about 10 years roughly), using concepts like microservices, TDD, BDD approaches but are in fact existing since 25 years (again roughly).
This is what are called S.O.L.I.D. principles.
Basically, it relies on 2 main aspects:
1 - everything is encapsulated so when you modify one feature, you are 100% sure you are not fucking up something else somewhere else.
2 - everything is tested automatically so .... when you modify one feature, you are 100% sure you are not fucking up something else somewhere else.

These 2 aspects are what can change from night a day the productivity of a development team. If the 2 principles are there, and the architecture is full SOLID, the productivity can be more than 10 times higher than a team that doesn't have these principles in place.

My knowledge is only on banking industry, but from my experience, even if again these concepts were emerging at the time of reason creation, it was generally not followed at all like now. It was generally ok to have 20% unit test coverage versus today where we tend to 100% coverage.

Now my 2 cents is that Reason developers are better than usual developers and have regularly tidied up their code (refactored). It is quite expected that they had to do a big cleanup on the UI because the technologies/concepts/frameworks have changed an awful lot since 20 years. So I think that's a very good news for us.

Yet, seeing at how they focus on developing new stuffs (players, instruments) and not very much the core (at least from a customer perspective), I would think that they still have technical debts and issues to evolve the main product...

Therefor to answer your question I would be very surprised if MPE development doesn't require an individual refactoring of all their synths and RE API, in that sense I would guess it is quite a huge journey, significantly more than VST3.

That's only my thought, I may be also totally wrong .

[jam-s]

...
Yet, seeing at how they focus on developing new stuffs (players, instruments) and not very much the core (at least from a customer perspective), I would think that they still have technical debts and issues to evolve the main product...

Therefor to answer your question I would be very surprised if MPE development doesn't require an individual refactoring of all their synths and RE API, in that sense I would guess it is quite a huge journey, significantly more than VST3.

That's only my thought, I may be also totally wrong .

The new stuff that gets implemented are REs and those are usually done by a different developer (team) or even by 3rd parties as contract work. Thus they do not cut into the Reason core developer time.
My guess on why core development seems rather slow is that there are only a few skilled core C++ developers left at RS (at max two teams) and those can only focus on one thing at a time (each). So only after the HiRes got to an OK state they could really start on the threading model (for M1) and VST3 support. And looking at the roadmap MPE is not even on the table to be fed into the development pipeline.

[avasopht]

Implementing CLAP and MPE isn't much of a feat. They're just features.

CLAP is more involved than VST (unless they provide a framework/library that helps integrate it easily). But it's just a feature like any other feature. It's not elusive, and doesn't require arcane knowledge of obscure practices that only a small handful of developers know.

In terms of technical debt, C++ has seen some major advancements of the language over the last 20 years, but they won't require everything (or anything really) to be rewritten. The changes simply offer you newer (and often better) ways of doing things.

There's no reason to expect them to not have modular systems with an automated test suite that runs on various platforms.

[Jac459]

The new stuff that gets implemented are REs and those are usually done by a different developer (team) or even by 3rd parties as contract work. Thus they do not cut into the Reason core developer time..

That's not my point. My point is that it is way way way harder to go modify a code that has 20 years of history than to create a new component. That's why they are productive for new components and super slow for core modifications.

[Jac459]

Implementing CLAP and MPE isn't much of a feat. They're just features.

CLAP is more involved than VST (unless they provide a framework/library that helps integrate it easily). But it's just a feature like any other feature. It's not elusive, and doesn't require arcane knowledge of obscure practices that only a small handful of developers know.

In terms of technical debt, C++ has seen some major advancements of the language over the last 20 years, but they won't require everything (or anything really) to be rewritten. The changes simply offer you newer (and often better) ways of doing things.

There's no reason to expect them to not have modular systems with an automated test suite that runs on various platforms.

It seems that we don't have the same understanding of technical debt... It has little to do with c++, which is not an obsolete language, even if you are right to say that it evolves quite a lot. It has a lot to do with 25 years of software building which has created certainly an immense level of complexity.

And for the modular system with test suites as per modem standards, you may be right but I would be surprised. CI/CD and devops concepts were not at the same level of maturity and the tooling was far from today's standard.

[jam-s]

The new stuff that gets implemented are REs and those are usually done by a different developer (team) or even by 3rd parties as contract work. Thus they do not cut into the Reason core developer time..

That's not my point. My point is that it is way way way harder to go modify a code that has 20 years of history than to create a new component. That's why they are productive for new components and super slow for core modifications.

Well, and my point is that this does not apply here as development of new REs is orthogonal to the core Reason development regardless of the inner structure or technical debt in Reason itself. Which leads to your argument being of the non sequitur kind.

[Jac459]

Well, and my point is that this does not apply here as development of new REs is orthogonal to the core Reason development regardless of the inner structure or technical debt in Reason itself. Which leads to your argument being of the non sequitur kind.

The fact that you don't see the logic doesn't seems there is none my dear friend .

To streamline the reasoning:
- MPE is a core feature to develop.
- Experience shows us that developing core features is a struggle for RS
- This is consistent with my expectation of the technical debt they may have.
- the fact that they output much more RE than core features is in my view a sign of that but i accept that i may be wrong, it is just conjectures.

[EnochLight]

CLAP support will likely *NEVER* happen in Reason DAW. With MPE, the jury is still out - Reason Studios haven't made any effort to support it in VST2, but with VST3 in testing, we can only hope (though I'd wager we won't see MPE in Reason 12).

[selig]

The new stuff that gets implemented are REs and those are usually done by a different developer (team) or even by 3rd parties as contract work. Thus they do not cut into the Reason core developer time.

Understood. And…
#1–RS has finite resources, agreed?
#2–They choose how to allocate those resources, correct?

One way to allocate resources is to put some toward new REs and some toward core development.

I would think what folks are asking for here is for them to choose to put MORE resources into core development.
How they may currently allocate resources is therefore inconsequential because see #1 and especially #2 above.

[tallguy]

From what I've seen in other applications, core development takes years. To give the end users something during those years, the developers will often release lots of plugin style content.

[jam-s]

The new stuff that gets implemented are REs and those are usually done by a different developer (team) or even by 3rd parties as contract work. Thus they do not cut into the Reason core developer time.

Understood. And…
#1–RS has finite resources, agreed?
#2–They choose how to allocate those resources, correct?

One way to allocate resources is to put some toward new REs and some toward core development.

I would think what folks are asking for here is for them to choose to put MORE resources into core development.
How they may currently allocate resources is therefore inconsequential because see #1 and especially #2 above.

Exactly, and RS have been looking for new C++ devs for in-house development quite some time. I'm sceptical on their recruiting success as the last job offer I've seen required working in the office which limits their possible candidates quite a bit. So their in-house (=core) dev resources are likely pretty limited and have to be assigned strategically to cover the many different tasks like VST support, M1/M2 support, hi-res GUI, bug fixing, core feature requests, RE SDK improvements, etc.
When you cannot find enough good new employees for in-house development having 3rd parties do contract work using a stable interface (like the RE SDK) and just some feature specification (which can be done by the product lead or somebody with no detailed knowledge of the Reason core) is a good strategy and to me it looks like RS has been doing this for the last few years.
(Mathias also said in a thread here that RE development for the RS/Propellerhead branded REs would not cut into core development for Reason, thus I suppose my interpretation of the situation is not too far off from reality.)

When you're severely restrained by #1 then #2 can only try to get additional external resources because overallocation of developers does not work well and leads to drastically buggy software.

[selig]

Understood. And…
#1–RS has finite resources, agreed?
#2–They choose how to allocate those resources, correct?

One way to allocate resources is to put some toward new REs and some toward core development.

I would think what folks are asking for here is for them to choose to put MORE resources into core development.
How they may currently allocate resources is therefore inconsequential because see #1 and especially #2 above.

Exactly, and RS have been looking for new C++ devs for in-house development quite some time. I'm sceptical on their recruiting success as the last job offer I've seen required working in the office which limits their possible candidates quite a bit. So their in-house (=core) dev resources are likely pretty limited and have to be assigned strategically to cover the many different tasks like VST support, M1/M2 support, hi-res GUI, bug fixing, core feature requests, RE SDK improvements, etc.
When you cannot find enough good new employees for in-house development having 3rd parties do contract work using a stable interface (like the RE SDK) and just some feature specification (which can be done by the product lead or somebody with no detailed knowledge of the Reason core) is a good strategy and to me it looks like RS has been doing this for the last few years.
(Mathias also said in a thread here that RE development for the RS/Propellerhead branded REs would not cut into core development for Reason, thus I suppose my interpretation of the situation is not too far off from reality.)

When you're severely restrained by #1 then #2 can only try to get additional external resources because overallocation of developers does not work well and leads to drastically buggy software.

OK, I get all that but that's not my point. I accept that (at least according to Mathias) progress is likely going to remain slower at RS than other companies. I can still WANT things to progress faster, and as such am moving towards those companies who already do that. But I'd much rather stay 100% in the Reason environment.
Bottom line: I've got far too many synths as it is, as I can now load up my Komplete, V Collection, Korg Gadgets, UAD, PLUS everything Propellerheads and many 3rd party REs for an embarrassment of riches.
While I can easily add more and more instruments and effects to Reason, what I CANNOT do is add core features to Reason…

[jam-s]

OK, I get all that but that's not my point. I accept that (at least according to Mathias) progress is likely going to remain slower at RS than other companies. I can still WANT things to progress faster, and as such am moving towards those companies who already do that. But I'd much rather stay 100% in the Reason environment.
Bottom line: I've got far too many synths as it is, as I can now load up my Komplete, V Collection, Korg Gadgets, UAD, PLUS everything Propellerheads and many 3rd party REs for an embarrassment of riches.
While I can easily add more and more instruments and effects to Reason, what I CANNOT do is add core features to Reason…

I totally agree and really would like to see faster core DAW development as well. There's a widely known shortage of skilled coders (or rather tech/IT guys) in general. So the really good ones can be very picky demand things like 100% remote work which got hugely popular during the lockdown and still the job offer is looking for people who want to work at the office in Stockholm.

While I can understand why RS would prefer this, I can also imagine that they won't get many applicants for that offer and that opening up and going with the times could really help them in up-staffing their engineering department. (More so as quite a few tech companies in the US (Facebook, Twitter, Amazon, etc.) have recently laid off quite a few of their developers.)

If RS insists on keeping core development just in-house, I don't think they can do that much about speeding up and catching up to the competition. Still they could possibly do a lot to please us - once the big blockers (VST3, M1 support) are out of the way - by focussing on many little QoL features, bugfixes, and re-designs/improvements of the core DAW and built-in instruments and FX for the next iteration which would become R13.

[selig]

OK, I get all that but that's not my point. I accept that (at least according to Mathias) progress is likely going to remain slower at RS than other companies. I can still WANT things to progress faster, and as such am moving towards those companies who already do that. But I'd much rather stay 100% in the Reason environment.
Bottom line: I've got far too many synths as it is, as I can now load up my Komplete, V Collection, Korg Gadgets, UAD, PLUS everything Propellerheads and many 3rd party REs for an embarrassment of riches.
While I can easily add more and more instruments and effects to Reason, what I CANNOT do is add core features to Reason…

I totally agree and really would like to see faster core DAW development as well. There's a widely known shortage of skilled coders (or rather tech/IT guys) in general. So the really good ones can be very picky demand things like 100% remote work which got hugely popular during the lockdown and still the job offer is looking for people who want to work at the office in Stockholm.

While I can understand why RS would prefer this, I can also imagine that they won't get many applicants for that offer and that opening up and going with the times could really help them in up-staffing their engineering department. (More so as quite a few tech companies in the US (Facebook, Twitter, Amazon, etc.) have recently laid off quite a few of their developers.)

If RS insists on keeping core development just in-house, I don't think they can do that much about speeding up and catching up to the competition. Still they could possibly do a lot to please us - once the big blockers (VST3, M1 support) are out of the way - by focussing on many little QoL features, bugfixes, and re-designs/improvements of the core DAW and built-in instruments and FX for the next iteration which would become R13.

Thanks for your extremely detailed responses!

[avasopht]

It seems that we don't have the same understanding of technical debt... It has little to do with c++, which is not an obsolete language, even if you are right to say that it evolves quite a lot. It has a lot to do with 25 years of software building which has created certainly an immense level of complexity.

And for the modular system with test suites as per modem standards, you may be right but I would be surprised. CI/CD and devops concepts were not at the same level of maturity and the tooling was far from today's standard.

Well, you'll have a revised coding standard, and a fair amount of disconnect when linking with new code.

So sure, it's not "tech debt" per se, but they'll either have to disable warnings on their old code or spend a lot of time "modernizing" it (which IIRC was what they mentioned on their first roadmap). I consider delayed migration to new standards and build systems as a sort of tech debt, but maybe that's just me.

I guess my expectation of their tech debt differs from yours. Reason looks like its systems can be pretty self-contained, plus they're very conservative with adding features. Speculative. But I just don't think the 25 years of development would have accrued immense complexity.

Rack devices are completely isolated from the main DAW.

The most complexity might be found in the insane flexibility of the mix of time-stretching, Recycle, comping, and APE. You can hop between a few of them quite seamlessly.

The midi events editor is pretty simple. I won't say the same about the arranger window.

Their MIDI implementation is isolated from devices, which interface with Remote, which is fed into Jukebox (something like that, right?)

Of course I'm just speculating and I'm probably about 70% wrong .

I agree with the CI/CD devops.

For all we know, they could have the cleanest modern codebase of all DAWs.

But when it comes to MPE, I think they're already halfway there with how they've designed Jukebox and Remote. It will require work, but I don't see the same entangled mess you do.

My optimism may be my downfall

[buddard]

Having RRP as a CLAP plugin would allow some sweet polyphonic modulations in Bitwig for example.

That would not be guaranteed since polyphonic modulation is an optional extension to CLAP, so hosts/plugins are not required to support that particular feature.
See for example the latest version of Reaper that supports loading CLAP plugins but doesn't (at least no yet) support from polyphonic modulation.

[kitekrazy]

We have no idea since we can't be a flt on the wall. The (d)evolving OS probably takes time to make sure the main app works.

[Jac459]

Well, you'll have a revised coding standard, and a fair amount of disconnect when linking with new code.

So sure, it's not "tech debt" per se, but they'll either have to disable warnings on their old code or spend a lot of time "modernizing" it (which IIRC was what they mentioned on their first roadmap). I consider delayed migration to new standards and build systems as a sort of tech debt, but maybe that's just me.

I guess my expectation of their tech debt differs from yours. Reason looks like its systems can be pretty self-contained, plus they're very conservative with adding features. Speculative. But I just don't think the 25 years of development would have accrued immense complexity.

Rack devices are completely isolated from the main DAW.

The most complexity might be found in the insane flexibility of the mix of time-stretching, Recycle, comping, and APE. You can hop between a few of them quite seamlessly.

The midi events editor is pretty simple. I won't say the same about the arranger window.

Their MIDI implementation is isolated from devices, which interface with Remote, which is fed into Jukebox (something like that, right?)

Of course I'm just speculating and I'm probably about 70% wrong .

I agree with the CI/CD devops.

For all we know, they could have the cleanest modern codebase of all DAWs.

But when it comes to MPE, I think they're already halfway there with how they've designed Jukebox and Remote. It will require work, but I don't see the same entangled mess you do.

My optimism may be my downfall

Well, I think I 100% agree with your statement, on all aspects.

2 minor points:
I count the software factory as technical debt (on top of all you mentionned).
I think I also agree on the fact that you may be a bit optimistic. Not because I think RS doesn't have good developers (I am sure they are great) but because recent big delays are probably (not certainly, just probably) due to the complexity you are mentioning on the core DAW part.