first : have you watched my video, and read my first post
… theres some details in their that I need to assume you already understand.
(and I dont have time to repeat )
second: as per the video, did you test the LPK25 on its own with the Organelle, and did it work? when you used it with the just using settings->midi-> device (i.e.without messing with patch_loaded.sh)
** if it works with this** then you know it works with alsa, so you can forget oss midi, and we can look at the multi device setup. (step 2)
if it doesn’t work on its own then we need to get this working first.
and you need to run DiagnosticLog (find on forum) so that I can see if your LPK25 is being detected correctly , by alsa.
about your problem,
so you want output via E-MU and input from LPK25
you’ve tested the E-MU output presumably via the organelle keyboard, and thats working,
but its LPK is not working
ok, I first assume you are sending on midi channel 2, id be tempted to try midiIn = 0 initially, so works on any channel, and try this with a C&G patch , to see if this is working … this tells you if you are getting midi data thru, without having to worry about midi channel.
if that is not working, then my suspicion is the LPK25 has multiple midi ports… this would also cause issue in single device setup, hence why we checked that first
to fix that you can get the port number by using settings->midi->device, and twisting encoder, see if there are other ports (it might not be evident from display, if they are very similarly named!)
apart from that you would need to run DiagnosticsLog and post the results (as described elsewhere on the forum)
btw: sorry, I really don’t want to start talking about ossmidi, beyond the details Ive already put in the top post here (which does cover quite a bit of info) - ossmidi is unlikely to be necessary, as its actually not as comprehensive/stable as alsa , and I don’t have time to mess with 2 different setups miid apis, and it’ll also just cause confusion on the forum…
ok, so to be clear you got the aconnect lines from the root directory patch_loaded.sh where you had selected the LPK and then later the E-MU… and then just put these in your patch_loaded.sh in the patch directory?
ok, so debug this, we could do the following…
a) just select the LPK25 in settings->midi (so not patch_loaded.sh)
then on the organelle in a terminal window (little black square down in bottom left of display)
then show us what it says here
b) put the modified patch_loaded.sh in place
and do the same again
basically, ‘aconnect -l’ will display all available devices and how they are connected with alsa
if you dont have access to a keyboard, then you can use the DiagnosticLog patch, which does the same - and sends the output to a file on the usb/sdcard.
This was the problem. I had copied the names of the devices from the Organelle screen and typed them in. I didn’t realise that the root patch_loaded.sh would update as I selected each one, and there were some minor differences in how they were called out. I copy pasted each one verbatim and it works. Thank you, that’s really saved my neck.
One thing I don’t understand: what does the channel do when handling MIDI in this way? Is all data on other channels purged?
My input via LPK25 is on Channel 2, but the output via the EMU is using 10 channels. It seems to be all working though so I don’t see what the channel selection does.
Some further thoughts -----------
I feel like the process of getting that working, despite your pretty thorough video, was enough of a pain in the arse that most people won’t bother. It’s really cool to be able to do this on a patch-by-patch basis - that’s definitely important.
I hear you on the tiny screen but I feel like it’s necessary to find a way of implementing it, because flexibility is one of the beautiful things about the Organelle and it should be made available to the less hardcore users.
How about: All connected devices show up in a list. So if there’s one device it’s really short and easy. If there’s more they get added to the bottom.
Enabled/Disabled can be baked in with the channel selector making it 3 lines per device:
Name Input (Disabled/Omni/1/2/3/4…) Output (Disabled/Omni/1/2/3/4…)
yeah, unfortunately that can’t work, for 2 reasons…
the screen is too small to display the full name, and also the ‘user description’ is a little different from the string required for alsa connection.
but glad you got it working
ok, im not quite sure what you mean…
the midi channels referred to in midi settings are the channels used by default for patches.
the input is used to replicate the organelle keyboard, the output for notes/knob movements from organelle.
they are used for quick midi interaction without need to change patches.
I personally done use them much, and I do something pretty different in Orac
no the data does not get filtered, PD sees all data with things like notein, its just mother.pd does not translate them to ‘note’ messages. (look at mother.pd you’ll see what i mean)
ok, this really leads on from the last point…
midi configuration can get very complex, with multiple devices, channels , how they interact with the patch etc.
so the goal of the midi settings on the Organelle were ‘limited’ , to the following:
try to work ‘out of the box’ with no configuration
work for one midi device
allow for midi device selection where there are multiple devices, or also when some devices have ‘quirks’ like multiple midi ports.
allow manual configuration for more ‘complex’ cases i.e. don’t impose limitations.
Id say its reasonable to say a good percentage of Organelle users, do not attach any midi controllers/synth to the Organelle, and of those that do a big percentage (80%?) use one device, most likely id say a controller (to get a bigger keyboard, with velocity)
so the current ‘goal’ probably hits 90% use case?
one thing I think the midi settings should have had added, was a separate midi input and output device (like channels) … honestly, for some reason it only occurred to me when we were ready to go with the 3.x release, and I then forgot it.
… but I suspect a separate input/output device, would hit another heathy % of use cases.
from there, it gets more complex quickly…
per patch control,
honestly I doubt is that common a requirement, Id have thought most users use the same controllers on all patches? I know from experience can be very confusing. e.g. ive forgotten that a patch wired to a particular controller, so my controller was working on some patches but not one of them!
this means if you have a ‘save to patch’ you also need to be able to recall from the patch…but thats not to tricky to implement… though you probably also need a ‘revert to global option’ too.
you have simplified your use case, where they share midi channels, but as you can see in my video, thats not the only way, you can actually make it so that different controllers come in on different channels e.g.controller #1 = 1-16, controller #2 17-32 … which you want, is really down to how a patch works, capabilities of a controller (e.g. some might only be able to work on channel 1) , if you want you controllers to be ‘equivalent’ or distinct
similar to multiple controller, but (almost always) you want them to be distinct, and so for multitimbral synths that means splitting 1-16,17-32
(btw:this also complicates patches, since they can no longer say midi channels are limited to 1-16!)
I agree, unfortunately the one of the other beautiful things about the Organelle is its simplicity, the fact that any one (tech or not) can use it.
I think we have to be really careful as ‘techies’ that by adding flexibility we don’t also add complexity…
it’s truly a balancing act.
I (personally) would prefer the Organelle didn’t end up with a deep hierarchy of menu settings trying to cope with every use-case I can think of.
thats not to say I disagree with your suggestions, nor that the balance is ‘tilted’ the correct way currently, rather just an insight to where we are.
as I said, I definitely think input and output device should be separated,
perhaps per patch save/recall, if it can be intuitive… and there is a need seen for it.
(its actually pretty easy to copy the global file, its the editing which i think is more intimidating)
unfortunately, I still suspect, multiple controllers/outputs is perhaps a step too far in complexity… without redesigning the UI quite a bit.
but never say never,
(and of course this is just my view, owen/chris might have different opinions)
This is really good thinking imo, especially to not overcomplicate things and keep things simple for cases where it’s best kept simple. Maybe there’s a way to keep the “default settings” involved in this no more complex than they currently are, but allow for more complex configurations for those who would want it.
By separate midi in/out, do you mean being able to select “note receive”/“note send” on or off? That would also be a great option for clock send/receive.
This may be a particular (maybe even uncommon) example, but in trying to have my Reface DX control Analog 4 (notes), while also syncing to Organelle clock, it’s been a bit of a mind bender mainly due to the fact that there’s no way to turn off clock send on the DX! I can turn off clock receive on A4, but no tempo presets (which organelle as clock would allow).
Currently I am doing A4 clock -> organelle -> DX, and DX notes -> A4
I could also try organelle clock -> A4(thru) -> DX, and DX notes -> org -> A4
This all not so much to say here’s what I’m doing and hence more in/out on/off midi options would help me, but more so to give some examples to further illustrate what @thetechnobear was saying on how/why midi can get very complicated, even with just a few devices! That said, it’s always useful to be able to turn on or off clock/note send/receive, on a per patch, per orac preset basis - but how to keep it simple while allowing for configurations (but not forcing users to do configuration setup for every patch etc) I can see why this might be a tricky.
what i mean is currently in settings->midi, you select A (one) midi device which is used for input and output. its always been this way on the Organelle.
But I think a quite common scenario is having a midi device for input (a controller) and a different midi device for output (a synth)… and this doesn’t make the UI any more complex, as we already have different channels for input/output, so logical to also have device separated.
clock… yeah, that actually not handled by the midi setup, nor even mother.pd this is handled by the ‘metronome’ subpatch, which unfortunately is copied into nearly every patch, so would have to be updated in every patch.
I do quite like that it ‘auto detects’ clock, its one less thing to think about, but perhaps there should be a mode selector - auto/master/slave … it could then be defaulted to auto, but you could override - if i remember, i’ll look at that for Orac (I want to do some changes to clock for the next release anyway)