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 <[EMAIL PROTECTED]> 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" > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
