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

[Miller Puckette]

Yes, it's the same bug on all platforms; I just was imagining you were on a
Mac for some reason.  On MSW the same fix works, but compiling stuff is
more dodgy there so I don't go around suggesting people try to recompile on
their Windows systems.

cheers
Miller

On Sun, Aug 17, 2003 at 10:41:58PM +0200, errorsmith wrote:
> 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
> 
> 
> 
>