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