Clock shift progressively during the set making quantization troubles !
Hello,
I use a Max patch for my AV performance p(O)st.
Everything work perfectly except for 1 stuff.
I create audiovisual sequences using a monome Grid. The way to do that is inspired by the app MLR from Monome, if you know. To be very accurate, I quantize my monome performance using the Max clock (16n). It works perfectly but after a while, it becomes impossible to perform perfectly because the quantization is no longer accurate. I need to turn Off Max, then turn On and it works again.
It's a big problem because after a while (I feel 20-30 min), It's impossible to perform !
Maybe it's about a little detail to have something perfect all the time ?
Thank you for your help.
I have a performance next week and this point is very stressful for me...
Best,
Alex
hmm seems too complicated to me, all that metros etc
but deferlow inserted in the metro path is not what I would do
all you need (at least I understand it so) is steady clock output
and selector for beat division.
would you have look at tempo object ?
Transport - free, set tempo change and division on the fly ..
simple, one object slution
are you enabling audio interrupt and overdrive in your settings? there are also some variables in the preferences regarding scheduler slop and a few others that are worth looking up the documentation for.
after quick glance at your patch screen shot, nothing jumps out to me. I would expect the metros to stay in sync if you have overdrive enabled. If you are having trouble and in a bind, you might want to try rewriting it as a clock-divider where you have one metro going at the fastest possible rate and then use counters to output a bang on every N bangs from the master metro. That being said it might introduce more bugs than its worth since you have to track resetting everything. Seems like your patch should work in theory but I havent personally let a patch run for 30 min straight.
Hello,
Thank you for your reply.
Deferlow is possibly not a good idea effectively. I will try without deferlow. But, probably that I have added this max object to improve the system. I don’t remember the reason. For sure, I don’t add deferlow without a reason.
Yes, scheduler :
in overdrive ON
in audio interrupt OFF
about the scheduler preferences, I tried to know how to improve the system but sincerely it’s really hard to know what change to do. For the moment I use the default settings.
About the idea to program a click divider from 1 metro. It was my first idea and I made it but it was less efficiency with more problems. Using different metros with different clocks work better.
Thank you,
maybe the problem is caused somewhere else.
One thing is quantised execution of monome input,
but what is receiving the monome messages ?
Also I remember in the past things going totaly
laggy after a while, and fast turning overdrive Off / On
in performance pasues solved the problem.
Involved were Midi In/Out and Vst synths.
After some time lagg in midi stream would appear.
At that time I had no time to really test if vst plugin was adding to the problem.
But it is years back.
I will try to turn on/off overdrive when the problem will occur. It could be a good temporary solution (better than turn on/off MSP, which everything stop including the sound). I 'm going to make some checks today and I will let you know. Thank you again.
for me this did it
I banged it everytime vst plugin had to load new preset bank, which
I believe to remember was the cause of the problem.
With 128 / 64 vector which I needed for better latency.
Plugin behaved well with 512 / 64
but that was too slow to play realtime.
Unfortunately, turning on/off scheduler in overdrive doesn't work.
I remove all the [metro] objects except the 16n one (and I control the [transport] object with this 16n one), and remove the [deferlow] objects. It doesn't improve the situation.
The only way to get a perfect quantization again is turning on/off MSP. Obviously, it's a very bad solution because I have to stop in the live performance !
there is no trace of any msp object in patches you posted.
So one can't really do anything to help you,
because there is no way to find out what could be causing that out of sync in first place.
Of course, I've just took 2 snapshots because I thought the solution was possibly here.
The whole patch is really huge using MSP. And it work only with monome Grid and Arc. It work perfectly except this problem. That's why I can't share the whole projet unfortunately.
You did not even explain what gets out of sync.
Is it stuff allready running that drifts out of sync
or do monome quantised values become laggy.
or do values get send out properly on time, but execution laggs.
This conversation does bring up a good troubleshooting strategy- Try to isolate that part of the patch thats driving the rhythm and see if you can re-create the problem you are having. i.e. maybe just have the metro objects drive some simple cycle~ objects with a line~ envelope. See if you encounter the issues that you are facing in your large patch. If not, start to add back in parts of the larger patch until the problem shows up. This will help narrow down the issue.
What gets out of sync : this is the quantization performance. It's a live, real-time, quantization.
Imagine that you play a midi keyboard, on a clock (bpm 124 for example), and the system make that all midi notes are perfectly on the beats. I perform it with my Monome Grid. It works perfectly during 15-20 minutes. After this time, the notes that you play are not perfectly on the beats anymore.
Reset the [transport] object with message 0. on the right input doesn't work.
Turn Off, then On the scheduler overdrive doesn't work.
Turn Off, then On MSP work.
I have to go inside my patch but it's a little bit huge to make this right now unfortunately.
Effectively, I could make a smaller patch only with the fundamental of the problem : clock, performance quantization and see what happens. I will do it but later because I know that it's going to take a lot of time... Thank you a lot.