Organelle and the MIDI Standard

Organelle
1

Recently, I met up with a friend of mine for a musical jam session. He has a whole set up of synthesizers, drum machines, sequencers, and whatnot, all connected via MIDI. I enjoy jamming on his setup, but this time, I brought along my new Organelle M. I wanted to see how it would fit into his rig.

Well, we ran into some issues. Namely, it didn’t integrate as smoothly as we had hoped. Unless the patch had some means of capturing (or sending) an external clock, there was no way to tempo-sync the Organelle to the rig (this was handled via an Akai MPC One). Further, the Organelle didn’t listen to the start/stop messages from the rig; it didn’t even pay attention to the “panic button” hard stop MIDI function.

This led to a bit of an argument about the Organelle, which made me wonder: Why doesn’t the Organelle handle MIDI the same way as other devices? Why does it allow patches to simply “ignore” mission-critical MIDI messages (e.g. hard stop)? Why isn’t this integrated directly into Organelle OS, as opposed to being handed off to the patches to “choose” whether to use it?

I ask because, seemingly, every other MIDI device DOES conform to these standards, at the core firmware level. It seems quite odd that the Organelle does not, despite it trying to be inter-compatible with other MIDI devices.

2

The problem is more an issue that stems from the open source nature of the Organelle and that it is entirely up to the developer of the patch. MIDI functionality isn’t required to be coded to be considered a valid patch. I guess my question would be what patches were you using?

I find the Orac ecosystem to be fairly robust and am able to jam with other MIDI synced devices

1 Like
3

But that’s my point. It doesn’t have to be that way. Organelle OS can be open source AND enforce baseline MIDI standard behaviors. Yes, people could modify the OS code, but by default, it could make a statement about what patches are (and are not) allowed to do. And it doesn’t have to be much. It could be something as simple as “must receive hard stop messages.”

I noticed this with a patch I ran recently. It had a random arppegiator, which sounded really cool, but if the arp was latched on for too long, one note would get “stuck” and would just be constantly playing, even if the arp was turned off. And there was no way to “kill” the stuck sound, except by loading a new patch.

In most standard MIDI devices, there is a simple gesture to “kill all sound” that the hardware is producing: double-tap the Stop button. The Organelle doesn’t have that, unless a patch includes it. Which seems EXTREMELY strange to me. It’s like, there are lots of standard “safety tools” that the MIDI standard comes with, but the Organelle just… chooses not to follow them.

A better alternative would be to have the Organelle follow these standard safety protocols in MIDI by default, but allow users to modify the OS code (as it is open-source) to bypass them. Like, it’s better to provide airbags and allow users to disable them, than to not provide airbags except upon request. Opt-out of safety features, rather than opt-in.

4

I guess it could probably be included in the mother patch to handle MIDI but unfortunately I don’t really see it happening. I guess there could probably be a guide on how to implement MIDI functionality for the Organelle but the patches available are made from people of all skill levels.

People who have been coding in Pure Data for years and people who only discovered Pure Data via the Organelle. A lot of C&Gs patches do work with MIDI very well but that cant be said to be the same for any old user patch. Another thing to point out is that most patches aren’t extensively bug tested before being released.

How I personally address this is by pretty much working exclusively in the Orac ecosystem. All the MIDI implementation is handled by the clock module and when using something like Transport or Transcycle, they do in fact react to start and stop messages and can sync with MIDI or Link.

If there is a patch you use a lot and find a bug in the implementation, that could be a compelling case for you to get your feet wet with Pure Data and share your bug fixes :wink: If there is a specific patch that is having issues too, feel free to make it known and I might give it a crack in trying to fix it

5

But that’s my point. We shouldn’t HAVE to implement MIDI functionality for the Organelle, because a lot of the baseline stuff of the MIDI Standard should be baked into the OS. At a core level.

Let’s compare it to other computers. With a Windows PC, you have the OS, and you have programs that you run. If a program is acting up, you can use the OS-level Task Manager to end the program. This forces the program to stop. And the program HAS to respect that call, because of how it’s written to conform to Windows operating expectations.

With the Organelle, the “task manager” is the MIDI standard. In order for the Organelle to be compliant with the MIDI standard, it has to function in a certain way. It has to be configured to accept certain MIDI messages from connecte devices. But it doesn’t do that. If a connected device sends the hard stop message, the Organelle doesn’t have an OS-level system that receives that message and kills the patch. It instead passes that message to the patch, where the patch writer can CHOOSE whether to obey it or not. The program is not required to end the task, because nothing is forcing it to do that.

To be blunt, this is bad design. The MIDI standard has had these expected behaviors for compliant devices since 1983. If a device complies with the MIDI standard, then it HAS to behave in a certain way. And seemingly, the Organelle does not. The Organelle, as much as I love it and find it fascinating, does not appear to be a MIDI compliant device. Yes, it can send/receive MIDI data, but it basically… does whatever the heck it wants with that data, rather than handling it in a way that follows the MIDI standard.

Which is weird. Like, there are GUITAR PEDALS that conform to the MIDI Standard, and they don’t seem to suffer adversely because of it.

Basically, what I’m looking for is an explanation. I’m curious to know why the Organelle doesn’t behave like other MIDI devices. Why it doesn’t have the core-level safeguards that other MIDI-compliant devices have. Why C&G chose to make a device that seemingly doesn’t comply to the standard.

In short, why can’t I have airbags? Why do I have to build them myself?

6

I understand your frustration. With most musical devices that support MIDI, there is a whole team with resources that try very hard to break their devices to make sure the implementation is fool proof. I don’t find it fair to compare that to a patch that was made by a beginner who knows just enough to put together something that works but is full of bugs.

A system call could be implemented in the mother patch but it all comes down to the patch developer. A system call to kill MIDI could be implemented but if there is not any part of the program that is actively listening for that, it won’t do anything. A tree can fall in the woods but it doesn’t matter if nobody is there to hear it. Another thing I would say is that MIDI is not handled at a system level, but rather at the Pure Data level.

C&G could maybe put together a guide on how to interface with that data and how they deal with it but there is a vast library of patches that were made by amateurs who later sold their Organelles and won’t maintain them. Maybe this could be remedied with supplying an empty user patch that has the implementation already coded in but even then, some developers might opt to just delete it.

In short, you would have to code in a midirealtimein object that converts the MIDI data into messages to correspond with clock, start, stop, and continue messages and then choose what those messages actually mean to the program. It’s not really that hard to do but it’s not in a majority of patches.

Unfortunately I don’t have a better answer than trying to fix it on a patch by patch basis and trying to document how you would go about implementing it and hope that the patch designer updates it to conform, or you can add it yourself. Feel free to PM if you have a specific patch that you are having a hard time with and I can try to show how it could be implemented and then if you run into a patch in the future that has similar problems, you can know how to fix it.

7

That makes sense. Thank you for listening to me.

To be clear, I don’t plan on stopping with the Organelle. I enjoy it a lot. It’s a great little device, and it has a lot of potential for integrating into my setup. I just need to deal with the fact that it doesn’t work like other devices, and seemingly, that won’t change.

If C&G were to implement stronger MIDI standard compliance in OS 5.0 or whatever, it would render countless patches incompatible. And that would likely mean that a lot of those no-longer-maintained patches you mentioned would just disappear. Which would be sad.

I think this is just how it’s going to be for a while. And I’ll have to learn to work around those hurdles. But for the most part, it should be fine. Audio in/out still works just fine.

1 Like
8

No problem! Also again, I watch this forum like a hawk and I try to always answer my PMs if you run into issues or want to pick my brain lol

1 Like
9

Interesting and good points made. An abstract midi patch with explanation (bit like the graphic demo one) could be useful for people to add to patches? Rather than lots of slightly differently done methods that would be confusing when going from one patch to another.

Doing stuff in Orac ecosystem is something I need to look at too to help with consistency like this.

1 Like
10

I think that would be sensible. Maybe also one showing how to implement the abl_link external would be good but even though there is a help file for it. Also I would love to see you making Orac modules :slight_smile:

1 Like