Diemo Schwarz

Hi, when the DSP graph is changed, the sample clock looses a few vectors compared to Max's internal clock, see patch below. This is probably unavoidable, but it forces you to be super careful when recording audio and events in parallel, since the event timestamps drift apart from the audio events, as soon as you open or edit another patch during recording.

I wonder if there's an easy way to detect this in C (for our own event recorder mubu.record) or in the patch? ...preferably without having to make the event recorder external a DSP object and count samples to derive timestamps.

max-time-offset.maxpat

Hi, when the DSP graph is changed, the sample clock looses a few vectors compared to Max's internal clock, see patch below.  This is probably unavoidable, but it forces you to be super careful when recording audio and events in parallel, since the event timestamps drift apart from the audio events, as soon as you open or edit another patch during recording.
Sooooooo, I wonder if there's an easy way to detect this in C (for our own event recorder mubu.record) or in the patch?  ...preferably without having to make the event recorder external a DSP object and count samples to derive timestamps.
Cheers!


Hi, when the DSP graph is changed, the sample clock looses a few vectors compared to Max's internal clock, see patch below.  This is probabl

creeping-time-offset-between-internal-clock-time-and-audio-sample-time

woah, that goes pretty deep to make a recorder that remains accurate even for live-patching :D

from my more basic understanding, if when the dsp_chain is altered, there's a way to grab the event-clock timing and use the sample-clock timing to inform correction over the event-clock only at the moment the dsp_chain changes... that would be one way(?)... but that's basically what you're doing in patch-form above(at least up to the subtraction point in order to calculate the error)...

one way to interface with this change at any accurate level is through a dsp64 method within each instantiated msp object... this is the method called when any of them are placed on the dsp_chain so if there was some way to track things at this point, that might be a way in...

i guess this is my nooby way of just bumping your thread up again with all this 'food-for-thought' 😋😇

apologies i don't have an actual answer 😊

...i wonder, too, if it's important to consider how much these 'scheduler preference' settings will change everything on an individual-user-based level:

Screen Shot 2021-02-25 at 9.45.34 AM.png

when recording audio and events in parallel, since the event timestamps  drift apart from the audio events, as soon as you open or edit

from my more basic understanding, if when the dsp_chain is altered, there's a way to grab the event-clock timing and use the sample-clock timing to inform correction over the event-clock only at the moment the dsp_chain changes... that would be one way(?)... but that's basically what you're doing in patch-form above(at least up to the subtraction point in order to calculate the error)...

one way to interface with this change at any accurate level is through a dsp64 method within each instantiated msp object... this is the method called when any of them are placed on the dsp_chain so if there was some way to track things at this point, that might be a way in...
i guess this is my nooby way of just bumping your thread up again with all this 'food-for-thought' 😋😇
apologies i don't have an actual answer 😊

...i wonder, too, if it's important to consider how much these 'scheduler preference' settings will change everything on an individual-user-based level:

creeping time offset between internal clock time and audio sample time