On Sun, 1 Jan 2006 13:18:09 +0100 [EMAIL PROTECTED] wrote: > > in a low latency *live* system, "timing" doesn't really exist outside of > > the current period. there is no concept of "when" that exists beyond the > > end of the current period. > to remove jitter i would delay all events i recive during one period > calculation by one period. so exact timestamping is very vital. > > there are only 2 things a live setup can do with an event received > during calculating the current audio buffer. > 1. play as fast as possible... results in midievents jittering to period > boundaries. > 2. add some fixed delay so that if the events were received in 10 sample > clocks distance they are injected into the system with a 10 sample time > distance.
Of course in my original post i assumed that softsynths use this second scheme (with exactly one period extra delay) otherwise all the hassle with midi thread priorities would be void anyways: "Anyways, one more thing to note is for this to work nicely, the softsynth needs to have an extra midi handling thread that is also running with a priority in the 90s range, so it can timestamp the event properly when it arrives." "The interesting number is the "diff" output as it tells us the difference of the previous midi event timestamp to the current one.The "next" field is the offset into the currently to-be-processed period." Only implicitly so, but let's assume the scheme you mentioned as given from now on. Paul's post was a bit ambiguous though i must admit. Flo -- Palimm Palimm! http://tapas.affenbande.org
