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 [email protected] http://lists.puredata.info/listinfo/pd-dev
