Re: Recommended way to classify AU categories on the UI?
Re: Recommended way to classify AU categories on the UI?
- Subject: Re: Recommended way to classify AU categories on the UI?
- From: William Stewart <email@hidden>
- Date: Fri, 6 Aug 2010 17:56:56 -0700
On Jul 31, 2010, at 12:42 PM, Ross Bencina wrote:
> I wrote something along the lines of the following (I've added the AU type constants):
>> At the moment I have all AUs listed in a single tree by category:
>>
>> Instruments > Manufacturer (kAudioUnitType_MusicDevice)
>> Instrument/Effects > Manufacturer (kAudioUnitType_MusicEffect)
>> Effects > Manufacturer (kAudioUnitType_Effect)
>> Generators > Manufacturer ( kAudioUnitType_Generator)
>> Panners > Manufacturer ( kAudioUnitType_Panner )
>
> A lot of the confusion seems to stem from this:
>> Instrument/Effects > Manufacturer (kAudioUnitType_MusicEffect)
>
> I take kAudioUnitType_MusicEffect to be ambigous about being an Instrument with audio input, or an Effect with MIDI input, but Sophia Poirier wrote off list:
>> Actually it is not supposed to ever mean "instrument which takes audio input", just "effect that takes MIDI input". I remember asking once about it long time back on the CoreAudio email list and being told this by Apple folks. So my thoughts are that something like "MIDI-controlled effect" might be a less confusing label, in my opinion.
>
> Can anyone else confirm this please? Is anyone using kAudioUnitType_MusicEffect for "instrument which takes audio input".
No, should not be.
As Sophia pointed out, _MusicEffect is a subtype for those effects that can take MIDI commands directly (using MIDI to control some of the effect parameters).
The distinction really lies around the notion of a note. If your plugin creates a note (regardless of whether it is takes audio input or not), then it should be published as an instrument. A common (but not exclusive) pattern for these is that they have NO audio input, but the notes are created in response to either MIDI events, or MusicDeviceStartNote call.
An effect does NOT create "note" events, but rather processes a stream of audio. Some effects may have direct control capabilities using MIDI (for instance a pitch parameter on the audio - see AUPitch - could be controlled by the MIDI pitch bend wheel).
> Otherwise I will just put kAudioUnitType_MusicEffect plugins in my Effects category and delete the "Instrument/Effects" category from my UI entirely.
Yes, that would be my suggestion. Then if you have a way to route MIDI to an effect, you can just show the MIDI dialog for those _MusicEffect types. This is how AULab works.
Bill
>
>
> Thanks!
>
>
>> Unlike some hosts, all AUs are available in the same list (ie context
>> doesn't provide implicit filtering to only instruments/only effects, etc).
>>
>> Some of my users are finding this classification confusing. I suspect this
>> is largely because the whole Instruments, Instrument/Effects, Effects
>> classification is artificially based on i/o topology rather than functional
>> role -- so you can end up with variants of the same AU in different
>> categories (e.g. what the user expects to be an instrument is in
>> Instrument/Effects for example).
>>
>> I'm considering removing the top level categories entirely and listing all
>> AUs only by manufacturer, or flipping the hierarchy thus:
>>
>> Manufacturer > Instruments
>> Manufacturer > Instrument / Effects
>> Manufacturer > Effects
>> Manufacturer > Generators
>> Manufacturer > Panners
>>
>> Is there a recommended Apple way of representing the AU list?
>>
>> Thanks
>>
>> Ross.
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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