Re: [Mixxx-devel] CO time resolution

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

Re: [Mixxx-devel] CO time resolution

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

Re: [Mixxx-devel] CO time resolution

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

Re: [Mixxx-devel] CO time resolution

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

Re: [Mixxx-devel] CO time resolution

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 : > Yes, the raw recorded data is a linear representation. The idea is to > reduce the number of data points

Re: [Mixxx-devel] CO time resolution

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

Re: [Mixxx-devel] CO time resolution

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 chan

Re: [Mixxx-devel] CO time resolution

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 , on-the-fly macros

Re: [Mixxx-devel] CO time resolution

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?

Re: [Mixxx-devel] CO time resolution

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 d

Re: [Mixxx-devel] CO time resolution

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 su