Re: Presets etc.
Re: Presets etc.
- Subject: Re: Presets etc.
- From: Urs Heckmann <email@hidden>
- Date: Fri, 10 Jun 2005 11:42:07 +0200
Bill,
I'm, a bit confused now...
... what we were referring to was changing the list of Factory Presets.
Not just setting a Factory Preset.
Or do you say that, if the list of Factory Presets has changed, any AU
state currently set to a Factory Preset must be updated? - That would
be uncool for several reasons (i.e. what if the new list has less
entries and so the currently set preset number exceeds the boundary of
Factory Presets?).
For ease of use and all, I suggest this analogy to hardware units:
Factory Presets are like a ROM. On some sophisticated devices this ROM
part can be exchanged on the fly.
.aupresets or any sort of externally stored classinfo are like a RAM,
FlashROM or floppy disk.
The present preset aka AU State is an edit buffer. Setting any preset
updates the edit buffer, but any changes of ROM, RAM, Floppy whatsoever
have no effect on it, unless the user takes further action -> switches
to new preset.
Any change of the edit buffer has no effect on the ROM.
Every instance of an AU is like a seperate hardware device. Whenever
you buy a new device (create a new instance), you get Factory Preset
ROMs for free. Thus, changing the ROM on one doesn't affect the others.
Needless to say, but while buying a new hardware doesn't automatically
clone all your floppy collection, the number of externally stored
.aupreset doesn't change (naturally, as the location for .aupreset
files is fixed)
In short & in order to avoid confusion:
- The list of Factory Presets can change
- Factory Presets belong to instances, i.e. if they are exchangable,
they are not static accross all instances
- Changing the list of Factory Presets does not affect that AU state /
classinfo
- Changing the list of Factory Presets is nothing that secretly happens
in the background. It must be a transparent process, caused by an user
interaction that has the sole purpose to do just this or that commonly
implies a change of the list.
I think this would be the easiest and most predictable way to deal with
dynamic FP lists. Any not so strict requirement in the AU spec should
be avoided.
Examples of changes to the list of Factory Presets and reasons
therefore:
- The custom gui of an AU lets the user retrieve a folder of .aupreset
files to be treated as Factory Presets for this single instance.
- For a live gig a musician prepares several instances with different
lists of Factory Presets because he can switch through them with Midi
Program Changes. He needs different sets for different instances.
- The AU treats a certain folder as the list of Factory Presets. The
user puts a new .aupreset into this folder and expects *all* instances
to change their list. In that case all instances will listen to folder
changes and issue a PropertyChanged notification on the list of Factory
Presets. (Is this the token worst case?)
- A modular AU (think Reaktor) switches to a new structure of "patch
cords" (think Reaktor Ensembles). The list of Factory Presets would
change to presets that comply with the new structure.
- A crazy plugin developer generates all Factory Presets by
randomization. Thus every instance has a different list from the
beginning, but the user can re-randomize the list.
- An AU has different sets of Factory Presets depending on
environmental properties, i.e. if a Side Chain is available or any type
of Channel Configuration is present (Stereo/Surround/Quattro). Changing
the track properties makes the AU instance change the list of Factory
Presets.
Funnily, I currently don't deal with Factory Presets myself, but I
think some clarification would be cool.
Cheers,
;) Urs
Am 10.06.2005 um 01:09 schrieb William Stewart:
Factory Presets are well, Factory Presets - we really don't expect
them to be changing - the analogy we used was ROM presets in Synths.
Generally they'd be global settings across all AU's, but there's no
strict requirement that this is the case.
There's a little bit of confusion about how these are set, and how
things catch these being set.
Basically the general approach we'd see is that the host (or whoever
sets a preset - whether this is the factory preset or a .aupreset -
the ClassInfo property), is that the setter is responsible for sending
any all parameters have changed notification. From AUHosting - when
the aupreset is set:
AudioUnitParameter changedUnit;
changedUnit.mAudioUnit = mTargetUnit;
changedUnit.mParameterID = kAUParameterListener_AnyParameter;
RequireNoErr (AUParameterListenerNotify (NULL, NULL,
&changedUnit));
There's currently a bug in both AU Lab and in the Carbon Generic View
that is when a Factory Preset is set, this notification isn't sent.
One property you can listen to that would indicate that the factory
preset has been set on an AU is kAudioUnitProperty_PresentPreset
Bill
On 08/06/2005, at 12:33 AM, Jeremy Sagan wrote:
Hello!
Is this the best way to listen for changes in the factory presets:
err = AudioUnitAddPropertyListener(au,
kAudioUnitProperty_FactoryPresets, myfactoryPresetChangedProc,
this);
static void myfactoryPresetChangedProc(void *plug, AudioUnit ci,
AudioUnitPropertyID inID,
AudioUnitScope inScope, AudioUnitElement inElement)
{
switch (inID)
{
case kAudioUnitProperty_FactoryPresets:
RefreshFactoryPresets(VPlug);
break;
}
}
Thanks,
Jeremy
On Apr 28, 2004, at 10:32 AM, Urs Heckmann wrote:
Hiya,
Specs wise, you can propagate a new list of Factory Preset by firing
a notification that kAudioUnitProperty_FactoryPresets has changed
8-)
Then, a well behaved host shouldn't hesitate to query this property
once again and update its preset menu.
But I guess, this is not the case currently...
However, unlike VST lingo, IIRC this would account for all instances
of that AU plugin.
Cheers,
;) Urs
Am 28.04.2004 um 15:48 schrieb Pavol Markovic:
Dear list,
I've read many opinions that VST mimics limited abilities of hw
machines. But isn't the AU fixed factory preset list something
restricted, too? Where is the software flexibility - it's main
advantage over hw. It's true that you can have fixed preset list
for simple reverb and work with it without problems, but for synths
you need patches sorted into categories - and to let users manage
them, to add new preset banks - this is what makes them usable. Yes
Urs' way is fine, but this works only for AU only plugins, unless
you'll write your own AU preset handler on other (sw and hw)
platforms. But this way it is AU format which dictates how the
things have to be organized.
PM
_______________________________________________
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.
urs heckmann
email@hidden
www.u-he.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.
_______________________________________________
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
--
mailto:email@hidden
tel: +1 408 974 4056
_______________________________________________________________________
___
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
_______________________________________________________________________
___
_______________________________________________
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