1 May
2004
1 May
'04
4:06 a.m.
Hi Tim!
void (*midi_msg)(LADSPA_Handle instance,
unsigned byte msg[4]);
.. is a four byte message.
I should have included some kind of man page:
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.
mvh // Jens M Andreasen
On fre, 2004-04-30 at 18:25, Tim Goetze wrote:
[Jens M Andreasen]
On tor, 2004-04-29 at 16:11, Chris Cannam wrote:
as i understand it, this is not enough. the run_synth() method allows
you to run the synth for a continuous audio block with [MIDI] events
interspersed at arbitrary timestamps, while with midi_msg() you'd
have to split audio blocks to match event timestamps, which is messy
and performance-unfriendly.
tim On Thursday 29 Apr 2004 2:19 pm, Jens M Andreasen
wrote:
Mmm .. This would replace, I think, all of your considerations on how to
extend LADSPA. It is (probably?) the only extension really needed. MIDI
is a very powerful protocol, and the beuty is that the client needs only
to implement those parts it needs to get going. I think I will not be really, totally happy
before I see something
like:
void (*midi_msg)(LADSPA_Handle instance,
unsigned byte msg[4]);
This would be exactly equivalent to the existing run_synth(), would it
not?