Hi
Some additions to position scratch.
As already pointed out "position scratch" is much more difficult then rate
scratch. But if your controller queue does not allow rate scratch, it is
not impossible. I have recently tuned Mouse scratch which is actual a
position scratch, with acceptable results. There was the main problem, that
we don't get the timestamps to calculate when was the mouse on the
propagated position.
Since you have the whole queue under control, it should be possible to
time-stamp the position infos quite exact, so that there is at least one
problem less.
Kind regards,
Daniel
2013/7/10 Daniel Schürmann <dasch...@mixxx.org>
> Hi Petah, Hi Mixxx developers
>
> I have access to an Hercules RMX2 controller which propagates its high
> resolution infos as two midi keys. So one of our future project will be the
> implementation of this.
>
> While a sysex solution will work as well, we should consider how to map
> those non standard high resolution values in a generic way.
>
> The discussion about timing concerns is right. Mixxx is only able to react
> on control messages between the audio callbacks. This timing is set by the
> audio buffer size. On length of an audio buffer is always processes without
> adopting new control messages.
>
> This means for Example with an Audio buffer of 20 ms, that 4 of 5 sysex
> messages will produce nothing but CPU heat. On the other hand with a 1 ms
> Audio buffer, you have unnecessary thread switch overhead, because it is
> only possible to adopt a control command after for cycles.
>
> So it is a good idea for best responsiveness to sync the control queue
> with the audio cycle. This is as well one of our future projects.
>
> An explicit poll for the hottest current values would be fine. This would
> avoid to process ~3.9 ms old values at worst. But RJs concerns are right as
> well, It does not come without costs. So we should check the timing
> carefully.
>
> Remaining todos:
> * Allow high res midi values,
> * Sync the midi thread with the audio callback.
>
> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
>
>
>
> I am also in favor of
>
>
> 2013/7/10 RJ Ryan <rr...@mixxx.org>
>
>> On Wed, Jul 10, 2013 at 2:05 PM, petah <mi...@djpetah.com> wrote:
>>
>>> >Is there a reason to make a request/response setup rather than a
>>> broadcast
>>> >setup? Isn't your processing code constantly reading this data as the CD
>>> >spins?
>>>
>>> Yes, approx every 4 milliseconds. If I were to write a 64-byte SysEx
>>> MIDI message that often it'd likely overwhelm the system.
>>>
>>
>> That's 16000 bytes/sec. Which is really not that much data. MIDI (i.e the
>> wire protocol) has a max of 31.25kbits/s but MIDI over USB usually ignores
>> that limitation. If you find it's an issue, you could just rate limit it on
>> your side.
>>
>>
>>> Since Mixxx doesn't need data that often and can only process it without
>>> glitches up to a certain point, as Owen pointed out, the "pull" model makes
>>> more sense.
>>>
>>
>> Maybe you should allow Mixxx to set the update interval via a sysex
>> message? Currently Mixxx doesn't have a way of telling how loaded it is.
>> The controller processing thread runs at lower priority than the audio
>> processing callback so it really should not matter if the scheduler is
>> working correctly.
>>
>> Adding the wire overhead and latency of a request every time you want
>> data seems silly because the time to the next request is a function of time
>> alone and the request carries no information.
>>
>>
>>> >You could just continuously write messages to Mixxx and then parse
>>> >them in a Mixxx MIDI script.
>>> >
>>> >
>>> >On Wed, Jul 10, 2013 at 1:43 PM, petah <mi...@djpetah.com> wrote:
>>> >
>>> >> I had this idea for a high-resolution MIDI interface and would like to
>>> >> know if it's doable/stupid before implementing it.
>>> >>
>>> >> My (software) device continuously updates a few high-res variables at
>>> high
>>> >> speed, i.e. it's not strictly event-oriented. There are two CDJs,
>>> each has
>>> >> the following variables:
>>> >>
>>> >> - track (unsigned int)
>>> >> - position_ms (unsigned int)
>>> >> - tempo (signed float)
>>> >> - pitch-bend (signed float)
>>> >>
>>> >> to keep it simple let's say each variable takes 32 bits, so that's 64
>>> >> bytes for both decks (and ignore other variables for now).
>>> >>
>>> >> if my software were to construct a MIDI SysEx message with this data
>>> as
>>> >> one binary blob, would a Mixxx javascript driver be able to query
>>> that blob
>>> >> to interface with my device?
>>> >>
>>> >> Since the data is real-time, Mixxx could query it as fast as it
>>> can/wants
>>> >> so there are no timing constraints on my end.
>>> >>
>>> >> thoughts?
>>> >>
>>> >> thx,
>>> >>
>>> >> -- p
>>> >>
>>> >>
>>> >>
>>> ------------------------------------------------------------------------------
>>> >> See everything from the browser to the database with AppDynamics
>>> >> Get end-to-end visibility with application monitoring from AppDynamics
>>> >> Isolate bottlenecks and diagnose root cause in seconds.
>>> >> Start your free trial of AppDynamics Pro today!
>>> >>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> >> _______________________________________________
>>> >> 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
>>> >>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> See everything from the browser to the database with AppDynamics
>>> Get end-to-end visibility with application monitoring from AppDynamics
>>> Isolate bottlenecks and diagnose root cause in seconds.
>>> Start your free trial of AppDynamics Pro today!
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> 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
>>
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
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
