I think snapshot~ is your best shot. You can generate a bang out of a pulse signal with edge~ and throw it in snapshot~. But you probably already know that. I think this way you get a delay of exactly one vector size, which is inevitable when you're going from one domain to the other, right?

Yes, I know snapshot~. I'm however imagining exact (sample accurate) control over what is sampled when. The timing of the max messages themselves would indeed be related to the vector size.

How about using snapshot~ to read the output of sah~, using edge~ to trigger the snapshot~ whenever the sah~ gets triggered? Maybe that's what Dave Mollen is recommending; but it's different from simply using snapshot~ to grab the first sample from the next vector.

Since snapshot~ is triggered in the max domain this will not give additional accuracy of what is being sampled.

When you use Christophers strategy you'll sample at sample accuracy, but you'll receive the number with a certain latency. But there's no way around that I think.

But somehow it doesn't work with edge~. It seems like the bang from edge~ arrives before the updated value from sah~ arrives. It works pretty well when you give snapshot~ a reporting interval though. But that means you'll get more latency. Here's what I've tried.

Hi all,

Edwin, as soon as you transmit information from the signal domain to control domain, you basically use another thread, which has its own latency and accuracy. Except if you're working with "scheduler in audio interrupt" (which also brings its problems, and anyway does not allow to achieve a time precision to the sample), you will lose a lot of time accuracy in the operation.

I encountered this issue with sampling accuracy a significant number of time, and the only precise way to do it that I know is simply not to use control to do it. Everything has to be achieved in the signal domain, using exclusively MSP objects. This may be kind of tricky sometimes, depending of what you want to achieve, but it works for sure. There are numerous MSP objects that can help you for that. As examples, instead of record~, use poke~ with count~; instead of play~, use wave~ with count~ or a phasor~.

Just use control messages for asynchronous messages, that do not need a sample-based time precision.

The main problem I encountered was precision: in Max5, 32bit adressing of wave~ is sometimes not precise enough, and you can get glitches when playing back. But with 64bits in Max6 it should not be a problem.

And also, gen~ should be your friend for what you're looking for.

Cheers

Alexis

@Christopher & Dave, Sorry to have missed the point. Of course it's sample accurate because sah~ takes care of this. I've have extended the patch a bit so it's possible to interpret what happens. In Max 5 the solution with edge~ gives rather unpredictable output. Max 6 however behaves rather (almost completely) reliable when the scheduler is in the audio interrupt. Of course the vector size has to be smaller then the sampling interval. The difference between Max 5 and 6 is interesting because I'm quite sure that snapshot~ simply outputs the first sample from a vector.

This is the modified patch:

@Alexis thanks for the post. The differences are clear to me and over the years I have a developed a tendency of doing a lot of control oriented things in MSP. In this case however I'm interested in turning things that happen in MSP into events and that brought me to this problem.

For the moment I can move on. I think it would still be great to see this functionality in a single object one day, especially because the combination of sah~, edge~ and snapshot~ remains a bit unstable.

Thanks! Edwin