Re: bus count and channel info confusion
Re: bus count and channel info confusion
- Subject: Re: bus count and channel info confusion
- From: "Angus F. Hewlett" <email@hidden>
- Date: Fri, 30 Jul 2004 19:21:44 +0100
Can you not try and synchronize things with the four or five major vendors
providing multi-out AUs so that everyone has Logic betas a month or so
ahead of time, and then just hit the switch?
Speaking for myself and FXpansion, we certainly have -no- intention to
support both ways at once in the same code. When Logic supports the right
way, so do we - ASAP. But, to have something ready for the users, we need
4-6 weeks to test everything.
>
Simply cutting the support for the old style like many suggested in
>
this thread seems a little rough
Yes, but there are really not so many multi-out AUs (and a fair few of
those that do exist are based on either the FXpansion wrapper or the Emagic
porting SDK). If those plus the Native Instruments ones are working OK,
that's probably 75% coverage... and most of the other 25% are regulars on
this list.
Regards,
Angus.
At 01:40 30/07/2004 +0200, Stefan Gretscher wrote:
>
Am 26.07.2004 um 20:02 schrieb William Stewart:
>
> The problem is that these 8 channels are really a collection of stereo
>
> and mono channels. If this is the only way (which Logic encourages by
>
> its implementation) that a synth can output more than one set of these,
>
> then it is *not* implementing this the way we've described and
>
> expected.
>
This is understood.
>
I really don't want to defend old Logic style by any means, I am sorry
>
if it
>
looked like that! I completely agree that the multi-bus concept is the
>
proper
>
way to go - Logic will take this route as well, I am just not sure how
>
to deal
>
with the transition from old to new style.
>
>
Simply cutting the support for the old style like many suggested in
>
this thread
>
seems a little rough to me as long as there's still so many AUs not
>
supporting
>
the new way, esp. as the old way is ugly but still not against AU specs.
>
So from a users point of view cutting it off is hardly more than
>
breaking existing
>
songs and workflows just for the sake of a beautyful concept...
>
>
As another idea, how about breaking the old Logic way when moving over
>
to Tiger? As Frank Hoffmann wrote earlier in this thread:
>
>> It is maybe unfortunate that Audio Units are allowed to do one thing
>
>> several ways
>
So why not melting down some options when upgrading to the next OS
>
instead of when upgrading a single host app? We could make Logic check
>
for the OS it runs on and then disable old Logic multichannel
>
accordingly.
>
Changing the OS seems a very reasonable occasion for everybody to
>
update their software, so this will be much easier for the user to
>
accept.
>
>
Talking about Tiger, there's a bunch of other things besides the old
>
Logic
>
multichannel problem I'd like to see unified, like for example the two
>
ways
>
of parameter notification. But that should be another thread I'd say,
>
once
>
we've finished this one :-)
>
>
> I agree with what Pavol was saying, that a synth that is capable of
>
> outputting more than 2 channels *should* publish an ACL to describe
>
> this capability.
>
I completely agree.
>
>
> I was (probably clouding the issue somewhat) making the point that this
>
> is not a hard and fast rule that can be expected to be applied across
>
> all AU's.
>
Ok thanks for clarifying that.
>
>
Stefan Gretscher
>
_______________________________________________
>
coreaudio-api mailing list | email@hidden
>
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
>
Do not post admin requests to the list. They will be ignored.
>
>
>
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd -
http://www.fxpansion.com
=======================================================
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.