From: Vesa <di...@nb...> - 2014-02-16 10:11:38
|
On 02/16/2014 11:59 AM, Tobias Doerffel wrote: > Wow, that looks great! Sure we can (should!) include it in 1.0.0. I'm > also looking for a possibility to hide/replace the title bar for > individual MDI sub windows as the title graphics of your plugins > should do the job as well (but much better). The current redundancy > adds useless information and requires more space. Once I figured out, > I'll tell you so we can work on integrating a close button in the > title bar. > > Toby Ok, that sounds good! We should then do the same for LFO/Peak controllers. And maybe all other native effects as well? Although they don't all take too much space, it's still good to get rid of the redundancy. Also there was another thing I meant to ask you. Am I understanding the effect plugin structure correctly, when I assume that the method processAudioBuffer is called for every buffer, regardless of whether the effect is "active" or not? There's a check in the beginning of the method for isRunning and isEnabled, and if either is false, the method returns before processing. I'm assuming isEnabled is for whether the effect is enabled by the user (by the led checkbox), and isRunning refers to the state of the effect, where it's disabled after a certain amount of silence (controlled by the decay knob). So if I want the effect to execute some code when it's in the "not running" state (ie. after it gets switched off after silence), I could put it inside this if clause? I'd like the peak values to be updated even when the effect is disabled/not running, because otherwise, if the front-panel decay value is lower than the effect's release value, the next time the effect gets enabled again the peak value may have been left in a non-zero state, causing a slight pop in the audio. |