Can automation have priority over notes ?
Continuing this topic : https://forum.ableton.com/viewtopic.php?f=35&t=242868&sid=e3442d87fb76f13286a06afb1c87f0c0
I'm wondering if there is a way for automated parameters to happen "before" notes without delating the MIDI flow.
Any ideas, resources ?
while i dont fully understand the question in the ableton forum, i am sure that he basically only wants to change the order of execution.
simply put: when you generate data you have full controll over "priority".
what could be is that you needed to introduce a delay of >1 scheduler tick to make sure the automation can not be overtaken by the note later in the live app.
The thing is, the midinotes and the automation data are generated at the clip level in Live, meaning they are not generated in the Max device.
If I delay evrything ebut the incoming notes in the Max patch, it works, but I'd rather not doing this.
I think to ensure the execution order "automation before notes" without touching the notes you need to send automation explicitly before the notes (negative delay). As a genaral solution I'm using 2 different timelines: the note generation timeline starts at bar 2 and the automation timeline starts at bar 1 with a delay of (1bar-x).
Test Patch with bondo works, but I am not shure if there is a delay
DOUBLE_UG, I gave this a thorough testing... it seems your example is setup to trigger the last-played note whenever the automation envelope hits 127. Per the above example image, try flipping your envelopes upside down so they drop to 0 at note start and rise to 127 after the note has concluded. A note of the most recently-triggered value will sound each time the envelope node hits 127. You can delete all the notes in the clip and notes will still sound.
you are right, seems i misunderstood how bondo works. Perhaps with thresh
but it only play the note when the envelope changes
Thanks to you for your experiments.
I might be mistaken, but [thresh] must introduce a delay.
Otherwise, maybe this would solve the issue with the note being triggered only when the envelope changes.
For what it's worth, none of the thresh-based examples have worked at all on my system (late model iMac, Max 8.1.9, Live 11.0.2). The on/1 value for the gate never pairs with the note value, they always pass through separately.
Double_UG, your latest example is still triggering notes from envelope values, rather than gating any notes that fall on the exact same point in the timeline as the envelope, as Chapelier has been trying to achieve. Is my understanding of Chapelier's goals incorrect?
You've understood my goal perfectly, @Patrick_k.
Could not test the patch above, but from what I see of it, incoming notes will not trigger anything excepts when the probability changes.
For what's worth, my initial patch work exactly as I want, except that I have to draw the automation a little early. It's not a super big deal, but it make the practical use much less intuitive.
If it were me, I'd live with the microscopic delay of adding a delay unit set to 0. It's so tiny as to be well below the threshold of human perception... plus I'm lazy, and I'd just want to draw my envelopes quantized and tidy. :) But I completely understand the desire to avoid anything that destroys the absolute timing perfection of a modern DAW... regardless of whether or not the delay is human-perceptible, it doesn't feel great to know that it is there.
you can delay musical events for up to a vectorsize without getting a different result from it ;)
Hahaha, I admit it's just some sort of OCD.
@RomanThilenius :
I have no clue how to do this, but I have the feeling that it doesn't apply to Max for Live. Am I wrong ?
Hmmm... I suddenly have the urge to add the delay object @0 solution to Chapelier's example .amxd and see what the phasing is like with that micro delay applied to one of two identical samples being triggered at at exactly the same point in the timeline... because yes, in that scenario, I suspect there would be something that is humanly perceptible. :)
it can be that when there is a note event on a live track that it will reach in time because the host takes care for that. all other events, scheduler or not, will be taken with the next audio vector from max externals, devices or vsts. so if you use a del 1 or a thresh 1 somewhere that will not change much compared to del 0. of course you still use del 0.
Well, I made the test. One is with the device (with del 0 added), one is without the device.
Can you tell which is which ?
if you use a samplingrate of 192khz and clutter the main thread with millions of messages, you will be able to tell the difference.