Re: AU MIDI events scheduled beyond next rendering slice
Re: AU MIDI events scheduled beyond next rendering slice
- Subject: Re: AU MIDI events scheduled beyond next rendering slice
- From: Urs Heckmann <email@hidden>
- Date: Thu, 7 Aug 2003 00:51:11 +0200
Am Mittwoch, 06.08.03, um 20:19 Uhr (Europe/Berlin) schrieb Jeremy
Sagan:
On Wednesday, August 6, 2003, at 01:46 PM, Philippe Wicker wrote:
It would be interesting to know the type of event when this occurs.
Note events? Program change? Bank select? Could it make sense for
some kind of event?
My first reaction when reading this is that it shouldn't happen, at
least for events such as notes, controls changes that affect the note
rendering, ... IMO, the scheduling of midi is the host's job, not
the AU's.
My personal opinion, from a host perspective, is that I agree. This
should not happen. It is the hosts job to do scheduling.
Hosts can't queue into a running render process...
Hence a plugin has to accumulate timestamped events and use them when
they are due...
... also, my queue does the trick of intelligently assigning/stealing
notes with some reasonable "future knowledge", which I honestly
wouldn't allow any host to handle.
http://www.u-he.com/vstsource/archive.php?classid=4#19 (updated today)
To let the cat out of the bag: Under certain conditions, my render
process (!) will schedule a NoteOff by itself if a sound already faded
away (i.e. short sample), even if "the key is still pressed", so to
put an idle voice back into the pool. The host can't know that and will
probably steal a voice that is still heard... just some tricks to
enhance user experience...
(well, I could write a book or two about note stealing now 8-)
If, for some reason, it must be like this, then this raises more
questions: how long in the future, are they still sorted by time, how
many of these events, types of such events. Knowing the answers to
these questions would give hints to AUs developers about how they
should implement that "future events" queue.
In fact, several plug-ins will not work unless events are sorted in
time order and, as I mentioned earlier, Apple's own DLS Soundfont
player plug-in will not work correctly unless note-offs with the same
time are sorted before note-ons.
Hmm, I have seen NoteOn/Off combos at same time quite often now, in
several hosts. What are they for, from the perspective of a host
designer?
And I agree with DLS, sending a NoteOff _before_ a corresponding NoteOn
is completely messy. Any NoteOff I get that is not for a NoteOn I
already have, will immediately be trashed. Otherwise I will need a
really, really long queue (capable of holding 2048 NoteOffs + some
extra for thread safety + a HUGE, really, really HUGE scanning
overhead)...
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.