Here's a patch that outputs the actual time of the bangs from a metro, and also shows the phasor~ clone generated using vline~. You can see that the actual time that the metro outputs is +/- 5ms (on my system), but the phasor has a constant period anyways! Craziness.
So if I wanted to use PD to schedule some other program or device, would I want to send along some sort of timestamp based on the logical time to keep the timing tight? Perhaps this is a solution for some people who have been running into scheduling sloppiness when controlling hardware devices? It probably would be very doable to have an arduino do micro-scheduling of events based on a timestamp received along with the messages that are supposed to trigger the events.
is anybody doing this already?
-spencer
#N canvas 193 278 652 300 10; #X obj 62 136 realtime; #X obj 62 189 -; #X obj 62 160 t f f; #N canvas 0 0 450 300 graph1 0; #X array $0-waveform 1000 float 0; #X coords 0 1 999 -1 200 140 1; #X restore 395 68 graph; #X obj 62 217 print realtime; #X obj 201 162 vline~; #X msg 201 140 0 , 1 10; #X obj 254 162 metro 100; #X obj 139 86 metro 10; #X obj 139 109 t b b; #X obj 167 7 tgl 15 0 empty empty empty 0 -6 0 10 -262144 -1 -1 0 1 ; #X obj 167 28 t b f f; #X obj 200 186 tabwrite~ $0-waveform; #X connect 0 0 2 0; #X connect 1 0 4 0; #X connect 2 0 1 1; #X connect 2 1 1 0; #X connect 5 0 12 0; #X connect 6 0 5 0; #X connect 7 0 12 0; #X connect 8 0 9 0; #X connect 9 0 0 1; #X connect 9 1 6 0; #X connect 10 0 11 0; #X connect 11 0 0 0; #X connect 11 1 8 0; #X connect 11 2 7 0;
On Dec 17, 2007 11:58 AM, Derek Holzer derek@umatic.nl wrote:
OK, now I've got it. This can be explained! It especially makes sense with the old "infinite looping" counter patch:
[f]X[+ 1]
where [+ 1] gets sent to the hot rather than the cold inlet of [f]. It wouldn't be such a problem if it only counted on signal blocks, but it actually counts as fast as the CPU will let it.
Great, concept is clear, I can continue!
best, d.
IOhannes m zmoelnig wrote:
Derek Holzer wrote:
So now that I've been told that actually DSP objects are "slower", it shakes up my world view a bit, so I'm looking for new metaphors to get it back together ;-)
all the "slower" vs "faster" is non-sense.
signals are handled in a _synchronous_ way (they have to process 44100 samples per second; synchronized with the soundcard); they do this continuosly (once you have started the audio-engine they will process 44100 samples/sec until the end of the world, or the audio engine gets stopped)
messages are handled in an _asynchronous_ way: "they happen on demand!"; they might occur every now and then; two messages might occur at the same logical time,...
so all in all, messages are way more powerful than signals.
unfortunately, CPU is not. that is one reason, why the oh-so-powerful messages are not used for signal processing.
mfg.asdr IOhannes
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 22: "Be less critical more often"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list