Re: Mutitimbral - philosophy
Re: Mutitimbral - philosophy
- Subject: Re: Mutitimbral - philosophy
- From: Brian Willoughby <email@hidden>
- Date: Wed, 16 Jul 2003 13:38:28 -0700
[ What about the labor overhead of a user who must instantiate 16
[ plugins before he can listen to a partner's emailed MIDI file?
[
[ Apologies for having an old-fashioned MIDI mindset...
[
[ Some sequencers automatically show all instantiated softsynths +
[ available external synths, in a MIDI Track DESTINATION pop-menu.
[ If a sequencer did not offer such routing, it might be difficult
[ to get me interested in buying the product.
...
[ Repeated apologies if I'm completely missing the point (GRIN).
I cannot say for sure that I understand the philosophy of MusicDevices, but I
assume it is at least somewhat akin to the CoreAudio HAL.
The goal with the HAL is to provide the most basic presentation possible -
i.e. a direct representation of the hardware, and nothing more. Pretty much
nothing about the HAL feature set is driven by the user experience - that's the
responsibility of the application developer. This allows the most efficiency
with any given piece of hardware, and also allows the most flexibility.
It certainly doesn't make sense from a user perspective for an audio device to
have a fixed sampling rate, but at the HAL level it might if that's a
limitation of the hardware. At the application level, the user should not be
aware of this because AudioConverter or the OutputAudioUnit options make
multiple sampling rates available even on hardware that has a fixed rate.
Of course, MusicDevices are supposed to be higher level and more flexible than
HAL drivers, but I think some of the philosophy of simplicity should hold.
If there is a way to accomplish something complex by combining multiple
MusicDevices, then I believe that the MusicDevice specification should not be
complicated by adding these abilities at the individual MD level. All of the
features that people are suggesting or requiring are valid, but they can be
handled by the application, and would even encourage more distinction among
different applications. Power users might not want the "ease" of dropping in a
16-channel multitimbral device, while most "normal" users would. This allows
for applications that are geared towards their user base.
It is certainly worthwhile to examine the limitations of sticking with
monotimbral MusicDevices. The question of whether CPU utilization is better
handled by MD settings, or in the host settings, is a question which doesn't
have an immediate and obvious answer. I'm certainly concerned that the various
quality settings for existing MusicDevices do not allow a one-to-one control
over the changes that affect the CPU. This works great for users who don't
understand CPU-hungry tasks, but there may be power users who will want finer
control over the parts of the algorithm that affect system load.
If the only reason for complicating the MusicDevice spec with multitimbral
features is to improve the user experience, then I say we do not need this.
Let the application developers distinguish their product. ... or, some
developers can release libraries or frameworks which implement commonly needed
behavior.
If there truly is an important feature which cannot be accomplished without
ganging MD units together in a multitimbral MD, then we should examine whether
there is another way. The example of dialing in voice allocation is a good,
real-world example, but I think it can still be handled by separate,
monotimbral units. If each MD publishes a parameter which announces its
current voice utilization, and also accepts a parameter which requests a limit
on how many voices will be used, then CPU load can still be controlled by the
host application without the units knowing about each other. An advanced host
application could look at all the units and set their quality parameter, or
other CPU load affecting parameters, such that the same result is obtained as
could be done in a multitimbral unit.
Just food for thought,
Brian Willoughby
Sound Consulting
_______________________________________________
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.