On 13/8/2009, "David Robillard" wrote:
>On Thu, 2009-08-13 at 10:08 +0100, james morris wrote:
>> I was trying to point to the question of: Why base the replication of a
>> control port on the replication of the audio ports? The audio port
>> replication is based on the number of channels, so ba
On Thu, 2009-08-13 at 18:48 +0100, james morris wrote:
> On 13/8/2009, "David Robillard" wrote:
>
> >On Thu, 2009-08-13 at 10:08 +0100, james morris wrote:
> >> I was trying to point to the question of: Why base the replication of a
> >> control port on the replication of the audio ports? The aud
On 13 Aug 2009, at 20:01, David Robillard wrote:
>> I'm assuming the only ports to be replicated are those which have
>> say a
>> multiPort property. I don't see why replication would not be the same
>> in a plugin instance, across all ports with that property.
>
> Because larger plugins can have
On Thu, Aug 13, 2009 at 09:27:20PM +0100, Steve Harris wrote:
> On 13 Aug 2009, at 20:01, David Robillard wrote:
> >> I'm assuming the only ports to be replicated are those which have
> >> say a
> >> multiPort property. I don't see why replication would not be the same
> >> in a plugin instance,
On 13/8/2009, "Fons Adriaensen" wrote:
>On Thu, Aug 13, 2009 at 09:27:20PM +0100, Steve Harris wrote:
>
>> On 13 Aug 2009, at 20:01, David Robillard wrote:
>> >> I'm assuming the only ports to be replicated are those which have
>> >> say a
>> >> multiPort property. I don't see why replication
On Thu, Aug 13, 2009 at 11:16:14PM +0100, james morris wrote:
> >How would a port type tell e.g. a multichannel limiter plugin if
> >it has to limit each channel separately, or use the same gain
> >reduction, based on the loudest one, on all ?
>
> All the port type (property) would do is say this
On Thu, 2009-08-13 at 21:27 +0100, Steve Harris wrote:
> On 13 Aug 2009, at 20:01, David Robillard wrote:
> >> I'm assuming the only ports to be replicated are those which have
> >> say a
> >> multiPort property. I don't see why replication would not be the same
> >> in a plugin instance, across
On Thu, 2009-08-13 at 23:53 +0200, Fons Adriaensen wrote:
> On Thu, Aug 13, 2009 at 09:27:20PM +0100, Steve Harris wrote:
>
> > On 13 Aug 2009, at 20:01, David Robillard wrote:
> > >> I'm assuming the only ports to be replicated are those which have
> > >> say a
> > >> multiPort property. I don'
On Fri, 2009-08-14 at 01:26 +0200, Fons Adriaensen wrote:
> On Thu, Aug 13, 2009 at 11:16:14PM +0100, james morris wrote:
>
> > >How would a port type tell e.g. a multichannel limiter plugin if
> > >it has to limit each channel separately, or use the same gain
> > >reduction, based on the loudest
On Thu, 2009-08-13 at 19:48 -0400, David Robillard wrote:
> On Thu, 2009-08-13 at 21:27 +0100, Steve Harris wrote:
> > On 13 Aug 2009, at 20:01, David Robillard wrote:
> > >> I'm assuming the only ports to be replicated are those which have
> > >> say a
> > >> multiPort property. I don't see why
On 14 Aug 2009, at 00:48, David Robillard wrote:
>> Several channels on a mixer should be doable with the 1/N channels
>> restriction.
>
> A mixer usually has several 'strips', each of which may have different
> counts. Like the ardour mixer, for example. This is a simple,
> realistic, and useful
On Fri, 2009-08-14 at 10:13 +0100, Steve Harris wrote:
> On 14 Aug 2009, at 00:48, David Robillard wrote:
> >> Several channels on a mixer should be doable with the 1/N channels
> >> restriction.
> >
> > A mixer usually has several 'strips', each of which may have different
> > counts. Like the ar
On 14 Aug 2009, at 15:56, David Robillard wrote:
> On Fri, 2009-08-14 at 10:13 +0100, Steve Harris wrote:
>> On 14 Aug 2009, at 00:48, David Robillard wrote:
Several channels on a mixer should be doable with the 1/N channels
restriction.
>>>
>>> A mixer usually has several 'strips', each
On Fri, 2009-08-14 at 17:09 +0100, Steve Harris wrote:
> On 14 Aug 2009, at 15:56, David Robillard wrote:
> > Perhaps a simpler example: an n->m panner. Are you really going to
> > argue that an n->m panner is not a useful plugin!?
>
> That's a more compelling example, but it can be done with M *
On 14 Aug 2009, at 17:30, David Robillard wrote:
> On Fri, 2009-08-14 at 17:09 +0100, Steve Harris wrote:
>> On 14 Aug 2009, at 15:56, David Robillard wrote:
>>> Perhaps a simpler example: an n->m panner. Are you really going to
>>> argue that an n->m panner is not a useful plugin!?
>>
>> That's
On Fri, 2009-08-14 at 20:01 +0100, Steve Harris wrote:
> On 14 Aug 2009, at 17:30, David Robillard wrote:
>
> > On Fri, 2009-08-14 at 17:09 +0100, Steve Harris wrote:
> >> On 14 Aug 2009, at 15:56, David Robillard wrote:
> >>> Perhaps a simpler example: an n->m panner. Are you really going to
> >
On Fri, Aug 14, 2009 at 04:47:22PM -0400, David Robillard wrote:
> Surround panning is not trivial, and not a small amount of code. It is
> exactly the sort of thing you'd want a plugin for.
Very true. More generally, one reason for wanting plugins in any
audio processing system is to allow for
On 14 Aug 2009, at 21:47, David Robillard wrote:
>>
>> The host can do it automatically, obviously.
>
> The host can do it automatically with the C multiplication operator as
> well, obviously.
True, but irrelevant.
If you have N channels feeding a panner with 5.1 outs v's N channels
feeding 2.
On Fri, 2009-08-14 at 23:41 +0100, Steve Harris wrote:
> On 14 Aug 2009, at 21:47, David Robillard wrote:
> >>
> >> The host can do it automatically, obviously.
> >
> > The host can do it automatically with the C multiplication operator as
> > well, obviously.
>
> True, but irrelevant.
>
> If you
On 15 Aug 2009, at 00:36, David Robillard wrote:
> On Fri, 2009-08-14 at 23:41 +0100, Steve Harris wrote:
>> On 14 Aug 2009, at 21:47, David Robillard wrote:
The host can do it automatically, obviously.
>>>
>>> The host can do it automatically with the C multiplication
>>> operator as
On 15 Aug 2009, at 19:25, Steve Harris wrote:
> It's all about making the easy cases easy, and the complex cases
> possible - something I believe in strongly, though I know not everyone
> shares that worldview.
>
> I guess a counter argument could be that hosts that can't handle /
> don't like the
On Sat, 2009-08-15 at 19:34 +0100, Steve Harris wrote:
> On 15 Aug 2009, at 19:25, Steve Harris wrote:
> > It's all about making the easy cases easy, and the complex cases
> > possible - something I believe in strongly, though I know not everyone
> > shares that worldview.
> >
> > I guess a counter
22 matches
Mail list logo
