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>: > 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
