Re: Mutitimbral - philosophy
Re: Mutitimbral - philosophy
- Subject: Re: Mutitimbral - philosophy
- From: Urs Heckmann <email@hidden>
- Date: Thu, 17 Jul 2003 00:00:20 +0200
Am Mittwoch, 16.07.03, um 22:38 Uhr (Europe/Berlin) schrieb Brian
Willoughby:
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.
Just food for thought
So I eat a little spoonful of it...
I think publishing voice utilization is exactly the stuff that would
make things more complicated.
a) Why should a Music Device be limitted to the concept of voices? I.e.
a setting where 3 parts play back samples, a fourth part being a
Vocoder or granular device that scrambles parts 1-3.
b) What if different parts sport different priority or another
heterogenuous management concept? - If we stick to real-world examples,
there are multitimbral boxes where you can assign (fixed) 3 voices on
part 1, monophonic parts 2 and 3 and dynamic voice allocation over
parts 4-16.
c) Sometimes, patches themselves eat up different numbers of voices.
They are already stacked.
d) Other times, patches define their own maximum voice count, like
monophonic, 4 voice max, fully polyphonic etc.
e) <irony>Objections are currently raised mostly from host developers,
not plugin designers. They'd be very happy and rocking the house if
they had to implement stuff like voice management + across plugin
borders by themselves</irony>
See, for simplicity sake, the host should need to know as little as
possible about any MD's internal workings. IMHO this is the point that
provides for flexibility.
"Multitimbral" in itself should be seen as this: A second dimension to
tint parameter changes. Not just "this parameter", "that other
parameter", but "this parameter here" and "that other parameter here"
_plus_ "this parameter over there" and "that other parameter over
there". - It's quite easy, and it is a concept that already exists in
our minds. Latter is an important argument when doing things right.
Cheers,
;) Urs
_______________________________________________
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.