Yes, that is a good example, but it requires a lot more than just recording CO changes. How will Mixxx know how a random CO change compares to its internal state. Which state (Deck or Sampler state) changed state will trigger which CO state.
How will the interface look like, to recode and recall such macros? Maybe some of similar tasks are requiring conditions similar to the break effect added in some controller scripts. A hand full more of these examples will be quite useful. Am 06.03.2016 um 22:50 schrieb Ferran Pujol Camins: > For example, a user could record himself setting a 4 bar loop and > successively halving it, a good known Dj trick. Then at the press of a > button this trick would automatically happen (macros will be time-scaled > to match different bpm). This is actually a requested feature: > https://bugs.launchpad.net/mixxx/+bug/1084352 > > Aren't this kind of possibilities not appealing to you? Or I don't get > what you mean in your last sentence. > > Kind regards, Ferran. > > 2016-03-06 22:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org > <mailto:dasch...@mixxx.org>>: > > 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> > <mailto: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> > <mailto: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> > <mailto: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> > <mailto: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>> > <mailto: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
