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: Jeremy Sagan <email@hidden>
- Date: Wed, 6 Aug 2003 20:11:12 -0400
Urs,
I think you are misunderstanding me. I will try to clarify.
On Wednesday, August 6, 2003, at 06:51 PM, Urs Heckmann wrote:
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-)
I am not sure what you are responding to here. I was just trying to
write what Bill eventually wrote more eloquently "But (and the
documentation is I think clear on this), the frame offsets are always
described as being offsets into the NEXT slice of audio that is to be
rendered (and for ramped parameters, they are rescheduled for each
slice),..." Thus the AU only needs to keep track of one buffer full of
data for MIDI events.
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?
If you are asking about a note that has 0 duration then I do not know.
Otherwise this is usually due to step recording. If there is a note
with duration 100 and is back to back with another note that begins at
time 100 then you will see, at time 100, a note-on and a note-off and
they could, of course, be the same pitch.
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)...
I think you are misunderstanding my initial email. I agree there is no
reason to send a note-off before a note-on but as I mentioned above
there is a perfectly valid scenario where a note-off and a note-on can
occur at the same time. In that case if the note-on appears to the DLS
AU before the note-off (remember this is even though the time stamps
are the same) it causes the DLS to not play the note-on.
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.