I know that in Max it is to the millisecond (0.001 seconds). Same for Pd?

@Maelstorm said:

In other words, if there are no audio objects in the chain, they will process as fast as possible.

So, a basic timer will determine how quickly message-rate is at any given time? There is no set speed threshold?

yes the message rate is instantaneous but some objects have a threshold at which they can go no faster, e.g. metro can't go < 1 ms, bang~ cannot go any faster than 64 samples. delay can though so it's pretty easy to make a "vmetro" object. seems like [timer] is sample accurate though
I'm purely talking about generating control signals at a given time interval, of course if you use [until] it will happen all at once, instantaneously
and [timer] will give an accurate result, just tested it with [delay]

As far as I know, no message rate function can be processed during an audio tick (block of 64 samples in default case). Audio ticks and message queue are processed in turn. Say, if you trigger one million message rate operations using [until], they will all happen in between two audio ticks. This may cause signal buffer underrun if the processing takes longer than the length of the audio tick. If I remember well, Max MSP has slightly more flexibility in scheduling. On Pd-list, Roman Haefeli has posted an abstraction [nbuntil] to spread workload according to measured CPU load, thus avoiding buffer underrun and dropouts.

By the way, polling of keyboard and mouse goes at a slower rate than the default interval between audio ticks: somewhere between 10 and 40 milliseconds. If you want to trigger messages with good timing from a human interface, a midi device is needed.

Katja

@katjav said:

By the way, polling of keyboard and mouse goes at a slower rate than the default interval between audio ticks: somewhere between 10 and 40 milliseconds. If you want to trigger messages with good timing from a human interface, a midi device is needed.
Katja

Which I noticed by using a touchscreen on windows. However, iPodtouch over osc/wifi works like a charm.

Cheers!

That's really helpful, Katja. Thank you.

@katjav said:

As far as I know, no message rate function can be processed during an audio tick

But this was not formulated so carefully because signal objects can sometimes receive and / or send messages as well. Such messages are processed within the signal objects perform method, therefore within the audio tick time.

Katja

Just so I am clear: unless messages are included within an signal object's perform method (i.e. within compiled object program code; is that what you mean?), we can safely assume that no message rate function can be processed during an audio tick?

@ricky said:

Just so I am clear: unless messages are included within an signal object's perform method (i.e. within compiled object program code; is that what you mean?), we can safely assume that no message rate function can be processed during an audio tick?

Yes that is what I meant to say. You can't use message objects like [metro] with sample-precise timing, unless you would set signal block size to 1. The default signal block size of 64 is a compromise. It would be very CPU intensive to do a function call for each sample in each signal object, therefore it is done blockwise in the 'perform loop'. Any message interrupt would defy that purpose.

Some objects like [threshold~] derive a message from a point in the perform loop iteration and present it at a message outlet in the signal object. In those cases too, messages come at the block boundaries.

A block of samples as exchanged by signal objects could be considered a list, which can only be handled by signal objects, not by message objects. However the [zexy/unpack~] and [zexy/pack~] objects can convert between these domains. This way, it is possible to access individual samples at message rate. See Toxonic's post on the matter:

http://puredata.hurleur.com/sujet-5257-audio-floatstream-message-domain

Katja

@katjav said:

A block of samples as exchanged by signal objects could be considered a list, which can only be handled by signal objects, not by message objects. However the [zexy/unpack~] and [zexy/pack~] objects can convert between these domains. This way, it is possible to access individual samples at message rate. See Toxonic's post on the matter:

http://puredata.hurleur.com/sujet-5257-audio-floatstream-message-domain

Katja

A thought on this...

If you insert a [tabsend~] and [tabreceive~], you have access to the raw blocks of data in tables. It appears you can operate on those tables using message objects upon receipt of a [bang~].

In the attached code, I do a simple volume control by operating on those tables - after rfft~ & before rifft~. Surprisingly, it's all kept in sync with no distortion. I wonder how much processing you can get away with on these tables?

I'm such a noob... I'm just starting to teach myself these concepts, the attached code is helping me learn & visualize what's going on with blocking, hanning, fft~ vs rfft~, etc.

Shawn

http://www.pdpatchrepo.info/hurleur/Learning-10-FFT-tabsend-tabreceive-1.pd