Re: MusicDevice instrumentIDs and presets
Re: MusicDevice instrumentIDs and presets
- Subject: Re: MusicDevice instrumentIDs and presets
- From: Philippe Wicker <email@hidden>
- Date: Fri, 20 Jun 2003 22:57:36 +0200
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).
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.
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 :-))
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
_______________________________________________
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.