Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
On Sun, 2006-06-18 at 21:50 +0200, Frank Barknecht wrote:
I'm not sure what exactly you mean with "granularity" here, but if you could only generate messages in steps of ~1.5 msec or 64 samples at 44.1kHz you could forget about using Pd to do techno music someone would actually dance to.
sorry, but how can you generate messages, that are _not_ aligned to a 64 sample grid ...
Every "clock-delayed message" (metro, del, pipe, qlist, ...) is not aligned to 64 samples, GUI generated messages like clicking on a [bng] are aligned. However to actually make use of this in signal externals, you need to do some extra work. vline~ does. See attached patch and doc/3.audio.examples/C04.control.to.signal.pd
well, a |metro 100.2| will create delays of 100.13ms and 101.59ms ... (logical time, 64@44100Hz)
Nope, it won't. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sun, 2006-06-18 at 21:50 +0200, Frank Barknecht wrote:
I'm not sure what exactly you mean with "granularity" here, but if you could only generate messages in steps of ~1.5 msec or 64 samples at 44.1kHz you could forget about using Pd to do techno music someone would actually dance to.
sorry, but how can you generate messages, that are _not_ aligned to a 64 sample grid ...
Every "clock-delayed message" (metro, del, pipe, qlist, ...) is not aligned to 64 samples, GUI generated messages like clicking on a [bng] are aligned.
the clock callbacks are run between two audio blocks ...
However to actually make use of this in signal externals, you need to do some extra work. vline~ does. See attached patch and doc/3.audio.examples/C04.control.to.signal.pd
vline~ achieves subsample accuracy by delaying samples for the next dsp block ... it's not, that actual messaging is happening ...
t
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
Am 19.06.2006 um 01:55 schrieb Tim Blechmann:
On Sun, 2006-06-18 at 21:50 +0200, Frank Barknecht wrote:
I'm not sure what exactly you mean with "granularity" here, but
if you could only generate messages in steps of ~1.5 msec or 64 samples at 44.1kHz you could forget about using Pd to do techno music someone would actually dance to.sorry, but how can you generate messages, that are _not_ aligned
to a 64 sample grid ...Every "clock-delayed message" (metro, del, pipe, qlist, ...) is not aligned to 64 samples, GUI generated messages like clicking on a
[bng] are aligned.the clock callbacks are run between two audio blocks ...
we have todistinguish between logical time and real time. I must say
that i also didn't know that PDs logical times can have sub-ms
accuracy (maybe because i don't do techno music!) but i made a small
patch to be convinced (attached).
On the other hand it's clear that these sub-ms logical times can't
really make it over to the DSP side (since every DSP block is
processed as a whole) without using tricks (vline~)
greetings, Thomas
Thomas Grill http://grrrr.org
Thomas Grill wrote:
we have todistinguish between logical time and real time. I must say that i also didn't know that PDs logical times can have sub-ms accuracy (maybe because i don't do techno music!) but i made a small patch to be convinced (attached). On the other hand it's clear that these sub-ms logical times can't really make it over to the DSP side (since every DSP block is processed as a whole) without using tricks (vline~)
i guess that the important thing here is to distinguish between jitter and the overall behaviour: when you trigger a sample it doesn't really matter whether you have sub-ms accuracy, since it is not perceivable anyhow. otoh, running 2 [metro]s at 100ms and 100.5ms might produce a perceptable drift.
fmg.asdr. IOhannes
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
However to actually make use of this in signal externals, you need to do some extra work. vline~ does. See attached patch and doc/3.audio.examples/C04.control.to.signal.pd
vline~ achieves subsample accuracy by delaying samples for the next dsp block ... it's not, that actual messaging is happening ...
But it doesn't matter when the actual messaging is happening: Clock delayed messages *know* when they are supposed to happen, they have a kind of timestamp, and vline~ takes care that they *do* happen at that time, regardless of wether that is inside of a signal block or not.
In every practical aspect I can think of this is equivalent to being delivered without quantization.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
However to actually make use of this in signal externals, you need to do some extra work. vline~ does. See attached patch and doc/3.audio.examples/C04.control.to.signal.pd
vline~ achieves subsample accuracy by delaying samples for the next dsp block ... it's not, that actual messaging is happening ...
But it doesn't matter when the actual messaging is happening: Clock delayed messages *know* when they are supposed to happen, they have a kind of timestamp, and vline~ takes care that they *do* happen at that time, regardless of wether that is inside of a signal block or not.
In every practical aspect I can think of this is equivalent to being delivered without quantization.
Many feedback scenarios are not possible with signals in blocks, and also some non-feedback processes do not work with signals in blocks if there is a signal->message->signal flow.
See attached patch: it would be cool if the table would show a staggered line when the bng is clicked, however it shows only a straight line, which indicates that the output of [threshold~] doesn't reach the lower [phasor~] in time.
Claude
http://claudiusmaximus.goto10.org
#N canvas 17 20 295 282 10; #X msg 161 129 0; #X msg 137 49 0; #X obj 15 206 tabwrite~ $0-threshold-test; #X obj 15 226 table $0-threshold-test 64; #X obj 15 17 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 55 79 phasor~ 689; #X obj 162 109 threshold~ 0.75; #X obj 80 149 phasor~ 689; #X obj 55 179 -~ 1; #X connect 0 0 7 1; #X connect 1 0 5 1; #X connect 1 0 7 1; #X connect 4 0 2 0; #X connect 4 0 1 0; #X connect 5 0 6 0; #X connect 5 0 8 0; #X connect 6 0 0 0; #X connect 7 0 8 0; #X connect 8 0 2 0;
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Many feedback scenarios are not possible with signals in blocks, and also some non-feedback processes do not work with signals in blocks if there is a signal->message->signal flow.
See attached patch: it would be cool if the table would show a staggered line when the bng is clicked, however it shows only a straight line, which indicates that the output of [threshold~] doesn't reach the lower [phasor~] in time.
I think, you're missing to send a 0 to threshold's right inlet. And I don't see a vline~ anywhere in your patch! ;)
Your patch brings up the problem, that the right, phase inlet of phasor~ or osc~ is not prepared to deal with clock delayed messages, but only handles "normal" messages, that is, it quantizes these messages to block boundaries. I think, I mentioned this in this thread already. We should open a feature request.
I made another built-in clone for phasor~ with metro and vline~ called vhasor~. Here the phase inlet is accepting and evaluating clock delayed messages.
Then additionally I'm not sure, if the right inlet of threshold~ deals clockdel messages correctly. As I understand the source code, it does some extra work to generate clock delayed messages as well, however my attached test patch still doesn't stagger correctly. I'm not sure yet, why.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Then additionally I'm not sure, if the right inlet of threshold~ deals clockdel messages correctly. As I understand the source code, it does some extra work to generate clock delayed messages as well, however my attached test patch still doesn't stagger correctly. I'm not sure yet, why.
Okay, attached is another test which shows, that [threshold~] always reacts on block boundaries. So this object is not useable for converting signals to messages with sub-block accuracy. I guess, we need something like an anti-vline~.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Claude Heiland-Allen -
Frank Barknecht -
IOhannes m zmoelnig -
Thomas Grill -
Tim Blechmann