• 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: Urs Heckmann <email@hidden>
  • Date: Fri, 4 Nov 2005 10:10:03 +0100

Hiya Michael,

Thanks. That makes a lot of sense. So... as an example, if I have a stereo plug-in (2,2), with the possibility of using stereo side-chain (2 extra inputs), I

A: Call AUBase::SetBusCount with kAudioUnitScope_Input, 2 and kAudioUnitScope_Output, 1 (But when do I make such a call?)

AUEffectBase tells AUBase upon construction to initially have 1 Input Element and 1 Output Element. These are created by AUBase::CreateElements().


Now look at AUScope::SetNumberOfElements(UInt32 numElements). It's not too picky about the point of calling time.

So, in your case you'd just do this in your constructor derived from AUEffectBase:

CreateElements();
Inputs().SetNumberOfElements(2);

B: The host may or may not use bus 1, so I need to check by overridiing Initialize(...). If GetInput(1) returns 0 then there's no bus 1 connected.

C: The bus inputs are added as extra inputs in my AUKernel::Process(...)?

D: I believe my client wants different GUI depending on whether bus 1 is connected or not. That would required Initialize(...) to be called before the GUI (or "view") is created. Is there any guarantee about that?

No, there's no guarantee. An AU can be Uninitialized and Initialized again while the GUI is up and running (you can do this in AULab). This scared me, too, when I did my first steps, but actually it's not such a big problem.


You'd just let your GUI listen to kAudioUnitProperty_BusCount by installing an AUEventListener or an AUPropertyListener (Events are guaranteed to be scheduled in the User thread if I recall correctly, which is good because you can safely draw, but they were buggy on older versions of OS X). When you get the notification, your View can query the BusCount via Properties for InputScope and OutputScope. Then your view can switch accordingly.

If Properties sound to be a weird concept (i.e. your GUI framework doesn't know of such a concept), just create a private Parameter (one that you don't publish to the host in your Parameter list) that you change by AUParameterSet() (see AudioUnit Framework Headers) within your effect instance upon such changes. Your GUI can then simply react on a Parameter change. Although this is less elegant.

--

One word about Kernels (because you brought it up in a previous mail)... Kernels are a matter of convenience for simple AUs that support n:n channel configurations. The developer can set up a Kernel and doesn't need to bother with much of the specifics of the whole AU world. Pretty much everything is done for him in the default behaviour of the base classes. But this requires that a plugin concept can be squeezed into the simplicity of the Kernel concept...

... now, what many developers do in order to meet more complex concepts (i.e. where such a trivial task as Panning from left channel to right channel is involved) is to neglect the concept of Kernels and override

AUEffectBase::ProcessBufferLists(AudioUnitRenderActionFlags& ioActionFlags, const AudioBufferList& inBuffer, AudioBufferList& outBuffer, UInt32 iFrames)

This is pretty much equicalent to VST's ProcessReplacing() method. In your case, you'd get the normal N:M Buffers for Bus0 and then you'd check if there's some input on Bus1 and if so, pull that an process as desired.

Hope this helps,

;)  Urs

(And I hope I got the facts correct after a long absence from the list ;-)



Thanks,

Michael Olsen


In reading this thread, I am wondering if I have been correct in my assumption
that an input bus and output bus are independent from each other. In other
words, I'm thinking that Bus 0 is not a bus having both input and output, but
that the first input bus happens to be named "Bus 0" and the first output bus
happens to be named "Bus 0" but they are actually not connected automatically.


Channel configurations like {{1,1}, {1,2}, {2,2}} are not referring to
specific busses at all. The first number in any pair refers independently to
the input busses, and the second number in any pair refers to the output
busses. There is no assumed correlation between input bus 1 and output bus 1,
or input bus 0 and output bus 0, etc.


I'm not sure if thinking of input and output busses as independent entities
helps anyone else in their understanding, but it sure works for me.


P.S. to Michael: these are mostly great questions. Not seeming stupid at all.
CoreAudio terminology and code can be tough to master at first.


Brian Willoughby


Begin forwarded message:

From: john smith <email@hidden>
To: email@hidden
Date: Thu, 03 Nov 2005 21:55:15 +0100
Cc: email@hidden
Subject: Re: Channels and frames


William,

sorry for these questions that probably seem stupid, but I really have
trouble understanding what you're saying. It's almost like we're not
speaking the same language.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/


_______________________________________________
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


_______________________________________________ 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