Why no multi-timbre instruments ?

This forum is for discussing Propellerhead's music software. Questions, answers, ideas, and opinions... all apply.
enossified
Posts: 25
Joined: 15 Aug 2016

Post 14 Jan 2020

bitley wrote:
12 Jan 2020
I reading some Craig Anderton article from the summer of 1985? ;-) While that sounds cool "on paper" it's not as the CZ engine struggles so hard it's insane.
My first synth was a CZ-5000, basically two CZ-101s in a single unit with 61 full size keys and 8-part multitimbral plus an 8-track linear sequencer...a workstation in today's terminology. It was very usable, much simpler to operate than a CZ-101 in multi mode. I used workstations as my prime synth right up until I sold of all my hardware at the end of 2017.

Multitimbral polysynths made sense to me because they were economical. The CZ-5000 could do the work of multiple instruments (as many as 8) and a sequencer (in those days, a relatively expensive hardware box). Within a few years, workstations came with multiple FX processors, too. In 2005, I purchased a Motif ES6...16 parts, 128 voices, 18 FX processors, internal mixer with EQ and send busses...and replaced four MIDI instruments, five FX processors, a mixer and a patchbay.

As others have noted, Reason itself began as a software implementation of a workstation....multitimbral, sequencing and effects in one device. It wasn't really a DAW in the early days since it didn't record audio, output MIDI or support plugins...it was a standalone application that accepted MIDI input and supported multiple channels of audio output. Within a year, I bought Reason 2.5, slaved to the Motif as an expansion device and ran the output of both into my hardware multitrack recorder.

Since Kontakt has been mentioned, keep in mind that Kontakt is not just a plugin, it's also a standalone instrument (I think Massive X is the sole NI instrument that is only a plugin...even Komplete Kontrol runs standalone) that can be run outside of a DAW. This is also true of IK's SampleTank, Arturia's V-Collection and Korg's Legacy Collection. It makes perfect sense for these to be multitimbral.

No DAW handles multitimbral plugins well because of the inconvenience of routing multiple MIDI channels into the plugin and routing multiple audio outputs. In every DAW I've used to date a multitimbral plugin like Kontakt or SampleTank requires setting up 16 MIDI tracks and 16 audio tracks. In many usage models, it's simpler to instantiate multiple instances of the plugin. The orchestral library case is one of the exceptions.

Busta US
Posts: 160
Joined: 26 Oct 2019

Post 14 Jan 2020

Re8et wrote:
14 Jan 2020
Multi-timbral synths are hard to find in the real world, let's take Roland boutiques, which are essentially VST's packed inside a shell.
The Jp-08 has percussions, bass, leads, horns, etc... and 4 voices.
Theoretically it could deliver a song, but no, it's mono-timbral, and does not have (of course) multiple outs.
I see it as a poor design choice, but I am talking real world hardware.
I'd never guessed the occurrance of it would've even been talked about in Reason environment to this day.
My 2 cents on Reason as a totally new user is that it excels in emulating hardware gear but seems to only stop there. Would've been nice to take advantage of the digital DAW world and make the best of both worlds...

Busta US
Posts: 160
Joined: 26 Oct 2019

Post 14 Jan 2020

orthodox wrote:
14 Jan 2020
One way of quickly implementing that feature could look like a Combinator-style Programmer section on top of the Reason Rack Plugin, where you could select which devices receive notes on which midi channels. The RRP is already a sort of Combinator after all, just you cannot block instruments from receiving notes & performance cc and individually transpose them, so that could be a good feature for everyone.

As for adding midi channels to the Reason sequencer, let alone implementing the full MIDI standard, I think this would be a mission impossible.
:lightbulb: :lightbulb: :lightbulb: :exclamation:

User avatar
jam-s
Posts: 885
Joined: 17 Apr 2015
Location: Aachen, Germany

Post 14 Jan 2020

orthodox wrote:
14 Jan 2020
One way of quickly implementing that feature could look like a Combinator-style Programmer section on top of the Reason Rack Plugin, where you could select which devices receive notes on which midi channels. The RRP is already a sort of Combinator after all, just you cannot block instruments from receiving notes & performance cc and individually transpose them, so that could be a good feature for everyone.

As for adding midi channels to the Reason sequencer, let alone implementing the full MIDI standard, I think this would be a mission impossible.
I disagree with your last statement. Imho a pretty good way to implement it would be to (finally) introduce virtual midi cables and sockets for all midi capable devices. in addition they would introduce midi splitter and merger. the splitter would have the additional option to filter each of its outputs to just a single midi channel. And if the ex-props wanted to go a bit further they would introduce an advanced midi message editing device and also transmit MPE data etc.

In the sequencer it could be a simple dropdown like the regroove channel to select the midi channel that the midi notes should be output to.
If you're in Aachen, come and visit us at the Voidspace.

User avatar
orthodox
Posts: 940
Joined: 22 Jan 2015

Post 14 Jan 2020

jam-s wrote:
14 Jan 2020
I disagree with your last statement. Imho a pretty good way to implement it would be to (finally) introduce virtual midi cables and sockets for all midi capable devices. in addition they would introduce midi splitter and merger. the splitter would have the additional option to filter each of its outputs to just a single midi channel. And if the ex-props wanted to go a bit further they would introduce an advanced midi message editing device and also transmit MPE data etc.

In the sequencer it could be a simple dropdown like the regroove channel to select the midi channel that the midi notes should be output to.
The problem here is not in the UI logic of how it could be done. I used to suggest the same thing about MIDI cables and processing utilities. Now I think that a hell of a lot of existing code and public interfaces is built upon the current midi stream format, so changing it is comparable to rewriting Reason.
Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise. -- L.Carroll

User avatar
Benedict
Posts: 2129
Joined: 16 Jan 2015
Location: Gold Coast, Australia

Post 15 Jan 2020

orthodox wrote:
14 Jan 2020
jam-s wrote:
14 Jan 2020
I disagree with your last statement. Imho a pretty good way to implement it would be to (finally) introduce virtual midi cables and sockets for all midi capable devices. in addition they would introduce midi splitter and merger. the splitter would have the additional option to filter each of its outputs to just a single midi channel. And if the ex-props wanted to go a bit further they would introduce an advanced midi message editing device and also transmit MPE data etc.

In the sequencer it could be a simple dropdown like the regroove channel to select the midi channel that the midi notes should be output to.
The problem here is not in the UI logic of how it could be done. I used to suggest the same thing about MIDI cables and processing utilities. Now I think that a hell of a lot of existing code and public interfaces is built upon the current midi stream format, so changing it is comparable to rewriting Reason.
I also agree with this. Easy to say at the pub, harder to incorporate the "business logic", even harder to build without breaking what makes the app what it currently is.
(one of the first things I was taught when selling databases)

A total rework of Reason can easily break one of the core promises that an R1 file opens and works the same in R11 (altho never the other way seeing R1 didn't have THor - how did we live back then!).
A total rewrite could also essentially change the whole workflow that is the real core of Reason (much as we like to think it is Thor).

:-)

User avatar
jam-s
Posts: 885
Joined: 17 Apr 2015
Location: Aachen, Germany

Post 15 Jan 2020

orthodox wrote:
14 Jan 2020
The problem here is not in the UI logic of how it could be done. I used to suggest the same thing about MIDI cables and processing utilities. Now I think that a hell of a lot of existing code and public interfaces is built upon the current midi stream format, so changing it is comparable to rewriting Reason.
In my theory RS/props have been working on this fundamental rewrite since the introduction of RackExtensions. In this theory the updated devices (DrOctorex, RV7000 mkii) have already been ported to a new api that is most likely very similar to the RE api. Some more behind the scene refactoring of the code will most likely have happened during the VST performance update which took much longer than expected to be ready. So even so as this is highly speculative I really hope that the very slow speed of progress is because of lots of behind the scene preparation for the needed updates to the graphics and core midi/processing stack.
If you're in Aachen, come and visit us at the Voidspace.

NostraDAWmus
Posts: 25
Joined: 26 Jul 2019

Post 16 Jan 2020

bitley wrote:
13 Jan 2020
NostraDAWmus wrote:
12 Jan 2020


I bought your WBF Kontakt version in addition to the RSN version, just to overcome the lack of MIDI multi mode in the RSN VST3 Rack,- at least for some sounds though ...

Now, we´ll get MIDI 2.0 and Roland offers the 1st 88 weighted keys controller supporting MIDI 2.0 via USB-C, we get better resolution and MUCH more controller numbers.
Reason HAS to step up w/ user assignable MIDI channels and controller assignment for EACH single device in the RSN Rack/ VST3 Rack !
I really wonder why this is soooo difficult. :roll:

P.
Thanks for that!

It's easy to explain. Reason has like say 2 million rows of code. There are about 20 developers. The todo list has 200 constant entries. Small company, very very large task operation. Leadership has to decide on what is most important all the time. Will all customers always be happy? No. Are all Windows 10 users happy then, since Microsoft probably has 20,000 developers? The answer is no there as well.
2mio rows of code ... o.k.,- but that´s not the damn VST3 rack.

A VST is a VST is a VST ...

Look at the Arturia M12 which is an photorealistic emulation of the Oberheim Matrix-12 at 1st glance.
In fact it´s code and when you look into the "Multi-Patch" page, you´ll imagine it works like a virtual rack,-
individual single patches nested in individual slots being assigned to the same or individual MIDI channels, receiving MIDI notes and individual as also global controllers,- and this toy offers a "favourites" bank where you collect your favourite patches which surprisingly THEN are recallable via MIDI program changes, similar to 64Bit Uhe synths offering the "user" bank or many NI devices (p.ex. FM8 program list !).
NI Kontakt hosting multiple programs/patches regardless of standalone or plugin mode si the better example for a rack though and even there are limitations w/ MIDI program changes.

While the "favourite" and "user" banks along w/ MIDI PrgChange issue in many VSTs is independent from MIDI Multi Mode, it´s an indicator there are ways working around some new and nonsense VST specs like obsolete "MIDI PrgChanges" nonetheless.
They shouldn´t be,- serious keyboard players need ´em,- and the y also need MIDI Multi Mode and multitimbrality as well.

It doesn´t matter if it´s a synth or "rack",- it´s a VST which obviously is based on a standard offering these possibilities and only the manufacturer decides for implementation.

It´s also questionable if everything has to be a VST3 now and even Steinberg wants it hat way.
Some thing are obviously easier to realise in VST2 64Bit SDK than in VST3 w/ it´s many restrictions.

:puf_smile:

P

User avatar
esselfortium
Posts: 1270
Joined: 15 Jan 2015

Post 16 Jan 2020

A basic implementation that would satisfy 95% of people's usage needs would be to allow a MIDI channel to be specified per note lane in the sequencer.

The remaining 5% would be sending Players and CV to individual MIDI channels, which could be most simply achieved with something like the EMI device. This would avoid the need to add MIDI cables to the rack paradigm, and would match with what Reason is already doing for external MIDI devices.

I think having both solutions is crucial, because the sequencer method is simplest from the user side and requires no extra routing shenanigans while composing, and the EMI method can be used for advanced situations where the user wants to get funky with MIDI/CV experimentation.

User avatar
Jackjackdaw
Posts: 337
Joined: 12 Jan 2019

Post 16 Jan 2020

esselfortium wrote:
16 Jan 2020
A basic implementation that would satisfy 95% of people's usage needs would be to allow a MIDI channel to be specified per note lane in the sequencer.

The remaining 5% would be sending Players and CV to individual MIDI channels, which could be most simply achieved with something like the EMI device. This would avoid the need to add MIDI cables to the rack paradigm, and would match with what Reason is already doing for external MIDI devices.

I think having both solutions is crucial, because the sequencer method is simplest from the user side and requires no extra routing shenanigans while composing, and the EMI method can be used for advanced situations where the user wants to get funky with MIDI/CV experimentation.
Exactly this.

chaosroyale
Posts: 334
Joined: 05 Sep 2017

Post 16 Jan 2020

I really hope you are right. Nothing would make me happier than an announcement from RS that Reason 12 will be a new "generation" of the Reason core, building upon the optimization from 11, with stock devices remade as RE, and a new UI. I would be happy to lose 100% backwards compatibility (something they already broke years ago with line6 and again with R11/rewire, so it is not a strict policy any more, and I think that's fine if it means gaining modern performance).
jam-s wrote:
15 Jan 2020
In my theory RS/props have been working on this fundamental rewrite since the introduction of RackExtensions. In this theory the updated devices (DrOctorex, RV7000 mkii) have already been ported to a new api that is most likely very similar to the RE api. Some more behind the scene refactoring of the code will most likely have happened during the VST performance update which took much longer than expected to be ready. So even so as this is highly speculative I really hope that the very slow speed of progress is because of lots of behind the scene preparation for the needed updates to the graphics and core midi/processing stack.

User avatar
bitley
Posts: 1309
Joined: 03 Jul 2015
Location: sweden

Post 16 Jan 2020

Solving the question of addressing reason instruments via midi channels has been possible since 1.0 as the hardware interface in the top of the rack lets us do this. So you might use any other seq and use your (this Reason) computer as a sound module. 64 channels can be assigned if you have a four by four midi interface. Cubase on Atari comes to mind as it's a legendary MIDI seq so there are possible solutions ready and waiting. If you can work with a dedicated hardware sequencer and don't need the visual guidance so much there are Akai MPCs with four MIDI outputs so that could be fun. The MPC is a wonderful keyboard sequencer.

User avatar
esselfortium
Posts: 1270
Joined: 15 Jan 2015

Post 16 Jan 2020

bitley wrote:
16 Jan 2020
Solving the question of addressing reason instruments via midi channels has been possible since 1.0 as the hardware interface in the top of the rack lets us do this. So you might use any other seq and use your (this Reason) computer as a sound module. 64 channels can be assigned if you have a four by four midi interface. Cubase on Atari comes to mind as it's a legendary MIDI seq so there are possible solutions ready and waiting. If you can work with a dedicated hardware sequencer and don't need the visual guidance so much there are Akai MPCs with four MIDI outputs so that could be fun. The MPC is a wonderful keyboard sequencer.
This is unrelated to what's being asked for, and does not allow you to send notes or automation to the other midi channel inputs of VSTs that support multiple midi inputs.

User avatar
bitley
Posts: 1309
Joined: 03 Jul 2015
Location: sweden

Post 16 Jan 2020

I thought some of those requirements was up anyway :)

User avatar
adfielding
Posts: 597
Joined: 19 May 2015

Post 17 Jan 2020

I would LOVE to see native multi-timbre instrument/multi-MIDI channel support in Reason. Since VST support was introduced I've been using Kontakt a ton, and I always end up with a mess of devices & sequencer lanes when working with orchestral stuff.

The Kontakt example isn't a total show-stopper as you can just throw more Kontakt instances at the problem, but I picked up a Virus Snow Ti last year and - while I absolutely love it - it's currently impossible to sequence more than one part at a time using the plug-in without using a workaround. The Snow supports 4-parts, but in Reason you can only use one. Given that the Total Integration aspect of the Virus was a large part of the appeal for me (besides the sound, obviously!), this is kind of a bummer.

Thankfully, I managed to get a workaround up and running using Element, LoopBe and the EMI devices - but this is a messy solution to something that shouldn't really be a problem in the first place.

  • Information
  • Who is online

    Users browsing this forum: EdwardKiy and 19 guests