M4L midi effect midiout just stops all midi output after some time
I am trying to test a new max for live device that I made, it is a simply a sequencer that outputs midi notes as well as MPE pressure and slide. After simply leaving the device running, at a certain point (it has happened as little as maybe 300 bars, other times around 2000) the device simply stops outputting anything. I tried with the device open and I can confirm that there are no changes inside the device, all messages continue to be sent to the midiout object, and yet they are not outputting from the device into Live. So it's hard to tell if this is a Max or a Live issue.
Now maybe it's not a huge issue as most people are not going to be leaving it running for so long, but it still seems odd behaviour that shouldn't be happening.
hello,
If you generate some notes with an another very simple device and let it run 300 or 2000 bars, is it the same behaviour? If not, it's maybe something in your device and it's not a general issue ...
I have too a device that generate some notes and send them to live but it's not MPE, I can let it running for ages without any problem...
Can you post an example of your device ?
I'm not going to post it since it's going to be a commercial m4l device.
Yes I'm testing now just a simple device banging out stuff, it's still running...
At first I thought it was the mpeformat device but it seems to be outputting correctly eg. 145, 60, 100 for a note on etc.
One thing that was occurring with the device before is that I was getting random notes coming on and hanging. Now there are only specific notes being triggered by the device so that made no sense. I deduced that somehow the midiformat object was being overloaded with messages and somehow was outputting the data bytes in the wrong order and a random message for velocity for example was triggering a noteon. I had to make a separate midiformat object for notes and one for slide/pressure which seemed to stop that from happening. I guess it could be the same issue that somehow something is coming out wrong and that is making all the note bytes in the wrong order. It's very odd.
When it happens the only thing that will get it working again is to delete the device and put a new instance in the midi track.
Now thinking about it, it's probably the same issue. I somehow one of the bytes is coming in the wrong place, then even if it looks right, the bytes are no longer being put in the right place so they are no longer triggering note ons and offs correctly.
Pretty sure I hit this when developing some of my MPE devices, too.
I can't check exactly what I did right now, but you might try putting a [midiflush] after your [midiformat] and banging it every time that voice gets a new note-on as a precautionary measure. (Assumes you're using poly~ voices).
I think I may also [midiflush] prior to the poly~ in response to moving the device, too.
I added a flush at one point, with borax connected just to see what was going on, and after midi notes had stopped coming out the device, everything inside was acting normally and borax wasn't showing any hanging notes. Simply going from 1 to zero notes as usual. Didn't try midiflush after the midiformat though...
I'm not using poly~ voices, just bpatchers for each sequencer
So i know this is kind of different from my first stated issue, but i'm convinced the random notes are related. So i put midiflushes after the note midiformat, after the parameter midiformat and then those lines go into mpeformat and i put another one after midiformat. When a naughty note popped out of the device, I checked the midiflushes in order. Nothing from either of the midformats, but the one after the mpeformat sent out a noteoff when i banged it. So it does seem like there's some crosstalk or bug going on, but the thing is that even when i remove mpeformat and go straight to midiout, the same thing happens. Wondering if using multiple midiouts can work
Ah you're right, poly~ isn't the point. The aggressive midiflush after midiformat should be the same in poly~/bpatcher as long as its one midiformat per channel out.
Midiflush didn't help, I'm still getting the random notes popping out. This is frustrating
The most annoying thing is that when i make a simplified device to approximate what's happening, I can't replicate the problem. I must be missing something
The most annoying thing is that when i make a simplified device to approximate what's happening, I can't replicate the problem.
Bummer. I swear this sounds like such a familiar problem to me but I'm just a little fuzzy remembering all the behaviors. The whole MPE in M4L was quite a black box.
A few more speculative questions:
You're only outputting notes on ch 2-16, right?
Are you outputting notes of significantly different lengths from each other?
In your bpatcher setup, do you route voices purely based on the channel they arrive into the device on?
When the issue happens, does sending a MIDI all notes off stop it? (176 123 0)
Are you using RNBO patches/externals at all? -- Until the January updates to Max 8.6.0/RNBO there were definite MIDI / message I/O issues in rnbo+M4L.
Alright, first, thanks for replying, I appreciate the help.
Thankfully it seems like it is fixed.
Basically the velocity, note length, slide and pressure are being changed to a new value at the end of each sequence. I decided maybe it didn't like that, so all I did was stored the changed values and only banged them out on the onset of the next note. I didn't expect it to fix it, but it seems like it did.
And yeah just to answer, ch2-16 yes, yes lengths changing, since it's a sequencer a specific note is generated in each bpatcher, I didn't try all notes off, unless that's what the flush sends out in which case I guess I did, and yeah no RNBO.
Glad you got it sorted out!