[PD] timing question

[Spencer Russell]

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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>