Thank you for the explanation Daniel. I'm writing my proposal for GSOC. I aim for macro recording. COs taking a finite set of values are not a big deal. But continuous CO are, because if we want to let the user edit the macro, a curve formed by a dense set of linear segments is not practical. I'm drafting an interpolation algorithm that combines sections of linear interpolation with sections of cubic interpolation. I ask this because I want to draft the algorithm in matlab as a proof of concept, so I need to generate data similar to what Mixxx would give. Then if my proposal is accepted, the algorithm would be further fine tuned with real data from Mixxx. The algorithm should also provide some improvement on the size of the data.
2016-03-05 12:12 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>: > do you facing a specific issue? > > Here how it works: > The new value is stored almost immediately in the global atomic double. > A latency and jitter comes in when we look at the threads. > Let's look at the midi wheel to audio sample pass: > The midi values are sampled in a 1 ms (5 ms Linux) cycle. MIDI supports > rates up to 0.32 ms. This means a steady wheel turn of a high speed midi > device results in a buffer of 15 midi messages that are processed at once. > (unfortunately the midi timestamp is ignored) the result is stored into the > COs immediately waiting for the audio thread which consumes the value every > 23 ms (default audio buffer size). If the engine thread is not scheduled > before the midi thread runs again the Co value is overwritten by a new one. > The routing samples are passed through on or two extra threads (depending > on the API implementation. Which introduces another delay of > 23 ms. > > How to improve It: > -sync the midi thread with the engine thread to eliminate the random > jitter. > -Take the midi timestamp into account to calculate the wheel speed And > acceleration. > - Add a filter like we have for mouse scratching that removes the > remaining jitter bits from the calculated values. > > We have currently an other Issue: > Let's say you want to play a track for 10 ms. You press play and pause on > the controller. Now it depends on the schedule moment of the engine thread > if the track is played 23 ms or not. In case play and pause are processed > between a engine callback play is overwritten by pause. IMHO this behaviour > is correct in this case. > If we need follow every Co change the consumer can register a change > callback. In this case every single change (or update if you wish) is > delivered either as a direct callback or queued on the threads qt message > queue. > > Kind regards, Daniel >
------------------------------------------------------------------------------
_______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
