Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
OK, thanks for going into it a bit more. Makes sense to me, of course, but I'll have to chew on it a while and think of a way to communicate it without twisting up people's heads too much at too early a part of the workshops ;-)
Actually for workshops it's easy: A [metro 1] will send a bang every 1 msecs, regardless what's happening with audio. Nothing complicated about that. In Max/MSP it's more complicated, as a [metro 1] may send bangs with varying periods of not always 1msec. But Pd is easy.
Though, even in Pd, GUI messages are treated special: If you click on a [bang( message, this will only be evaluated every 64 samples. But you probably cannot click the mouse repeatedly with a constant 1 msec period anyways, so it shouldn't matter.
The second thing, people need to learn then is, that most signal objects can only be scheduled on block boundaries. So if you send a new frequency to an [osc~] as a float message, the osc~ will not respond immediatly, as it has already calculated the next block of samples. So the new frequency can only be taken into account for the next block after that. IIR block here means 64 samples always, regardless of block~ size. But I may be wrong about that.
[vline~] is one of the few special objects which additionally can "look into the future" and change it's value kind of in the middle of a block (other objects like that are vsnapshot~ and Claude's wonderful analogue-envelope generator - and I'm working on making the as of now unreleased lua~/vessel~ external clock-aware, too). But this "see the future" only works for messages, that Pd already knows about, and these are messages that originate in a clock-based object like metro, delay, pipe, etc. Messages not coming from there, i.e. GUI messages, cannot be known in advance of course. But as these are quantized to 64 samples anyway, it doesn't matter most of the time.
Ciao
Frank Barknecht _ ______footils.org__