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