20 Jun
2005
20 Jun
'05
12:02 p.m.
Le 20 juin 05 à 14:33, Benno Senoner a écrit :
Stéphane Letz wrote:
I was only answering to the initial question of wether a MidiShare
like API (where event scan have future timestamps, to be delivered at
their due time to clients by the mean of a scheduler) could be built
on top of the jack Midi API the way it is designed. And the answer is
probably not.
Stephane
Good question....
I would say that one the may problem is that jack MIDI does not
has the concept of time-stamps in the "future" . The Jack MIDI
"events" are received in real-time (similar to what MidiShare does
with the Receive callback concepts) but have also to be delivered
in real-time.
In the absence of any scheduling mechanism, I don't think the
MidiShare API could be re-built on top of the underlying Jack MIDI
buffer transports system.
I did not look at the jack midi API yet but what do you mean with
time-stamps in future ?
timestamped MIDI events relative to the current audio fragment or
in future in general, eg deliver this midi event
in 100000 samples starting from the current position ?
I think it's probably enough that jack provides the former.
eg my audio fragment is 128 frames
note on ch 1, note 60 velocity 100 at frame 20
note on ch 1, note 64 velocity 80 at frame 100
so the timestamp is always between 0 and 127 (fragmentsize).
AFAIK VST does it what way and sequencers are perfectly fine with
that scheme.
I don't believe the future timestamping (with timestamp >
fragmentsize) provides many advantages
since it leads to long queues and poor interactivity.
Eg if I want to modify the midi data in real time the first
approach works better since the latency
of the modifications to the midi data becoming audible will be only
1-2 audio fragments.
I think that the argument of needing a kernel based midi API that
timestamps event is the future because
the user space processes cannot provide decent timing is moot these
days because of the excellent RT performance
of Linux and that often sound generation is internal (eg virtual
midi instruments/samplers) so having
jack that handles midi+audio can provide better timing (sample
accuracy) than the ALSA sequencer and simplifies
the programming of virtual midi synths/samplers. (no RT midi
sensing thread etc).
Look at VST: 2 simple callbacks: processEvents() and process() to
implement sample accurate virtual instruments.
Thought ?
cheers,
Benno