>Now, for the case of a sofstsynth this scenario doesn't fit, because the >synth is not zero latency. This means that a "tight" midi track is >audible with the softsynths output latency.
most softsynths are zero latency. only those that work in the frequency domain tend to have non-zero latency. by this i mean that the synth will generate output for a given time period at the same time as processing any input it receives (which may be nothing at all) for the same time period. >Now, Jack is really an audio server but it could also be used to >communicate the latency of the softsynth to the Audio/Midi Sequencer. I >know there's calls to get the output latency of physical output ports. >But it would be nice to have calls to ask for the physical output >latency of clients [this value can be different for different clients - >maybe with different output devices]. the jack API supports this for every port of every client. its nothing to do with particular classes of ports. it *is* up to the client to set the port latency correctly. >This way, the audio/midi-sequencer could ask jack for a list of clients >and offer this choice to the user who then can select which midi tracks >correspond to which softsynth. The Sequencer could then send the midi >events a tad bit earlier [the output latency of the softsynth]. ardour does exactly this. it delays all tracks by various amounts so that they sync up with the most latent/delayed one. this includes internal delays caused by plugins, and external delays due to signal routing. >What do you think? I have no insight into the implementation details of >jack, so i don't know how possible this scenario is and if it fits with >design decisions. its already done :) --p
