On 05/29/2012 01:03 AM, Fons Adriaensen wrote:
Things are different if the control data was not generated
'live' but e.g. created in an graphical automation editor
using a displayed recorded waveform - the one the plugin
will operate on - as the time reference. In that case
users will not expect
On Mon, May 28, 2012 at 10:49 PM, David Robillard d...@drobilla.net wrote:
On Tue, 2012-05-29 at 01:43 +0200, Albert Graef wrote:
On 05/28/2012 07:27 PM, David Robillard wrote:
For live plugins if you're going to stop continually running the
plugin,
you must deactivate it, so I can see
On 05/29/2012 02:23 PM, Paul Davis wrote:
there's a misconception right there, i think. you wouldn't deactivate it
to listen to the dry signal. you'd bypass it using some feature of the
host.
Yes, of course this depends on the host. But presumably an LV2 host
would then also deactivate the
On Tue, May 29, 2012 at 9:37 AM, Albert Graef dr.gr...@t-online.de wrote:
On 05/29/2012 02:23 PM, Paul Davis wrote:
there's a misconception right there, i think. you wouldn't deactivate it
to listen to the dry signal. you'd bypass it using some feature of the
host.
Yes, of course this
On 2012-05-29 14:37, Albert Graef wrote:
On 05/29/2012 02:23 PM, Paul Davis wrote:
there's a misconception right there, i think. you wouldn't
deactivate it
to listen to the dry signal. you'd bypass it using some feature of
the
host.
Yes, of course this depends on the host. But presumably an
On Tue, May 29, 2012 at 09:48:10AM -0400, Paul Davis wrote:
the question really is under what circumstances should the host/user call
deactivate/activate?
if the host/user has done this, then they should be clear on the
consequences. you don't call these functions in order to bypass a
Hi!
I'm CC'ing this to LAD and jack-devel with reply-to set to jack-devel,
hope the listservers keep the header fields intact.
Though it reads jackd1 there, it also affects jackd2.
No action has been taken, yet, but I tend to agree with the bug report
and (temporarily) disable celt support in
On Mon, May 28, 2012 at 10:49:06PM -0400, David Robillard wrote:
I'd say that the standard case here is to *keep* all the MIDI controller
settings, not reset them. Just imagine that you're running a reverb
which forgets all settings when you briefly deactivate it in order to
listen to the
On Tue, 2012-05-29 at 09:48 -0400, Paul Davis wrote:
[...]
you really want both (a) a method to stop and restart the plugin (b) a
method to reset to it back to the state it would have immediately
after instantiation. its not 100% whether deactivate/activate is
either of these ...
There is
On Tue, 2012-05-29 at 16:18 +, Fons Adriaensen wrote:
On Tue, May 29, 2012 at 09:48:10AM -0400, Paul Davis wrote:
the question really is under what circumstances should the host/user call
deactivate/activate?
if the host/user has done this, then they should be clear on the
On Tue, 2012-05-29 at 21:51 +, Fons Adriaensen wrote:
On Mon, May 28, 2012 at 10:49:06PM -0400, David Robillard wrote:
I'd say that the standard case here is to *keep* all the MIDI controller
settings, not reset them. Just imagine that you're running a reverb
which forgets all
From: Fons Adriaensen f...@linuxaudio.org
Subject: Re: [LAD] Plugin buffer size restrictions
On Mon, May 28, 2012 at 06:05:20PM +0300, Stefano D'Angelo wrote:
IMO it's easily said: if control rate audio rate it's plugin's
responsibility, otherwise the host feeds upsampled/filtered
On Wed, 2012-05-30 at 15:03 +1200, Jeff McClintock wrote:
From: Fons Adriaensen f...@linuxaudio.org
Subject: Re: [LAD] Plugin buffer size restrictions
On Mon, May 28, 2012 at 06:05:20PM +0300, Stefano D'Angelo wrote:
IMO it's easily said: if control rate audio rate it's plugin's
13 matches
Mail list logo
