How to : Advanced Midi Setup (3.1)

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 :slight_smile:

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 :wink: )

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 :wink:

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 :wink:

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

(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 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 :wink:
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? 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
in pd-opts.txt we place the following:

 -mididev 1,2

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

(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
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?

midi channels!

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.

Advanced tip:
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, also allows other interesting options, as its not specific to midi :wink: )

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!.

Happy Patching


That’s great!! Thanks ! (for the video and explanations)
this time around I wasn’t that courageous to figure it out ;-( although I was messing with (that I got right…)

Talking of sequencers; LinnStrument has a nice one… diving in!

1 Like

Gracias Mark! Will check this out
Very well explained tut btw :slight_smile:

Awesome!! few lines added and OG respond to all of them; for now LinnStrument, Xkey and a 88 mother keyboard (adding more devices kind of “allocates” higher numbers 28:0 32:0 36:0 40:0)
Will try some more later and a video of a simple jam…
:beer::tea::wine_glass: @thetechnobear

Hi Mark,

Thanks for all the info.

This is probably a stupid question but how would I determine which device has sent the midi in a PD patch, is it just done on channel number?



yes, pure data patches only see midi channels, they have no proper concept of devices (unlike max/msp)

however you can add more virtual devices, to extend this concept further.
(Ive updated the original post will more advance configuration tips)

@keymanpal , cool… i knew you would have fun with this :slight_smile:
… next step is multi-timbral patches, so we get multi parts for each controller.

Linnstrument, cool, Id forgotten about the sequencer … that’ll be fun.
I just got the Pyramid, a week or so ago… been lusting after it for a while, really flexible thing, great as a sequencing/clocking hub for all the bits of hardware Ive been accumulating… im particularly interested in its polyrythmic/polymeter handling which is really strong - nice to step away from 4/4 :wink:


Thanks for the info on virtual devices, that is exactly what I need :slight_smile:

1 Like

ok, added some more ‘tips and hints’ which might catch people out when they start playing with this :wink:

1 Like

Yeah :wink: Organelle and Pd keeps me busy by the fireplace.

Congrats on the Pyramid! I did play with it at last year Superbooth, lovely!

1 Like

Read and read again; all the missing trickery :wink: thanks a million!

This is brilliant, thanks Mark!

1 Like

I finally got 2 midi devices working. Mark, thank for the extended explanation, your time and effort.


YES! Thank you for the explanation. Got my Digitakt to send midi commands to the organelle using channel 14, and then pass along commands on midi channel 16 to my OP-1. PERFECT!

a 1000x thank you.

1 Like


thanks for your work on this, mark!

i’m running up against a midi related problem (i think…) and was wondering if the above is part of the solution.

i’ve got a korg nanokontrol that i want to use for midi cc in and an EMU midi interface that i want to use to send midi note info out. originally, i thought that it should be fine since [ctlin] would only be addressed by the nanokontrol and [noteout] would only need to address the EMU. however, when both are plugged in, it seems that only one works at a time. (so far can’t figure out why it chooses to recognize one or the other each time i boot the patch.)

even with MIDI in coming from one device and MIDI out going to another, will i still need to add both as virtual devices, as above?

1 Like

nevermind, got it all sorted now!

once i downloaded OS 3.1 and watched your tutorial video, it was a piece of cake. didn’t realize that the organelle defaulted to recognizing only one MIDI device. with the “aconnect” command, this took 5 minutes to set up.

thanks again for putting in the work to make things like this so painless.

1 Like

cool, glad you got it working…

you might have noticed the video is now slightly ‘out of date’,
as in 3.1. you will now see that the contains things like

aconnect "Pyramid MIDI USB:0" "Pure Data:0"
aconnect "Pure Data:1" "Pyramid MIDI USB:0"

i.e. we are not using device numbers (28:0)
this actually makes life easier , because it doesn’t matter which order your (multiple) devices are connected, it will still work, something a little error prone with device numbers.

the only ‘drawback’ of this is it codes which hardware is connected , rather than which port
i.e. 28:0 generally refers to the first USB port , what ever is connected to it
(unfortunately, its the ‘generally’ in this statement that makes it undesirable)
which is why I left the default as 28:0, so that users can connect one device directly without caring too much.

either device number or device name format work, so you can choose to use whichever you please.

1 Like

2 posts were split to a new topic: Record MIDI Sequence from External Device & Loop it back to Device

i was going to update to 3.1 before installing the orac stuff but it seems the link on patch storage is broken
Can someone point me to the download for that?

thanks @oweno