1 Jan
2006
1 Jan
'06
9:45 a.m.
On Sun, 1 Jan 2006 13:18:09 +0100
torbenh(a)gmx.de 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