[David Robillard]
On Sat, 2012-06-02 at 11:37 +0200, Tim Goetze wrote:
As a plugin author, I consider all assumptions or guarantees about
the block size useless unless the plugin can tell the host exactly
what it wants, and get it everytime (and I'm not even sure it would be
worth it).
LV2's
[David Robillard]
On Fri, 2012-06-01 at 20:22 -0400, David Robillard wrote:
[...]
I am attempting to farm
precisely one piece of information: whether or not the above callback
can adequately express any reasonable block length situation; i.e.
whether or not any plugin could know yes, I can
On Sat, 2012-06-02 at 11:37 +0200, Tim Goetze wrote:
[David Robillard]
On Fri, 2012-06-01 at 20:22 -0400, David Robillard wrote:
[...]
I am attempting to farm
precisely one piece of information: whether or not the above callback
can adequately express any reasonable block length
On Mon, 2012-05-28 at 17:08 -0400, David Robillard wrote:
[...]
The buffer size feature is
mostly orthogonal and simple to add; ControlPort is the thing that
probably shouldn't have been inherited from LADSPA at all.
Back to the buffer size issue... (which is actually tangent to what this
On Fri, Jun 01, 2012 at 06:09:06PM -0400, David Robillard wrote:
LV2_Buf_Size_Status
get_block_length(LV2_Buf_Size_Buf_Feature_Handle handle,
uint32_t* min,
uint32_t* max,
uint32_t*
On Fri, 2012-06-01 at 22:22 +, Fons Adriaensen wrote:
On Fri, Jun 01, 2012 at 06:09:06PM -0400, David Robillard wrote:
LV2_Buf_Size_Status
get_block_length(LV2_Buf_Size_Buf_Feature_Handle handle,
uint32_t* min,
uint32_t*
On Fri, Jun 01, 2012 at 06:42:01PM -0400, David Robillard wrote:
On Fri, 2012-06-01 at 22:22 +, Fons Adriaensen wrote:
On Fri, Jun 01, 2012 at 06:09:06PM -0400, David Robillard wrote:
LV2_Buf_Size_Status
get_block_length(LV2_Buf_Size_Buf_Feature_Handle handle,
On Fri, 2012-06-01 at 22:56 +, Fons Adriaensen wrote:
On Fri, Jun 01, 2012 at 06:42:01PM -0400, David Robillard wrote:
On Fri, 2012-06-01 at 22:22 +, Fons Adriaensen wrote:
On Fri, Jun 01, 2012 at 06:09:06PM -0400, David Robillard wrote:
LV2_Buf_Size_Status
On Fri, 2012-06-01 at 20:22 -0400, David Robillard wrote:
[...]
I am attempting to farm
precisely one piece of information: whether or not the above callback
can adequately express any reasonable block length situation; i.e.
whether or not any plugin could know yes, I can run or no, my
I think providing synchronous control events, with 'future' values (at
least some distance L in the future) is the way to get that. Let's
pretend that the Ultimate Plugin Interface (UPI) 1.0 exists, works this
way, is stable and unmalleable, and all you have to work with to
deliver
your
On Wed, 2012-05-30 at 19:42 +1200, Jeff McClintock wrote:
I think providing synchronous control events, with 'future' values (at
least some distance L in the future) is the way to get that. Let's
pretend that the Ultimate Plugin Interface (UPI) 1.0 exists, works this
way, is stable and
From: David Robillard d...@drobilla.net
I'm a modular head, I remain convinced that control ports are nothing
but a pain in the ass and CV for everything would be a wonderful
fantasy land :)
It's called SynthEdit land *everything* is CV ;) (not on Linux sorry).
As it happens, I am
On Thu, 2012-05-31 at 06:59 +1200, Jeff McClintock wrote:
From: David Robillard d...@drobilla.net
I'm a modular head, I remain convinced that control ports are nothing
but a pain in the ass and CV for everything would be a wonderful
fantasy land :)
It's called SynthEdit land
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
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
On 05/28/2012 12:52 PM, Fons Adriaensen wrote:
They are not that stupid. And they didn't need me to find
out the things they did not like: extensions being created
and then deprecated, extensions that 'exist' on some web
page but are implemented nowhere, tutorials that start with
saying that
On Mon, May 28, 2012 at 02:58:55AM +0300, Stefano D'Angelo wrote:
(Maybe just for the record) I meant one version for sample accurate
control (whether by accessing future values or by the host providing
latency compensation) and another for live usage (virtually
latency-free, but less
2012/5/28 Fons Adriaensen f...@linuxaudio.org:
On Mon, May 28, 2012 at 02:58:55AM +0300, Stefano D'Angelo wrote:
(Maybe just for the record) I meant one version for sample accurate
control (whether by accessing future values or by the host providing
latency compensation) and another for live
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 control
signals at audio rate to the plugin and all problems evaporate...
The don't evaporate, they
On Mon, 2012-05-28 at 17:01 +, Fons Adriaensen wrote:
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 control
signals at audio rate to the
On Mon, May 28, 2012 at 01:30:37PM -0400, David Robillard wrote:
Take a filter plugin. Calculating the actual filter coefficients
from the 'user' parameters (frequency, gain, etc..) can easily be
10..1000 times more complex than actually using those coefficients
to process one sample. So
On Mon, 2012-05-28 at 19:48 +, Fons Adriaensen wrote:
On Mon, May 28, 2012 at 01:30:37PM -0400, David Robillard wrote:
Take a filter plugin. Calculating the actual filter coefficients
from the 'user' parameters (frequency, gain, etc..) can easily be
10..1000 times more complex than
I assume that computing parameter trajectories basically means
interpolating, and that inevitably introduces some latency.
That's a key point. Interpolating any sampled signal introduces latency.
let the host pass a limited number of future parameter samples at each
run() (could be
On Mon, May 28, 2012 at 05:08:02PM -0400, David Robillard wrote:
Assuming that by 'signals' you mean audio rate controls, yes.
Again, the exception is 'synthesis' modules. You'd expect a
VCA in a modular synth to do what the ADSR tells it to do,
even if that results in artefacts. But you
On Tue, May 29, 2012 at 10:06:42AM +1200, Jeff McClintock wrote:
You can't provide live MIDI playing 'in advance', you can't prove parameter
updates in advance, just like you can't provide live audio in advance. If
the plugin wants 'future' data to interpolate stuff, it needs to introduce
On Tue, 2012-05-29 at 10:06 +1200, Jeff McClintock wrote:
I assume that computing parameter trajectories basically means
interpolating, and that inevitably introduces some latency.
That's a key point. Interpolating any sampled signal introduces latency.
let the host pass a limited
On Mon, 2012-05-28 at 22:40 +, Fons Adriaensen wrote:
On Mon, May 28, 2012 at 05:08:02PM -0400, David Robillard wrote:
Assuming that by 'signals' you mean audio rate controls, yes.
Again, the exception is 'synthesis' modules. You'd expect a
VCA in a modular synth to do what the
On Sat, May 26, 2012 at 08:48:07PM -0400, David Robillard wrote:
Nothing cloak and dagger about it. If someone is prepared to pay me for
writing a report on something I do have strong opinions about (and very
probably because of that), should I refuse that ? It's a consultancy
job just
On Sun, May 27, 2012 at 7:16 AM, Fons Adriaensen f...@linuxaudio.orgwrote:
So it's my *behaviour* that bothers you. So be it. I'm not going
to change my opinions in function of the advancement of Free
Software or whatever 'higher cause' or marketing campaign, ever.
I've done my part of
On Sun, 2012-05-27 at 11:16 +, Fons Adriaensen wrote:
[...]
So it's my *behaviour* that bothers you. So be it. I'm not going
to change my opinions in function of the advancement of Free
Software or whatever 'higher cause' or marketing campaign, ever.
I've done my part of advocacy for
On Sun, 2012-05-27 at 10:01 -0400, Paul Davis wrote:
[...]
this type of clash isn't useful to anyone, and this is why i think
david gets so upset with them - that rather than there being
discussion that targets how can this be done (right)? there ends up
being a tone of well, this is wrong,
2012/5/26 Fons Adriaensen f...@linuxaudio.org:
1. telling a plugin that at N frames from the current position the
parameter P should have value V, and
2. doing the same, while also requiring that the plugin outputs
N frames at that time.
My argumentation is that doing (2) is a bad idea,
On Sun, May 27, 2012 at 01:19:36PM -0400, David Robillard wrote:
However, doing it for pay is professionally dishonest. When you are
paid to report on something as an expert, you are supposed to set a
higher bar for yourself than mailing list trolls. While the buffer size
analysis is fine
On Sun, 2012-05-27 at 21:59 +0300, Stefano D'Angelo wrote:
[...]
In practical terms, especially w.r.t. LV2, there may be a third way:
let the host pass a limited number of future parameter samples at each
run() (could be negotiated at instantiation time), so that the plugin
doesn't have to add
2012/5/27 David Robillard d...@drobilla.net:
On Sun, 2012-05-27 at 21:59 +0300, Stefano D'Angelo wrote:
[...]
In practical terms, especially w.r.t. LV2, there may be a third way:
let the host pass a limited number of future parameter samples at each
run() (could be negotiated at instantiation
On Sun, May 27, 2012 at 09:59:29PM +0300, Stefano D'Angelo wrote:
If I understand correctly an implication would be that you get uniform
sampling of parameter signals with control rate = sample rate /
nframes. I assume that computing parameter trajectories basically
means interpolating, and
2012/5/27 Fons Adriaensen f...@linuxaudio.org:
On Sun, May 27, 2012 at 09:59:29PM +0300, Stefano D'Angelo wrote:
If I understand correctly an implication would be that you get uniform
sampling of parameter signals with control rate = sample rate /
nframes. I assume that computing parameter
On Mon, May 28, 2012 at 12:00:36AM +0300, Stefano D'Angelo wrote:
So far so good, but in practical terms how could a plugin API allow
all use cases without requiring the plugin writer to do twice the
work? The only solution I can think of is getting future values in
case a host can provide
On Sun, 2012-05-27 at 19:56 +, Fons Adriaensen wrote:
On Sun, May 27, 2012 at 01:19:36PM -0400, David Robillard wrote:
However, doing it for pay is professionally dishonest. When you are
paid to report on something as an expert, you are supposed to set a
higher bar for yourself than
2012/5/28 Fons Adriaensen f...@linuxaudio.org:
On Mon, May 28, 2012 at 12:00:36AM +0300, Stefano D'Angelo wrote:
So far so good, but in practical terms how could a plugin API allow
all use cases without requiring the plugin writer to do twice the
work? The only solution I can think of is
On Fri, May 25, 2012 at 10:43:36PM -0400, David Robillard wrote:
I am making an LV2 extension for accessing and/or restricting the buffer
size. This is straightforward, but I need to know just what
restrictions are actually needed by various sorts of DSP.
The sort of thing we're looking
On Sat, 2012-05-26 at 10:02 +, Fons Adriaensen wrote:
On Fri, May 25, 2012 at 10:43:36PM -0400, David Robillard wrote:
I am making an LV2 extension for accessing and/or restricting the buffer
size. This is straightforward, but I need to know just what
restrictions are actually needed
On Sat, May 26, 2012 at 02:23:52PM -0400, David Robillard wrote:
[Something about buffer sizes]
I didn't follow the discussion, but maybe you want to address something
related, too: make the buffers 32-byte aligned, so that plugins can use
AVX.
I don't know who's responsible for providing the
On Sat, May 26, 2012 at 02:23:52PM -0400, David Robillard wrote:
This is not a problem. If a plugin exists that requires this
functionality, it won't work in hosts that can't provide that
functionality. Compared to the situation of that plugin not existing at
all, something has been
as once again another discussion that could be a useful technical
discussion turns into a stupid spitting match. sigh.
look fons, variable size frame counts were one approach to a genuine
problem: how to deliver automation data to plugins. but they were not
added solely for that reason.
you
On Sat, 2012-05-26 at 20:42 +0200, Adrian Knoth wrote:
On Sat, May 26, 2012 at 02:23:52PM -0400, David Robillard wrote:
[Something about buffer sizes]
I didn't follow the discussion, but maybe you want to address something
related, too: make the buffers 32-byte aligned, so that plugins can
On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrote:
as once again another discussion that could be a useful technical
discussion turns into a stupid spitting match. sigh.
So far I didn't spit and I have no intention to do such a thing.
look fons, variable size frame counts were one
On Sat, 2012-05-26 at 20:05 +, Fons Adriaensen wrote:
On Sat, May 26, 2012 at 02:23:52PM -0400, David Robillard wrote:
[...]
Which leads to an interesting observation: you extension
actually negates part of the core specs. So that is allowed ?
Sure it is. In this case, it's not even
On Sat, May 26, 2012 at 05:08:47PM -0400, David Robillard wrote:
Here, notice a plugin not working in the host is *inherent*. This is
why LV2 folks generally don't consider this a problem - it isn't one.
If the host literally *can't* provide a given feature (e.g. fixed buffer
size) and the
On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen f...@linuxaudio.orgwrote:
On Sat, May 26, 2012 at 04:22:58PM -0400, Paul Davis wrote:
as once again another discussion that could be a useful technical
discussion turns into a stupid spitting match. sigh.
So far I didn't spit and I have no
On Sat, 2012-05-26 at 16:22 -0400, Paul Davis wrote:
[...]
now, we can sit here and listen to you and dave mudslinging about the
sanity of this or that. you can, if you want, insist that everyone who
designed AU and RTAS and VST also don't understand audio programming.
maybe you're even right
On May 26, 2012 10:02:32 AM Fons Adriaensen wrote:
On Fri, May 25, 2012 at 10:43:36PM -0400, David Robillard wrote:
I am making an LV2 extension for accessing and/or restricting the buffer
size. This is straightforward, but I need to know just what
restrictions are actually needed by
On Sat, 2012-05-26 at 22:02 +, Fons Adriaensen wrote:
On Sat, May 26, 2012 at 05:08:47PM -0400, David Robillard wrote:
Here, notice a plugin not working in the host is *inherent*. This is
why LV2 folks generally don't consider this a problem - it isn't one.
If the host literally
Hello laddies,
I am making an LV2 extension for accessing and/or restricting the buffer
size. This is straightforward, but I need to know just what
restrictions are actually needed by various sorts of DSP.
The sort of thing we're looking for here is buffer size is always at
least 123 frames or
55 matches
Mail list logo
