[PD] one abstraction, different delay lines?
jakkesprinter at web.de
Wed Jul 15 11:52:36 CEST 2020
Thank you for these nice explanations!
Haha thats funny, i only know debouncing from electronics, where debouncing hardware switches is an important thing. But indeed, it is the same technique here:-)
I would definitely share the opinion that the system should not produce clicks when all effects are busy working. So my first step will be to figure out how many button sets and hence effects my system is allowed to have. I guess, that saving cpu will be a nice to have feature for later.
> Am 11.07.2020 um 20:27 schrieb Christof Ressi <info at christofressi.com>:
>> How would I do this? Is it possible to somehow check the volume that is going out to the outlets of a clone?
> Yes, but you need to use [send~]/[receive~] resp. [throw~]/[catch~], so can analyze a specific output and not the sum of all outputs. A simple way is to check the output of [env~]. The blocksize can be very short (e.g. 64 samples) and you don't need overlap. Of course, the silence/signal detection has to happen outside the actual subpatch, because DSP must be running.
> There is one problem, though: if the input signal has pauses, the processed signal might have pauses too, so must not switch off immediately, but only after a certain amount of silent blocks in a row. This technique of avoiding rapid state changes is called "debouncing". You can schedule the switch off with [delay] and send a [stop( message if a block is not silent. The delay time should correspond to the max. number of samples until the plugin output becomes silent (= "tail size").
> Actually, VST plugins often employ this technique to save CPU. For many VST2 and VST3 plugins, the host can ask the plugin for its "tail size", so it knows when it can stop processing. VST3 plugins also have a "silence flag" for each channel which can be set by the host, so the plugin itself can suspend processing if appropriate.
> On the other hand, some people argue that the system must be able to handle the max. number of effects anyway, and if you run all effects all the time and the CPU can manage it, you won't get any surprises. Of course, the big disadvantage is that the system uses more power than necessary most of the time.
>> On 11.07.2020 18:55, Jakob Laue wrote:
>> So, I was thinking about Dan's advice to turn the dsp on and off with [switch]. I will definitely need this feature for saving CPU.
>> Currently I am wondering which is the proper condition on that I decide to [switch] a clone off.
>> Let me explain with an example:
>> Say I have 10 button matrices, therefore I have 10 clones of my delay-effect. Each clone the delay-effect for one specific button matrix. When the user is playing a melody on the first button matrix and then switches to the second matrix, I am not allowed to [switch] off the delay effect on the first matrix, because even if the first matrix might not be triggering new midi notes anymore, the delay effect might be set to feedback = 100, an thus is still playing music.
>> So my first idea was to switch off the delay effect, when dryWet and feedback are set to zero. But then I would also have to check wether or not there is music coming in on the inlets off the delay effect...And what if I am not using a delay but a reverb effect. Then I would have to check different sliders...a little bit confusing i would say.
>> So then I had another idea: Couldn't I simply check (periodically) whether or not a delay-effect-clone is still sending audio to its outlets? I think that this would be a good general approach that could be applied to other effects, as well. How would I do this? Is it possible to somehow check the volume that is going out to the outlets of a clone?
>> Best, Jakob
>> Gesendet: Mittwoch, 01. Juli 2020 um 12:30 Uhr
>> Von: "Dan Wilcox" <danomatika at gmail.com>
>> An: "Jakob Laue" <jakkesprinter at web.de>
>> Cc: "Pd-List" <pd-list at lists.iem.at>
>> Betreff: Re: [PD] one abstraction, different delay lines?
>> (My mail program mangled this message for some reason, so I copy/pasted the quote below. I hope it's the correct one to respond to...)
>> Right now I have the master audio stream (= the audio of all matrices) going into the clone object, so it sounds like i have several delay effects with different settings on the master channel. It sounds nice, but it is not what I want right now:)
>> Jakob, the next step would be to add a [switch~] object to each of the instances inside the clone object, then enable/disable based which one you want to use. That could work as dsp will not be performed on those which are switched off, saving CPU.
>> A simple solution is for each instance to accept an "on" message with a float (1 or 0) to enable/disable. Then to enable as ingle one, send a [all on 0< message followed by the single one to enable, [1 on 1<.
>> On Jul 1, 2020, at 12:00 PM, pd-list-request at lists.iem.at wrote:
>> Message: 1
>> Date: Tue, 30 Jun 2020 13:31:57 +0200
>> From: Jakob Laue <jakkesprinter at web.de>
>> To: Christof Ressi <info at christofressi.com>
>> Cc: Pd-List <pd-list at lists.iem.at>
>> Subject: Re: [PD] one abstraction, different delay lines?
>> <trinity-6b0b8585-789d-4804-8ea8-2e84792187b9-1593516717310 at 3c-app-webde-bap20>
>> Content-Type: text/plain; charset="utf-8"
>> An HTML attachment was scrubbed...
>> URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200630/9648c0c4/attachment-0001.html>
>> Dan Wilcox
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list