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
