Yes, the raw recorded data is a linear representation. The idea is to reduce the number of data points by interpolating the data with cubic curves, sort of a simplification of the data (as seen in the drawing of my previous mail).
Do you feel macro recording only appeals to a minority of users? I think it's pretty impressive. And as I already explained, other cool features (like your auto-dj sequencer) can be built from it. This interpolation thing is only a part of what needs to be done, but I really feel it is needed if we want our users to edit recorded sequences. I appreciate your feedback! 2016-03-06 20:05 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>: > Ah yes macro recording will be a cool feature. > I habe not yet understood how you will be able to record a becubic curve. > The result will be always a linear representation from audio callback to > audio callback. > It may send to have a abstract editor that converts a cubic curve to a row > of linear changes quantisiced by the size of the audio buffer. > > I actually thought about that > https://blueprints.launchpad.net/mixxx/+spec/midi-auto-dj > > How do you think about that? Storing the command in a midi file has the > advantage that we are able to record the original input, including the > original timestamps. > > The midi decoding is already in place so we have it for free an only need > to implement q midi player that is treated as a controller. > > If I look too a possible gsoc project. It might be difficult since it > probably matters only a minority to our users. > To have a chance for a successful proposal, you have to make sure that you > issue also problems that matters a majority of our users. > Am 06.03.2016 2:45 nachm. schrieb "Ferran Pujol Camins" < > ferranpujolcam...@gmail.com>: > >> Macro recording is a cool feature by itself: you record some cool routine >> and you can reproduce it with the click of a button. But it also serves as >> the foundation of other demanded features like Session action recording >> <https://bugs.launchpad.net/mixxx/+bug/669009>, on-the-fly macros >> <https://blueprints.launchpad.net/mixxx/+spec/deferred-button-execution> >> or cool custom auto-dj transitions. >> >> It is desirable to be able to edit a macro, something similar to what you >> would do in a daw. Problem: editing a curve represented by lots of short >> linear segments is not easy. Interpolating with cubic splines, the curve is >> represented in a more convenient way for editing: >> >> >> >> This might also be more memory efficient, but I think this wouldn't be a >> big problem anyway. >> >> The interpolation algorithm is just an auxiliary feature for the main >> feature of my proposal, which is macro recording. The interpolation >> algorithm will not improve Mixxx in any way that is not macro recording >> (although the algorithm will be properly isolated from the macro recording >> code, so we can further think if other Mixxx features can benefit from it, >> but this is out-of scope of my proposal). >> >> The algorithm I'm drafting is not real time, so it won't immediately >> solve it. >> You'll get the full proposal soon :) >> >> 2016-03-05 23:39 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>: >> >>> 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
