Re: MusicDevice instrumentIDs and presets
Re: MusicDevice instrumentIDs and presets
- Subject: Re: MusicDevice instrumentIDs and presets
- From: Bill Stewart <email@hidden>
- Date: Fri, 20 Jun 2003 16:18:01 -0700
On Friday, June 20, 2003, at 01:57 PM, Philippe Wicker wrote:
On Friday, June 20, 2003, at 05:09 AM, Bill Stewart wrote:
Most of the existing synths today do not support the concept of
instruments or multi-timbral - essentially this is done by the user
to have to have multiple instances of a synth unit open, and the host
provides the services for mapping selectors for setting different
patches.. This makes the synth itself a bit easier to write, as it
just manages its current, single inst, state, and puts a burden on
the host to provide the flexibility, etc of managing the different
presets, libraries, etc...
Does that mean that AU MusicDevice developer may assume that the
choice of the instrument have to be provided by some host UI (and
therefore that there's no need to provide this choice in the AU UI)?
This would make sense. Beside it may be confusing if such choices can
be done in different places (and it would need some work to keep both
sides in sync).
That's a good question... I think for the preset based synths this is
essentially a requirement. For a "multi-timbral" synth... I'd expect I
guess that the AU has some work to do...
All well and good...
(Just gathering my thoughts here!)
So - I think the general rule (as with any other property) should
also be applied to this problem, with the instrument Count
property... As Chris outlined, for synths that don't support this
concept, their instrument count would be zero.. For synths that do,
then hosts should listen to it! :) This can and will change...
The "implication" I think of a synth unit supporting instruments is
that it provides the instrumentIDs for selecting particular
instruments.. Think of a DLS bank - these ID's are hard coded into
the bank itself. We would not expect a negotiation to occur between a
host and a unit with regards to instrument ID's - In the situation
you describe I would expect that the AU's-UI to do (as you say) most
of the work and the host receives its "instructions" - of course it
can do its own remapping on top of this, but it should send to the
synth what the synth reports to it.
However, when the user does change an instrument as you outline, the
AU will need to issue a property change for not only this instrument
count property but also other properties (instrument names for one
and some others that we'll detail when we can, but we'd probably use
some kind of extensible mark up language to describe patch name lists
and MIDI channel capabilities - guess we better get working on that >> :)
I agree. InstrumentCount is not enough.
There's another potential problem that comes to my mind (a little bit
off topic but related in a way). If the user has modified a preset (on
the AU side), how can we guarantee that the modifications are given a
chance to be saved when the window is closed, or when the AU is
cleaned up before the user has saved? Maybe there is some work for the
host here.
Sure - the AUParameterListener would take care of this "need to know"
Its a good point - we'll have to make sure this behaviour is
defined... Who's volunteering to write the synth that lets me (the
user) do this?
Well, hmmmm, I guess I should be (one of) the volunteer(s) :-) But you
may have to wait sometime before you can play with :-))
That's fine...
Bill
Bill
On Thursday, June 19, 2003, at 12:41 AM, Jeremy Sagan wrote:
On Wednesday, June 18, 2003, at 05:56 PM, Philippe Wicker wrote:
This discussion leads me to ask a corollary question. Some kind of
MusicDevices will allow the user to build instruments and banks "on
the fly" (I think about soft sample players). The user may - will
-want to listen to the result in "real time" without first saving
its new program (instrument) then the instrument in a bank and the
whole thing in a preset and finally reload this preset in the host.
When working with a real (hardware) sample player, you can load,
add, remove, edit samples/instruments and hear the immediate result
while sounds are played. It would be nice if such a behavior was
available with any "AU compliant" host. Most of - if not all - this
work is to be done on the AU side, but as soon as a new instrument
is created by the user - by the mean of the AU custom UI - the host
could reflect this change in its own UI (eg the menu(s) to select
instrument/midi channel). Do you think that hosts should be
required (or maybe we could talk of hosts UI design guidelines) to
listen to some parameter/property to achieve that?
Yes, that would be very cool. I would definitely be a listener!
Jeremy
_______________________________________________
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.
-- 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
______________________________________________________________________
____
_______________________________________________
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.
Philippe Wicker
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
________________________________________________________________________
__
_______________________________________________
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.