M4L MIDI effect only passing MIDI while being edited !?!?
For some reason the M4L midi effect I've been working on is only passing MIDI along when the patcher window is open (ie. when I'm editing it). As soon as I close the patcher window, I see from Live's yellow dots that the MIDI is somehow getting stuck in the device. So for troubleshooting, I reduced it to a simple midiin, midiparse, midiformat, midiout chain (all midiparse outlets connected to their corresponding midiformat inlets) and the problem persists. Note: whenever I make any changes in the patcher window, it starts passing MIDI like I want it to, but only until the next time I open then close the patcher window again.
Please, someone tell me what stupid newbie mistake I am making!
Thank you
maybe you have some other device on the track that eats up the midi?
Posting a picture of the whole Live set may be helpful to see the context, in particular track input/output selection.
Here are pictures of working (patcher window open) and not working (patcher window closed). As you can see the midi is entering the device but not leaving it. I should mention I'm using external instrument to get midi to Mainstage (which I use for its sound library). The Max patch I'm working on creates custom CC which will go to the third inlet of the midiformat, out of the device, through ext. instrument, and finally into Mainstage to control the sounds.
.png)
.png)
Your MIDI merging in the "sdfa" device may be problematic since you are feeding CC messages into the byte stream. Try using the same configuration as in "gadf" with midiparse/midiformat and then connect [pak] to the 3rd inlet of [midiformat].
Sorry- cluttered workspace: "sdfa" isn't the device I'm asking about (although it shows you the idea of how I'll make my CCs).
"gadf" is the problem device where if you look closely, MIDI is getting stuck in it somehow, when the patcher window is closed, even though there is nothing but a glorified MIDI through in the whole device! There must be some silly checkbox I've forgotten.
Very frustrated. Thank you for the attention!
But I still think that "sdfa" could be the culprit, because it merges MIDI bytes which may lead to invalid messages and thus stop processing of "gadf". Simple test: Delete the "sdfa" device and see what happens.
I was able to fix the problem for a while by deleting "sdfa" but as I continued to patch, the problem returned and went away several times as I deleted and re-added devices. kI'm still finding that opening a device's patcher, renaming it, or hot-swapping it for an identical device, can change whether it passes MIDI. Several patching days later, I opened the patcher of someone else's M4L device (Trigg.me RECEIVE by 4Live.me). I didn't make any changes and pressed "don't save" when closing it, because I had only opened it to study his patching. Lo and behold, Trigg.me RECEIVE had stopped passing MIDI and was now rendered useless (until I replace it with a fresh one). A few times during my own patching a device that had spontaneously stopped passing MIDI would start again after a few minutes, but most of the time not. So the problem remains: what silly setting, or is it a bug, is responsible for M4L devices ceasing to pass MIDI when I open their patcher windows?
Thanks for any help!
In fact, I remember similar problems when editing a MIDI device, and I had to reload the Live set to get it working again. So there seems a bug when changing the environment from Max (edit mode) to Live (performance mode), but difficult to reproduce.