Also, I feel we should not think in terms of recording MIDI, but recording CO changes. This way users using the GUI can also record macros.
2016-03-06 20:15 GMT+01:00 Ferran Pujol Camins <ferranpujolcam...@gmail.com> : > 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
