Best Practices For Keeping Scheduler In Sync With MSP
Hello folks! I've been working on a live rig for myself the past several months, which is based mostly around playing back stems from my songs and improvising with a bunch of effects on top of it. Each song has a few sequencers from which pitch data is sent to effects and also some synths. At first I was doing all the sequencing at audio rate since that's obviously the only rock solid way to keep things perfectly in sync. However, a few months ago I decided to move all the sequencing over to the scheduler in order to free up CPU for other things, allow for easier polyphony with my synths, and in general just make things more compatible with my workflow outside of the live set, since I plan to use all these synths, sequencers, and effects for composition as well.
Obviously, the sequencers gradually drift out of sync with the MSP parts of the rig. I've found that if I restart the DSP between every song, I can get away with it since it takes several minutes for things to get really off. I've read many threads on this same topic, which have been helpful, however there are still some questions I have.
Why is it that the only way to get things synced back up is to restart the DSP rather than to briefly stop the scheduler? I was inclined to think that since the problem is the scheduler getting behind, the solution would be to stop the scheduler to allow it to "catch up". But doing so has never gotten things back in sync. Is it safe to conclude that once the scheduler gets behind, it stays behind?
To sum things up, I guess what I'm looking for is a way to get things synced back up without manually restarting the DSP. In an ideal world, I would be able to do song transitions haha. I know that the real solution is to just sequence at audio rate but I would much rather make this work. It doesn't have to be perfect.
For context, the two sequencers I'm using are delay based Markov chains. They are reset every N bars by metro. I've experimented with phasor -> delta-> edge -> for resetting instead of metro, but it doesn't help to keep things in sync at all. If anything, it makes it worse.
I've also experimented a bit with the slop time, but things will eventually get behind regardless of what it's set to. Also, I'm running I/O and SVS at 64 samples. Scheduler in audio interrupt makes things way way worse so I have that disabled. Overdrive is on.
Any insights are appreciated!! Thanks!
what is that MSP part of ther rig ?
Audio playback ?
does it provide any kind of sync to that data rate sequencers ?
here a little test
2 counters driven by metro 10 ms and count~ based
after running more then 2 hours still in sync
[quote]Obviously, the sequencers gradually drift out of sync with the MSP parts of the rig[/quote]
this should not really happen, but if it does, there is probably nothing you can do against it.
first of all: when everything time critical is max now, why would you need to keep the scheduler in sync with the DACs sample clock? as long as both run stable all is fine, no?
Hey Source Audio,
The MSP part I'm referring to is audio playback. My songs are split up into stems and then I'm using a sort of accumulator into peek to play them back. And no, it does not provide anything to the data rate sequencers, they are running parallel to the accumulators. I'll test out this little example you gave me, thanks!
Hey Roman,
My stem playback is still running at audio rate so I wouldn't say that everything time critical is max now. Sorry if I wasn't clear about that. The goal is to keep the sequencers in time with the stem playback, or at least find a good way of locking them back in sync once they get off.
What do you mean by this should not happen? It seems like the general consensus is that timing matters should be kept purely signal rate or purely scheduler to avoid these kind of sync issues.
Thanks!
yes of course, playing a long audio file or using signal LFOs would be the exception.
so let´s ignore that "it should not happen" (because it happens for you).
how does your sequencing look like? if it is based on metro and times using absolute values (ms) you might be able to replace your main metro with a patch which checks for the difference between its output and a signal-driven clock and correct the metro(s) on the fly to compensate for offsets as they appear.
one vector is probably to small, i would try 1000 ms distances first. the mechanism itself will still suffer from the need to jump from signal to scheduler domain, but at least it can´t run totally out of sync.
Roman,
Sounds like a promising idea! As I mentioned in the main post, the two (identical) sequencers are Markov chains based around the prob object plus a bunch of delays chained together. However, every N bars the sequence is reset by sending the stop message to all the delays and starting it over from the first step. This is triggered by a tempo locked metro -> counter (since notevalues are capped at 1nd but sometimes I want it reset every 2 or 4 bars, etc.) I'm thinking that even though most of the sequencing is done by delays, I could try your method for the reset metro and maybe that would be enough to keep things in sync. I'm attaching a picture of the reset mechanism (can attach the full patch if necessary as well). There are some receives that may not make sense out of context so I'm happy to explain whatever. The final trigger is connected to prob.
on the "control signal" side count~ might be your friend.
at 44100kHz, [%~ 44100] will give you a seconds meter, at a vectorsize of 64 samples you can edge~ or snapshot~ them (with an inaccuracy of up to 1.4 ms) and then compare the values from time to time to the time values your metro/delay stuff accumulated together since the last DSP start.
if the metro is suddenly 50ms too late, stop it at its next beat, wait for 50ms, start it again.
better way is not to use metros or delays but to use sync signal of audio playback
to create bangs, counters etc at set intervals.
For me that is the only way to get both worlds stay in sync over longer period of time.
No matter if you want to use ms, or tempo based sequencing.
it is easier to make but isn´t it jittery? (on a sub-ms level but still)
i have that audio vector based metro abstraction, but whos only use case is under NRT && without interrupt. (because this situation does not offer a scheduler thread at all)
Appreciate the help guys. Roman, I'm still a little confused as to how to implement your method exactly. Any chance you would share a little example? Thanks
Source Audio, thanks for reminding me that you can send a dsp restart message to max! If I can't get these reliable in sync at least I can program DSP restarts to happen between songs without having to do it by hand