[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)
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
[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
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
>
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, 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: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_
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 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
di
On Thu, 2012-05-31 at 06:59 +1200, Jeff McClintock wrote:
> > From: David Robillard
> >
> > 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*
> From: David Robillard
>
> 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 currently portin
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
> 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
> you
On Wed, 2012-05-30 at 15:03 +1200, Jeff McClintock wrote:
> > From: Fons Adriaensen
> > 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 sa
> From: Fons Adriaensen
> 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, othe
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, 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 wh
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 limit
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 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. B
> 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 negoti
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 co
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 samp
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
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
2012/5/28 Fons Adriaensen :
> 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 (virtu
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 acc
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 ever
On Sun, May 27, 2012 at 06:33:25PM -0400, David Robillard wrote:
> > Judging from the (quite limited) feedback I got on my report,
> > what you present as an inevitable quality of the whole LV2
> > project - things are 'designed' iteratively and as the result
> > of a lot of social interaction -
2012/5/28 Fons Adriaensen :
> 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
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 yourse
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 prov
2012/5/27 Fons Adriaensen :
> 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 b
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, a
2012/5/27 David Robillard :
> 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
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
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 fi
2012/5/26 Fons Adriaensen :
> 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, and even more
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 wro
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 L
On Sun, May 27, 2012 at 7:16 AM, 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 Linux A
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
On Sat, 2012-05-26 at 19:47 -0400, Tim E. Real wrote:
> I added variable run-length processing to MusE.
> It can break a period into single frame runs if necessary.
[...]
> What about encoder and decoder plugins? Yer switching matrices etc.
> Their precise control rates and timestamps must be prese
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 lite
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 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 rig
On Sat, May 26, 2012 at 4:59 PM, Fons Adriaensen wrote:
> 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
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
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 w
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 on
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 plugin
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 write
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 gai
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 bu
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
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 lookin
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
57 matches
Mail list logo
