• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Channels and frames
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Channels and frames


  • Subject: Re: Channels and frames
  • From: Marc Poirier <email@hidden>
  • Date: Thu, 27 Oct 2005 09:58:39 -0400

On Oct 27, 2005, at 6:30 AM, john smith wrote:

I do just want to throw in here that I would encourage you to consider whether you really need to limit your effect to these configurations.


Thanks for your consideration. What you need to know is that what I'm creating is a wrapper to a geneic format.
The way we're doing it, the plug-in decides the number of channels (which can then, for multi-channel plugs, i.e. synths, be set in the interface).
This is to support all platforms. Some of them, for instance Cubase as I recall, tends to show all outputs, even if not used.


As for effect plug-ins I want to limit them to the configurations I mentioned, i.e. 1->1, 1->2 and 2->2 and maybe in some cases 2->1. This is for performance reasons. A dynamic channel count decreases performance too much IMHO.

Why on earth would it decrease performance? I mean, obviously processing 6 channels is going to most likely use more resources than processing 2. But I don't think that only allowing 2 somehow solves this problem. All it does is remove possibly valuable options. And a plugin that allows any number of channels isn't going to use any more resources processing 2 channels than a plugin that only allows processing 2 channels, unless there's some really weird and bad design being used that I'm not thinking of. So yeah, how can this possibly add performance problems? I've been doing it with most of my AUs (always when possible) with zero problems, and only advantages.



If your plugin doesn't have any inter-channel dependencies, or if it does but they can easily scale to any same number of inputs and outputs, then I would really encourage you to do that. It's a nice capability of AU, and personally I feel that too many effects don't do that when they easily could. And in fact, if that's what you were to do, then you could forget about this SupportedNumChannels() thing, cuz the default for effect AUs is to not support the property, and not supporting the property = saying "I can do any number of channels, as long as the number of inputs and outputs are equal."

Oh, that's interesting.

But besides the performance thing, some questions arises which I guess could be called "semantic". For instance, say I have a reverb, and I get 3 channels, what do I do? With 2 channels the answer is obvious, and with 1 channel I *could* (even if I'd prefer not to) make it stereo, and mix it down the single channel.

What's not obvious is what you are talking about. What do you mean, "what do I do?" As I said, if you're dealing with no inter-channel dependencies, than you just process more channels the same as you processed the first couple. If you do have inter-channel dependencies, then you decide if the design is scalable. If not (failing the first 2 possibilities), then you limit your channel configurations. There's nothing about reverb's basic nature that limits you to stereo, so I really don't understand your question. If you are talking about some specific reverb algorithm that does some special stereo field stuff and that is integral to its algorithm, then that would fall under the category of inter-channel dependencies that can't be scaled. So sure, there are cases like that, but more often than not, that's not a real limitation.



So, honestly I feel that such a system is not really too useful. I don't automatically support surround streams, just by adding extra channels.

Yes it does. Surround streams have more than 2 channels. If you can support any number of channels, than you can support processing any type of surround stream. I can't figure out why you might think that that's not true?



Marc _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Channels and frames
      • From: "john smith" <email@hidden>
References: 
 >Re: Channels and frames (From: "john smith" <email@hidden>)

  • Prev by Date: Re: Channels and frames
  • Next by Date: Re: Channels and frames
  • Previous by thread: Re: Channels and frames
  • Next by thread: Re: Channels and frames
  • Index(es):
    • Date
    • Thread