Random thoughts on MIDI

Official support for: mutools.com
Post Reply New Topic
RELATED
PRODUCTS

Post

mutools wrote:{...MuLab...} only handles up to 16 MIDI input channels (up to 8 input ports are internally merged into 1 virtual MIDI input port = 16 chans)...
I've been thinking about this for quite a while. I'll start by saying this is "blue sky" stuff and in no way a feature request -- I've no idea how much demand there is for it (though I know there is some, as there is for so many features).

When I push "Record" and MIDI is enabled, what I want to happen is all incoming MIDI events get recorded until I hit stop. That's the easy bit to explain, I guess.

But what do I want to do with those events?

Well, one of the source devices was a three-manual plus pedals organ transmitting on four channels.

One was a MIDI Wind Controller.

One was a multi-track sequencer triggered from an external hardware set up and capable of transmitting on sixteen channels all by itself.

... etc...

That's not an excessive MIDI set up. Just three MIDI input ports easily copes. Of course, you couldn't do the "old fashioned" 80s daisy-chained MIDI cable approach as you'd potentially run out of channels. And you might also hit problems if both the organ and wind controller refuse to give up channel 1.

Somehow, when I hit record, it's got to "just work", though, without too much thought.

Now, before I get as far as recording, I'll have had to do some set up to get any sound, of course. Each of those organ manuals will need assigning - possibly all to the same rack with a nice-sounding organ but equally possibly to multiple racks with completely different sounds... or some combination. The wind controller probably has a single rack containing its target sound module (which could be anything...). The sequencer is a bit of a headache immediately: do I really want 16 racks? No, I probably want one with a MuX in to "hide" the complexity - channel split and route inside the MuX. (I'll likely have done the same with the organ - there's no rack MIDI send, as far as I can see.)

When I hit record, I can now think: "Ah, I'll need to send these events to these targets in future, so I'll need to keep them in separate parts" -- and then the parts, as they're concurrent, demand separate tracks in the MuLab sequencer. So we have a one track per rack paradigm appearing. This is probably exactly what everyone already expects...

There's still the "but MuLab doesn't support more than 16 channels" bit to overcome. As I understand it from Jo's quote above, MuLab knows about multiple MIDI ports but chooses to merge them ahead of all other processing currently. This is why there is currently no need for a "Session Event Input" module. However, routing is still something that has to be set up (either as follow focus or explicitly).

I think conceptually the easiest thing would be to have one or more "Session Event Input" modules. This could be associated with one or more MIDI input ports, merge their MIDI events and output MuLab events, as is currently done. The new module could also provide the same routing as is currently present but it could also offer the user a more visual approach to routing, using Session MuX.

This scales well: in the simplest case of one input, the behaviour is exactly as at present. MIDI set up would be where you decided whether you wanted a MIDI port to have its own Session Event Input or which existing one to merge events into. When you add a second port, it can still be just as easy as it currently is by default but you also have the flexibility to keep the events separately routed.

So, at this stage, we can hit record and the output from each Session Event Input gets a track for each of its targets.

Post

Hey pljones, thanks for your interesting post. I'm gonna take a bit of time to reread and think about this conceptual topic. Currently quite focused on some other coding tasks and want to profit of the good flow of that. Will get back on this interesting one asap.

Post

pljones wrote:I think conceptually the easiest thing would be to have one or more "Session Event Input" modules. This could be associated with one or more MIDI input ports, merge their MIDI events and output MuLab events, as is currently done. The new module could also provide the same routing as is currently present but it could also offer the user a more visual approach to routing, using Session MuX. This scales well: in the simplest case of one input, the behaviour is exactly as at present.
Not true i'm afraid because how it's done now you can route MIDI input to any module, i.e. in the SMA or deeper. While if the event input modules are in the SMA you can only directly route them to modules in the SMA. There is a way to route them to deeper to, but that will take extra steps.

Anyway, i appreciate the essence of your post, and i also would like to make the MIDI input system more compliant with the rest of MU. This topic is related to supporting real parallel MIDI inputs, and also to the often requested Event Recorder module. It will take some extra thought.

Post

I wasn't suggesting taking away the current method of managing the routing -- that would remain and continue to happen "behind the scenes" if used, even if the module were in the SMA. The "visual routing" would only work at the level the module was inserted into, as with the existing Event Input module. A "Session Event Input" would only be able to route to SMA modules, yes: visually. But using the existing routing scheme, it could continue routing wherever, such as an Event Input module in a lower level. (I accept that's not necessarily visually "transparent" but unless you enforce cascading outward of event input points, I don't see a neat way around it. I was assuming such cascading would be overly complicated but maybe it's not.)

Post Reply

Return to “MuTools”