note: this requires OS 3.1 (see beta thread )
In 3.1 you are able to select midi input and output devices separately, and also allocate separate midi channels.
but some have asked, is it possible todo more advanced configuration, and the answer is yes , in 3.1 there is much more flexibility
This video shows how you can have multiple midi controllers for input and also a ‘midi thru’ type functionality.
In this video I use one organelle connected to a normal usb hub , that then ‘controls’ 3 other devices, a midi sequencers (Pyramid) , a keyboard ( virus) and another Organelle via a USB host adapter (see other thread)
Its quite a fun setup…
(albeit slightly contrived, I could actually use either the Pyramid and Virus as a midi router )
a fun side note… The Pyramid + Organelle is a really fun, and powerful combo - the Pyramid can be bus powered off the Organelle, which is powered off my usb battery pack - will be creating a few multi-timbral patches in next few days, to play with this more.
more advanced configuration and tips
testing more advanced setups
something i should have said in the video, before you start editing files, make sure your controllers works as expected in the ‘simple case’ via the midi settings menu first… pretty tedious doing these changes, and finding the issue is something ‘simple’ further on down the line
Alsa midi vs OSS midi
in 3.1, I switched to using Alsa for pure data from OSS midi , because its so much more flexible, and better supported by hardware.
so far there have been no reports of hardware not working, but if you need to switch back to OSS midi this is still possible. however, unless you have very good reasons - I would advise against it.
(testing if you have issues is about the only reason i can think of)
create a file called pd-opts.txt , and place in either /usbdrive/System or a patch directory (if you only want for certain patches)
in this file place:
note: if you do this, then all the discussion in the video, and this post regarding aconnect are irrelevant, since this is only applicable to alsa.
it is possible to connect multiple devices using oss midi via -mididev in the pd-opts.txt fie, its very similar to alsa, except its doesn’t use virtual devices, and you need to determine the hardware names/addresses.
but this is left to the reader… use alsa
directories for patch_loaded/pd-opts.txt/mother.pd (etc)
which is used>, why? when?
so when a patch is loaded, the following priority is used
Patch directory -> System Directory -> root (e.g. /usbdrive, only patch_loaded.sh)
(yes, sdcard is also supported, but im keeping it simple here ;))
the idea is simple…
if you want a custom setup for a patch, use the patch directory
if you need a custom setup for ALL patches, due to your ‘hardware setup’ use the System directory
if you want to revert to the ‘standard menu’ , then you will need to delete the custom one
now the important thing here is… your not going to see this from the Organelle UI.
So, if you put one in system, it can be pretty confusing, if you forget and then start using the Organelle midi menu, and you see it makes no change!
so if you do start having custom setups, bare this in mind.
note: whilst doing the video, Ive noticed a small bug in 3.1b1, which means that the patch_loaded.sh will not work in the patch directory, only the root or System directory, this is now fixed, and available in 3.1b2
midi settings : midi enabled/channel
in midi settings, you can see midi enabled and midi channel
what do these really do? (hint: it might not be what you think )
the first thing that is very important to understand is regardless of these settings pure data receives (and can send on) all midi channels at all times!
(only alsa routing (aconnect) affects what midi data PD sees, and what it does not)
ie. if you set midi in : disabled, midi channel : 1,
if you put a notein, object in your patch, you will still receive note data sent to organelle on midi channel 2!
why? thats illogical
the reason is, these setting refer only to midi input/output handed by the mother patch (mother.pd)
, which in turn is only interested in how to map midi data to the ‘organelle keys/knobs’
consider midi output first…
if you have midi output ch = 2, then the organelle knobs , will send CC 21-24 on midi channel 2, and they keys, note on/off on midi channel 2… if you put midi out: disabled, this will stop entirely,
for midi input its similar
midi input ch=2, means CC 21-24 are mapped to the organelle knobs
for note on/off… these are mapped to ‘key events’ within the PD patch, which is what most organelle PD patches map to notes played. (rather than listening to notein directly)
given this, i repeat … midi in/ch midi out/ch refer to how and if midi data is mapped to the ‘organelle hardware’.
regardless of these settings, your pure data still receives and can send all all midi channels, using the underlying pure data midi objects.
this is particularly important and useful for multi-timbral patches
tip: midi enabled , refers to midi gate in the mother patch ie midi in : enabled = midiInGate = 1
when are settings applied?
patch_loaded.sh is used either when you do ‘save’ in the menu, or when you start a patch (just after its loaded, hence the name ;))
pd-opts.txt, is used when a patch is started (or restarted obviously)
if you editing via usb stick, your going to end up restarting patch, so wont see this, but if you edit the file directly (ssh or on HDMI screen) , generally you will want to restart the patch.
routing pure data output
so in the video I kept it simple and handled midi input , but what about output from pure data patches?
well as I eluded to in the video, this can also be changed
so in my example the default configuration had:
aconnect 36:0 128:0 aconnect 128:1 36:0
so pure data input and output was connected to the pyramid
what if i wanted the pure data output instead to be connected to my virus (32:1) , whilst input is still from the pyramid, simple
aconnect 36:0 128:0 aconnect 128:1 32:1
more sophisticated routing : virtual midi devices
as we have seen, when we route to pure data, the only way we can distinguish where the midi data is from (or going to) is by midi channel… i.e. your pure data patch cannot filter by device (or send to a specific device) , only to a midi channel
this is ok, for the most part, we have 16 channels, but what if we need more?
or what if the controller does not have the ability to specify midi channel (e.g. say you have 2 devices fixed to midi channel 1 output)
this can be handled in pure data by creating more virtual midi input/output device (128:0, 128:1 are virtual midi devices)
to do this we first need to tell PD to create more virtual devices, we do this with a command line option which can be added to a file we need to call pd-opts.txt, which can be placed in the System directory or patch directory (similar to patch_loaded.sh)
in pd-opts.txt we place the following:
this says to create 2 virtual midi input and midi output channels (rather than the default one of each)
so we now have:
128:0 'Pure Data Midi-In 1’
128:1 'Pure Data Midi-In 2’
128:2 'Pure Data Midi-Out 1’
128:3 ‘Pure Data Midi-Out 2’
now the quick among you will notice an oddity here… 128:1 is now an input , when as previously it was an output… unfortunately this is just the way it is, you cannot tell PD how to allocate the device numbers.
however this is not a problem… as we can manage this using patch_loaded.sh
(if you add more virtual devices, they are mapped in the same way)
ok, so we now have extra devices, so we now need to map our devices as before in patch_loaded.sh
so, i’ll do my pyramid to one set, and the virus to the other … so i remove the original mapping and use:
# map pyramid (36:0) aconnect 36:0 128:0 aconnect 128:2 36:0 # map virus (32:1) aconnect 32:1 128:1 aconnect 128:3 32:1
notice: how they map…
ok, so now we have out midi being routed into pure data ok…
so how do we determine which has come from the virus, and which from the pyramid?
so for the first device (pyramid), when we send on midi channel 1, we see this data in our PD patch on midi channel 1, (as expected) , but when the virus sends on midi channel 1, we see it in our PD patch as midi channel 17 (!)… i.e. 1 + 16 (reverse if we do output, channel 17 will get sent to virus on midi channel 1)
i.e. the first devices uses channels 1-16, the second 17-32 etc.
if we add more virtual devices, then we always use the mapping
virtual channel = midi channel + (virtual device number * 16)
this means we address as many devices as we wish for input and output.
and also means if we have devices that can only send on a specific channel, e.g. 1 , then we can create a new virtual device to map it to a different midi channel inside PD.
notice, how the controller routing is separated from the patching…
you can create a patch, that thinks of controller #1 as channels 1-16, and controller #2 as channels 17-32 (etc)
but you are then totally free in how you map your controller(s) to these virtual devices, i could even map one controller to both of these 'virtual controllers’
e.g. here i map my virus to both ‘virtual controllers’
aconnect 32:1 128:0 aconnect 128:2 32:1 aconnect 32:1 128:1 aconnect 128:3 32:1
this is quite a useful concept , as it means you can develop patches which allow for different physical controllers where a user has them , but will still works from a single controller if thats all the user has, and the underlying pure data patch does not have to change… only the ‘configuration’!
(this is one reason why allowing configuration in the patch directory becomes interesting)
I recognise that for some this is fiddly… (this is why the default ‘one controller’ setup is possible from the Organelle menu), but perhaps the above shows, the reason its like this is, midi routing, can get pretty complex depending upon what you want to achieve… adding this kind of flexibility into a 4 line display, frankly, is not really viable…
(the patch_loaded.sh, also allows other interesting options, as its not specific to midi )
however, once you have wrapped your head around alsa device numbers, and using aconnect… and how PD sees midi devices, it actually is very straightforward. one of those times, where reading it, is much more complex than actually doing it!.