[PD] opposite behaviour of [delay]

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.

Re: [PD] opposite behaviour of [delay]

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

Re: [PD] opposite behaviour of [delay]

but notice that speedlim doesn't loose the last bang, it reschedules it. so there will be an extra bang coming out when the delay time is over. Joao thanks! 2015-10-21 17:30 GMT-02:00 IOhannes m zmölnig : On 10/21/2015 08:36 PM, Jonathan Wilkes via Pd-list wrote: Max and

Re: [PD] connection problem with oggamp~ object

Hi, I never used oggamp but according to the message report, your stream is quite strange with 1Hz and 44100 channels Maybe metada have been swapped and then libvorbis fails to decode the stream ? Can you play the same stream with another software / decoder ? Best Antoine -- do it yourself

Re: [PD] opposite behaviour of [delay]

On 10/21/2015 08:36 PM, Jonathan Wilkes via Pd-list wrote: > Max and Pd's cyclone library have [speedlim] and iemlib, btw. gsdmr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and

[PD] LyonPotpourri 3.0 and fftease on deken?

If I could, I'd do it, but I don't, so... would anybody who's uploading libraries to deken do it? ;) Are there such people who's "doing it"? Anyway, I think these libraries are worth it. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and

[PD] WG: opposite behaviour of [delay]

It behaves slightly different to your abstraction - IMHO better. It does not block the last bang or whatever. It delays it until the scheduled time is over. Depends on what you need or want. Ingo ___ > Von: Pd-list [mailto:pd-list-boun...@lists.iem.at] Im

Re: [PD] opposite behaviour of [delay]

yeah, [speedlim] is not what I'm looking for, it doesn't really behave like my patch, it's quite different. So I'm still wondering if there is such a thing or just my patch cheers 2015-10-21 18:32 GMT-02:00 Ingo : > It behaves slightly different to your abstraction - IMHO

Re: [PD] opposite behaviour of [delay]

There’s also the rjlib vanilla implementation m_speedlimit. Dan Wilcox @danomatika danomatika.com robotcowboy.com > On Oct 21, 2015, at 2:41 PM, pd-list-requ...@lists.iem.at wrote: > > From: Alexandre

Re: [PD] opposite behaviour of [delay]

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]