is there any way to defeat live's "all notes off" message on transport stop?
I've got a midi track housing my controller max for live patch, and the "all notes off" message on transport stop is turning all my LEDs off. Is there an easy solution to this?
(It turns out the easy solution was to switch my hardware controller to send/receive CC messages rather than notes, but I'd still be curious to know if there's another means).
Has anyone found a way to defeat it yet? I need this function and the workaround Neuro mentioned does not help me in my scenario...
Basically I need the notes that were playing in a MIDI session clip to hold even after I give Live a stop_playing message. Any help?
live sends a CC 123 0 when stop, so you only have to block it.
Thanks, Double_UG, for the spoonfeed! I appreciate it.
midiselect is perfect for this and now "midievent 176 123 0" is no longer getting through - at least when i monitor the events coming out of the last outlet of a midiparse object connected to the midiselect object you've provided.
Now the only problem is that the notes still don't sustain upon stopping transport because I believe Live is also sending individual note offs for every currently playing note. But I should be able to use midiselect in some fashion to selectively filter those messages too.
But devices come after the clip in the chain so you won't be able to filter anything with midi objects.
Sorry, what I mean is a note off will come through before an observer detects that the transport stopped. If you stop playing with an Api call then of course you can activate a note off filter before.
Oh.... so what you're telling me, 11Olsen, is that it's practically impossible? Double_UG's patch is pretty much just for show? Because if i understand you correctly, the clip is executing an "all notes off" command before the device can even get a hold of the message?
This is really unfortunate for me...
I'm thinking that I want to achieve is impossible to do directly but maybe I can still learn by making a patch that keeps a cache of the last note played, then upon stopping transport it'll output the note again... this is exceptionally suboptimal but hey, maybe that's the best that can be done.
Okay... i see your edit and realize what you're saying only applied to my continued need to filter individual note offs and not to the "all notes off" filter Double_UG provided. It'll just take me a bit of time to learn about what exactly an API call is and how to use it.
EDIT: i was using it but didn't know what it was referred to as.
Also, i was using plugsync~ to monitor transport if that matters at all.
I think it can only be done if you make your own stop button in the device. Any notification that the user pressed stop in the Live transport bar will come to late I'm afraid.
I see what you're saying. I should be fine then but I was actually previously unaware of the difference in the chain location between devices and the play/stop buttons or even a controller mapped to buttons those as a remote. I'll keep this in mind going forward.
Thanks for the useful info, Olsen.
Sorry that first comment was comming out of a wake up confusion. I shouldn't post before I had a coffee. I was talking about the midi chain, you can't filter midi in a device that is comming from a controller or another track. It will always reach the clip first. But that isn't relevant for your problem.
[plugsync~]'s stop notification is also to late. Note offs already passed.
As you are using your own "call stop_playing" message, it should work. Tell me when you have problems to get it going.
Aren't we all a little more on the ball after our coffee? heheh.
If you saw my post I deleted saying I've solved my problem please disregard it because I haven't. I spoke too soon and it was a false alarm.
At this point I'm afraid my goal of having notes sustain after giving a stop_playing call is impossible to do directly. I don't know what's going on because I was checking the MIDI stream at different points along the patch starting from [midiin] all the way to [midiout] and whenever i used a stop_playing call normally Live would send a CC "all notes off" message along with individual note off messages for each note that was playing at the time transport was stopped.
I've successfully filtered these messages but the notes still get cut off... maybe I'm missing something obvious but I don't think so.
Does anyone know what could be cutting notes off? As previously stated, I filtered the MIDI off messages with a [midiselect] for the "all notes off" message and I used a [gate] to filter the individual note off messages. I'm monitoring the stream of midi going to [midiout] and there are no note off messages coming through. Sorry if I'm being redundant at all.
If no one knows, I guess I'm just going to build a disappointing patch that replays the notes that were playing when transport stopped.
I did a quick test and yes, even if the midi device completely cuts off the connection between midiin and midiout, the notes get canceled. If you only stop the clip it works but the global transport-stop cuts off everything.
I don't know if I like that.
I appreciate you taking the time to confirm my finding. Because it totally could have been the case that I made a mistake. Although not this time, as you've seen for yourself. I definitely dont like it, but it may be intentional design... :\
I'll see if stopping the clip alone instead of the set/global transport could work with a "continue_playing" message in tandem to sort of stutter through a clip. I assume not, but maybe. I'm mostly a dilettante in Max/Ableton so a lot of this goes over my head.
In the end, my humble little device is more of an exercise in possibility at this point anyway since I'm also discovering the fact that M4L runs in a low-priority thread as I understand it which makes the latency of Live API commands not ideal for my purposes since it's milliseconds too slow. But that's just something I'll add to my new wishlist of features for M4L - the option to interact with Live API on a higher priority thread, if at all possible and if that's the transport command latency culprit. Just to share and not be so secretive, if anyone cares, I wanted this device to pause transport upon note-on messages with the option for hanging notes which as you maybe can imagine would be useful for some applications.
Anyway, thanks again for discussing this with me, Olsen. I'm going to try out clip stop commands which I wouldn't have bothered to without you reporting that those work fine and leave notes hanging just like I want them to.
there's a "stop_all_clips" method of the live_set object. If you call that without quantization and activate your note-off filter before, you have something close to what you describe. To continue the clip where it stopped you could adjust the clip start but that will change the rhythm compared to other looped clips.
to pause transport upon note-on messages
That I don't get. Which note-ons exactly? When and how will the pause get triggered?
Yeah I couldn't get "stop_all_clips" to work like I wanted and figured it wasn't meant to be used the way I'm trying to use it.
Which note-ons exactly? When and how will the pause get triggered?
I'm looking for it to pause when clip MIDI note-ons occur during playback of said MIDI clip.
Ok, I get a picture now. But the hanging note will play the sound. Wouldn't it be better if the launchpad pad lights up but the actual sound is not played before the user hits a pad? I noticed that a m4l instrument can filter note-offs, also when the Live transport stops. So maybe instead of a Live instrument (like Operator) you build your own or let the user load a vst in it. If I find the time later, I will try to create a little example. Definitely an interessting device idea.
You could try to get indpendent of live and it's transport
by using own device as sequncer / midi player and also max based synth
which needs not to follow any transport or midi rules.
or have note on - offs
Wouldn't it be better if the launchpad pad lights up but the actual sound is not played before the user hits a pad?
Good point, yes it would be better! I have no justification for the way things are other than the inspiration coming from what happens when playing a MIDI clip and sending data out to the controller - the clip determines both sound and light. It would seem that I simply lacked the creativity or awareness to realize things aren't the way the ought to be.
Thanks for discussing this as much as you have already. I'm glad you think the idea is interesting.
Double post, just saw your post
You could try to get indpendent of live and it's transport by using own device as sequncer / midi player and also max based synth which needs not to follow any transport or midi rules. or have note on - offs
That's definitely the way to go! I have a lot of work to do then but I now see a path to success! My apologies if this was what you were proposing and I missed your point, Olsen. And thanks, Source Audio, for spelling it out so plainly to me. I have a hard time understanding people sometimes.