[PD] opposite behaviour of [delay]

[Matt Barber]

While we're talking about ways to limit output of message delays (etc.),
check out also the [debounce] abstraction in extended.

Alexandre's attached idiom is quite common in other areas, too, like
protecting a [readsf~] from all input until it has finished playing, or
halting all input to a synth abstraction while it is generating an event.
One strategy I like even more is finding a way to route all the incoming
information intended for the object in question back out for further
processing (perhaps another delay or readsf~ or synth abstraction is open
and can accept the event).

On Wed, Oct 21, 2015 at 11:42 PM, Liam Goodacre <liamg_uw at hotmail.com>
wrote:

> If you'll allow more than one object, then a combination of [onebang] or
> [once] with [delay] should do what you're looking for. You'll need to reset
> them each time, but it should still be simpler than using spigots.
>
> Incidentally, from you title I was hoping that you were asking for a
> [delay] object that would schedule a bang n milliseconds *before *it was
> triggered. Now that would be something!
>
>
>
> > howdy, [delay] ignores multiple input bangs and considers only the "last"
> >
> > from the help file:
> > "sending a "bang" to a [delay] which is already set will reschedule its
> > output, cancelling the old one."
> >
> > What if I wanted the opposite, like, further bangs will be ignored and
> not
> > reschedule the output. The output would then be rescheduled only after it
> > did output something and then received a new bang. Is there an object
> that
> > does that?
> >
> > I made a patch that does it, with [spigot], seems to handle the job. Find
> > it attached.
> >
> > cheers
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151022/b8440f30/attachment.html>