el.samm~ and count~ go out of sync with max 5.1.3
I have a show tomorrow and I’ve just noticed a problem with a patch that used to work correctly (i upgraded max since then, and overlooked the problem in earlier tests of the patch).
I’m using el.samm~ and count~ together in a patch. With previous versions of max, these two would stay in sync as expected. With max 5.1.3 though, when i use the Core Audio driver for my EDIROL FA-66 soundcard, the sync between these objects drifts. Though if i use the Core Audio built-in driver for my macbook, they stay in sync as expected.
I need the two to stay in sync when using my Edirol soundcard. I’m running at 44100 sampling rate. Any help in solving this would be greatly appreciated.
Test patch is attached.
Once you use edge~ to move from the signal to the message domain, you are no longer assured sample-accurate performance. In that case the signal vector size could become a significant factor in the performance of your patch. Try a smaller vector size and you may get better performance. In general, when trying to debug a system involving several objects, you might want to test each individual object separately. Finally, in this patch you are using two separate metronomes and hoping for the best. You might try a redesign so that there is only one master clock in your patch. As a side note, this kind of problem is why I always try to keep timing in the signal domain.
Good luck,
Eric
Hi Eric,
Thanks for the comments. In the test patch the edge objects are there just to demonstrate the drifting. The problem isn’t that they aren’t lighting at exactly the same time, but that they’re flashing at entirely different rates (I may not have worded that very clearly earlier).
I agree completely that it’s best to stay as much as possible in the signal domain, your objects are really useful for that. Unfortunately in my case (at least i thought) it was necessary to use a count~ object as well as samm because i’m storing single sample ‘triggers’ in a buffer, and i need to be sure they get read out again, by feeding the buffer players (xplay) with a continuous sequence of whole sample index integers.
I reinstalled a previous version of max, and that didn’t solve the sync problem. So i’m wondering if it could be something to do with the general state of my OS. ugh!
Linking clicks to ramps has been on my todo list for awhile, but C74 has gotten there first with an elegant object called sync~. Maybe that could be the basis for redesigning your patch.
Eric
Thanks Eric, that patch is helpful.
Do you know whether reading a buffer index based on a sync-ramp * buffer-length-in-samples, is an approach that can be relied upon to safely read every sample in the buffer without skipping any? (assuming the buffer was recorded into at the sampling rate).
I avoided doing this initially because i though there might be subtle problems with rounding leading to skipped samples. But if this works then i think it would solve my problems.