[PD-dev] PD-cvs Digest, Vol 29, Issue 11

[IOhannes m zmoelnig]

pd-cvs-request at iem.at wrote:
> Message: 6
> Date: Wed, 11 Jul 2007 17:34:40 +0000
> From: Martin Peach <mrpeach at users.sourceforge.net>
> Subject: [PD-cvs] externals/mrpeach/osc packOSC-help.pd, 1.6, 1.7
> 	packOSC.c,	1.6, 1.7 unpackOSC.c, 1.3, 1.4 routeOSC-help.pd, 1.2, 1.3
> To: pd-cvs at iem.at
> Message-ID: <mailman.9.1184234402.17743.pd-cvs at iem.at>
> 
> Update of /cvsroot/pure-data/externals/mrpeach/osc
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5352
> 
> Modified Files:
> 	packOSC-help.pd packOSC.c unpackOSC.c routeOSC-help.pd 
> Log Message:
> unpackOSC now simply outputs (through the right outlet) a delay in milliseconds when it 
> receives a timetag, as the timetag itself is not useable inside pd.
> The delay is zero when the timetag is in the past.
> Help patches have been updated to match.
> Also corrected a mistake in packOSC.c timetag calculation.


cool feature, thanks martin.

however, i have 2 remarks:

the simple one:
is it possible to set the "current" timetag within the [packOSC] and the
[unpackOSC]? usually 2 osc-hosts should be synchronized via ntp, but who
knows...
otoh, this might be rather low priority...



the more complicated one:

"0" for past events is (imho) not a very good choice.
how should we distinguish between bundles that have just arrived "in
time" (where the natural delay is "0"), bundles that are tagged
"immediately", and bundles that arrived too late.

one solution might be to use negative delays: delaying objects, such as
[delay] and [pipe] just ignore negative values (so they behave the same
as when fed with "0"), but the user has the option to determine whether
the message arrived to late and can act accordingly (e.g. discard
messages that should have happened yesterday)

i haven't looked at the code, but what happens when a bundle is to be
processed "immediately": a delay of "0" is _not_ the same as no delay,
as can be seen in:

[bng]
|
[trigger bang bang bang]
|           |          [print c]
[print a]   |
            [del 0]
            |
            [print b]

which will result in "c, a, b"


so if i am to honour the timetags (via [del] or whatever), my
"immediate" messages will not be handled immediately (it sounds worse
than it is: due to the nature of network traffic, we could always assume
that the "immediate" bundle arrived a fraction of a second later...;
nevertheless i think it might be very good if i could distinguish
between the 3 "types" of timetags)


mfg.asdr
IOhannes