Jack MIDI timestamping Was: Re: [linux-audio-dev] What parts of Linux audio simply suck ?

Stéphane Letz wrote: 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