[PD] howto gain finer resolutions of message/audio interaction?

errorsmith me at errorsmith.de
Sun Aug 17 22:41:58 CEST 2003


Hello,

> (i.e., reverse the order of the two lines).  Then just ./configure and
make
> and vline~ should be as good as new... or just wait till Monday when I can
> get the compiled Mac version out.

It seems not to be only a bug in the Mac version. I found it in the windows
version.

I still find it very hard to understand how messages are coverted into audio
and the opposite. As I said I am a pd newbie, so maybe I overlooked
something. It would be very helpful to understand how the messages are
scheduled and in which cases the timetags are interpreted.
If all messages in pd are timestamped and more than one message per
audioblock are scheduled for a message to audio conversion,
it would make sense to use these tags whenever possible. For instance sig~
can allign the messages within an audioblock in dependence of the time tags.
I see no reason that it shouldn't do that. Also for the other way round: the
snapshot~ object can take all scheduled bangs at its input and sample the
audio signal at the times defined by the timetags of the bangs. Generate a
number for each bang, while the number messages have the same time tags as
the corresponding bangs.

But even if all conversions are using the time tags there is still a problem
with messages generated with threshold~. Say you want to generate a random
number on each zerocrossing of an audio signal with a treshold~ object and
you multiply the random number with the audio signal so that its amplitude
is changed with each zerocrossing. The problem is that even with timetags
the random number will have a delay of one audiobuffer since they will be
used in the next audiobuffer instead in the one where they were generated. A
workaround would be to delay the audio signal before it gets multiplied for
one audiobuffer. I think this workaround is quite uncomfortable since you
maybe need to delay other signals which are in sync to the mentioned signal.
Also the latency in live performances will be increased.

It would be nice to be able to set the "update rate" of the message
processing. It would make sense to set the wait period with block~. So if
you set block~ 1 then you would get sample accurate message processing if
you need it. This would be nice since block~ can be different for each
subpatch. So If you really need the sample accuracy then you put the
corresponding structure in a subpatch while the parent structure still have
a cpu friendly update period of one audio buffer.

I hope not to take too much of your time.

thanks and regards,

erik









More information about the Pd-list mailing list