Hi Ferran That sound interesting but I do not get the use case.
What will be possible with such an algorithm what we cannot do yet? What kind of users will benefit from it. A related real world issue is for example this: https://bugs.launchpad.net/mixxx/+bug/1157570 Will your solution solve it? Kind regards, Daniel Am 05.03.2016 um 17:26 schrieb Ferran Pujol Camins: > 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 > <mailto: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
