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...@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@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
