Yes, right. A good solution will also work from the GUI. The idea was just that a midi file has already the capability to store control commands along with timestamps. Since there is a standard, there are already third party apps and libraries we may re-use. The sysex extensions offers the option to add Mixxx specific features.
So it looks like form the techical point of view it looks like it will work. If we find out it does not work or we hav not enough benefits, it is also a good result. ;-) If we compare a possible Mixxx macro recording with lets say Open Office Calc, there is an important difference: The real timing. So IMHO the use cases are not obvious. It is important to define some good common use cases, that we have a good reference we can compare our ideas against. That is probably one of the hardest part of your project idea. Am 06.03.2016 um 20:17 schrieb Ferran Pujol Camins: > 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 <mailto: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 > <mailto: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 <mailto: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 <mailto: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> > <mailto: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
