Hi all, I searched for some info on the shortest time interval available for the tempo object. I pressume 1/ 44100 secs won't work. I'm trying to fill (sample) a table with sequenced snaphshot~ values taken from an audio signal.

Which is the shortest interval available on [tempo]?

do you mean [metro], not [tempo] ? because metro is limited to 1ms intervals.

also, snapshot~ only triggers on block boundaries, doesn't it?

yes, i meant the [metro] objetc, sorry. Thanks for the info, is there any other way to create such intervals (less than 1ms) without converging in [until]?

On the other hand, I think the snapshot~ does indeed print only block boundaries, since there's a set command to 'reset next DSP blocks', according to the help patch. But honestly, I don't how it works, I would love to have more information on these matters...

maybe someone else has experience that says otherwise,

but i don't think it's really possible to run sample-by-sample control messages to read/write/process audio signals.

there's a very good chance that you'll find ways to do what you want in signal domain exclusively, so i'd suggest to look into those.

[metro] has a 1 ms limit, but if you really need to go lower you can make your own [metro] with a [delay] and a [t b] to feed the bang back to [delay]. [vsnapshot~] can be used to avoid snapping to block boundaries.

However, I remember someone trying to do it this way and it was a cpu nightmare. So as mod said, try to stick to the signal objects for something like this.

could you guys tell me some of those objects? I'm actually to resynthesize the sampling folder, id est., snaphot~ a signal every sampling period and dumping it's value into a table, so that to get blocks.

Anyway, Maelstorm, that was kick ass way to go down with [metro]. I'll definetely try out and make the cpu sweat

Maybe could you use [rpole~ 1] or [vline~] to increment every sample and use it to feed a [tabwrite~] with it ? These numbers streams can be re-elaborated using [expr~].

@cacosomoza said:

could you guys tell me some of those objects? I'm actually to resynthesize the sampling folder, id est., snaphot~ a signal every sampling period and dumping it's value into a table, so that to get blocks.

Sorry, but I don't really understand what you're trying to say here. Can you try explaining it again, maybe with more detail?

yeah, sorry that was a nightmare sentence. I actually meant 'process' instead of 'folder'.

Basically, I am trying to sample an audio signal within pure data. I was thinking I could read sample values with the [snapshot~] object every (sampling rate)^(-1) seconds and dump each value on a table. Well, I actually got it to work with [t b b], [delay] and [vsnapshot~], as you told me.

How does [vsnapshot~] avoids block boundaries anyway? I tried with [snapshot~] first and the result was pretty strange. I would love to really understand the difference between both objects. And again, why the 1 ms restriction in the first place for [metro]? Is there a minimum 'a priori' time delay for [delay]? (or is it as fast cpu can manage between two bangs?)

nau, I will explore those objects you mention.

http://www.pdpatchrepo.info/hurleur/rawsampler.pd

You would be better off using [tabwrite~] for this. The whole thing could be simplified like this:

[osc~]
|
| [bang(
|/
[tabwrite~ dyn]

Clicking bang will fill up the table with the audio signal.

As for the block boundaries, all audio objects in Pd work on blocks (or vectors) of samples. They don't simply pass along one sample at a time. Instead they send blocks of 64 samples (by default). You can think of them like audio buffers at the DAC. So, each object gets a block of samples, processes them, and sends them to the next object to process. This is done for efficiency reasons.

Now, when most audio-rate objects receive a message, they wait until the end of the block for that message to take effect. Again, efficiency reasons. But sometimes you need more accurate timing. So that's where objects like [vline~] and [vsnapshot~] come in. They can take messages and still have sample-accurate timing with just a bit more of a hit on the computational load. So, specifically for those objects, [vsnapshot~] gives you the sample right when the bang was received, whereas [snapshot~] gives you the sample at the end of the block when the bang was received.

I'm guessing the reason why [metro] has a minimum of 1 ms is because [metro 0] would just cause a crash (it would be like [bang(-->[until]), so there has to be a limit. 1ms was probably chosen because [metro] really is meant to be more like a metronome clock (not an audio sampler), so that minimum probably seemed more than reasonable.