3 May
2004
3 May
'04
8:47 a.m.
[Jens M Andreasen]
I should have included some kind of man page:
agree about the sorting of events (which btw is mandatory for the
host with run_synth() following <dssi.h>).
however, i insist that the midi_msg() idea deters performance by
forcing the host to split audio blocks (cache coherence and more
indirect function calls). in effect, run_synth() demands less from the
plugin (no MIDI byte stream parser with error correction mechanisms
needed), thus results in more readable event parsing code and leaves
the decision about sub-cycle length to the plugin, which is a good
thing.
it also seems worth noting that forcing an event's audio frame offset
into 8 bits is a bit meagre. it's not uncommon to run at 2+ k frames /
audio cycle, and some interfaces and systems won't go below 512
frames/cycle in the first place. off-line processing may even involve
a lot longer audio cycles.
tim
msg[0] = midi_status;
msg[1] = midi_data_1;
msg[2] = midi_data_2;
msg[3] = sample_offset; // counting from most recent rendering.
Personally I can ignore sample_offset, but to
others it is a
prerequisite.
... and I realize now that I should not totally ignore sample_offset. I
would probably try to change the internal status to fit with 64/32/16
samples, or whatever is the rendering fashion of the day.
And one more thing: The host should do the sorting and interleaving of
events from those devices it listens to. Not that it will break anything
if it doesn't, but if it do, then everything will be so much more tight
and solid. That is to say that the client(s) need not to bother about
time, except for beeing aware that time might not be 100% linear.