Re: app structure issues
Re: app structure issues
- Subject: Re: app structure issues
- From: Urs Heckmann <email@hidden>
- Date: Fri, 4 Oct 2002 19:36:15 +0200
Am Freitag, 04.10.02, um 18:33 Uhr (Europe/Berlin) schrieb Will Benton:
I'm thinking that one good design would be that the control portion of
the app generates dynamic "instrument" objects for each note sounded;
these "instrument" objects would have functions that would generate a
specified number of frames. Getting a noteoff message would cause the
instrument object to go into the decay portion of its envelope, and
eventually it would deallocate itself (or something). The callback
function then iterates through the list of active instrument , mixing
down their outputs.
Hmm, I havn't checked out the instrument side of AUs yet, but one thing
might be a common rule: You shouldn't allocate/deallocate objects on a
frequent basis in a realtime system. It would probably be better to
have a set (or list) of instruments (or voices as I would call them)
set up on initialize and then send a "gate on" message to one when a
note on happens and a "gate off" when the corresponding note off (note
on with zero velocity respectively) comes in. The big art is to know
when to address which voice. I have once implemented this with an "age
counter" and an idle flag. Idle voices (zero output) can be called
without hassle but if no idle voice is available I look for notes that
have been played for longer time than others. Gate off events would add
extra to the age counter and voices in release-mode would therefore be
"stolen" preferredly. Of course, gate on events would reset the age
counter to zero. I think this is how it's usually done.
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.