I see, I will reflect that in the proposal and then we can further discuss it.
Thanks for your input :) 2016-03-06 23:24 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>: > 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
