Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
[EMAIL PROTECTED] wrote: Message: 6 Date: Wed, 11 Jul 2007 17:34:40 + From: Martin Peach [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] 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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
Martin Peach wrote: 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) OK, I'll put in negative delays. great. and i forgot to mention, that you can always connect the 2nd outlet to a [max 0] so you get the original behaviour. That's a difficult problem. What's the difference between zero and zero? I mean how does one tag no delay as being different from a delay of zero without adding another outlet? There's a problem with unpackOSC at the moment in that if no time tag is received there is no output on the second outlet, so you have to externally zero the delay line after every message. that is _good_ news, as it allows one to detect the absence of a timetag. (no message is a message too...) one could also use bang as a more explicit indicator, but then one would _have_ to acknowledge the type too. (it's not such a good idea to send the bangs to the right inlet of [del]; but then this would enforce people to really take care of the timetags (if used at all), which is not necessarily a bad thing) so i am happy with anything that allows me to distinguish between now and immediately. another question: in osc, timetags are per-bundle (not per message). is the scheduling information sent to the outlet for each message or only once for each bundle? fgmas.dör IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
IOhannes m zmoelnig wrote: another question: in osc, timetags are per-bundle (not per message). is the scheduling information sent to the outlet for each message or only once for each bundle? The delay is output exactly once for each time tag. packOSC generates a time tag whenever a bundle is opened with a '[' message. It's possible for a bundle to contain other bundles whose time tags _must_ be later than that of the enclosing bundle. In that case I suppose you could get two or more delays output for a single message but the last delay would always be the correct one. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
Martin Peach wrote: IOhannes m zmoelnig wrote: nevertheless i think it might be very good if i could distinguish between the 3 types of timetags) That's a difficult problem. What's the difference between zero and zero? I mean how does one tag no delay as being different from a delay of zero without adding another outlet? OK, I changed packOSC to output negative delays and it's now obvious, even on the same machine a current time tag always has a slight negative delay, whereas an immediate time tag is always exactly zero. That leaves the slight problem of a future message that arrives exactly on time... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
On Jul 12, 2007, at 11:33 AM, [EMAIL PROTECTED] wrote: Martin Peach wrote: IOhannes m zmoelnig wrote: nevertheless i think it might be very good if i could distinguish between the 3 types of timetags) That's a difficult problem. What's the difference between zero and zero? I mean how does one tag no delay as being different from a delay of zero without adding another outlet? OK, I changed packOSC to output negative delays and it's now obvious, even on the same machine a current time tag always has a slight negative delay, whereas an immediate time tag is always exactly zero. That leaves the slight problem of a future message that arrives exactly on time... Martin Wow, nice work! That sounds like it'll be quite easy to use timetags now. Is there anyway to generate timetags with Pd yet? .hc ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
Hans-Christoph Steiner wrote: Martin Peach wrote: IOhannes m zmoelnig wrote: OK, I changed packOSC to output negative delays and it's now Oops, that should say unpackOSC... obvious, even on the same machine a current time tag always has a slight negative delay, whereas an immediate time tag is always exactly zero. That leaves the slight problem of a future message that arrives exactly on time... Martin Wow, nice work! That sounds like it'll be quite easy to use timetags now. Is there anyway to generate timetags with Pd yet? Well, packOSC does that when you open a bundle, you can also specify an offset. Is there a need for actual raw timetags? I started an external to generate them as a list of four floats (64 bits split into four 16-bit numbers). Then I realized it's easier to use millisecond delays since that's what pd is using, so unpackOSC just converts the received time tag into a millisecond delay relative to the current time. This could be altered easily by adding a constant at the outlet. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
