Am 09.01.2016 um 01:39 schrieb Sean M. Pappalardo - D.J. Pegasus:
>
> On 01/08/2016 04:00 PM, Daniel Schürmann wrote:
>> The current algorithm
> Ignore the implementation for now. I only want to discuss design in this
> thread, i.e. How should soft-takeover behave in each case?
I am just wondering if we have actually an issue with the current
implementation, or if the discussion
only starts because of some faulty tests. If it ain't broke, don't fix it.
>> Line 4 is not reached in my scenario since the user moved the slider
>> very quickly.
> I'm confused then. As far as soft-takeover is concerned, it shouldn't
> care how the on-screen control was moved (whether the user did it with a
> mouse or AutoDJ did it,) its evaluation of whether to ignore a new
> hardware value will be the same.
Yes, exactly. We have to scenarios where soft-takeover should take place:
1) The CO was moved by something else than the midi value it is mapped
to. (covered by the current implementation)
2) The hardware control was moved without emitting midi messages, e.g.
after a layer switch or before power up.
(this is done by the new ignore next feature and the topic of the
pending discussion in Bug 1531876)
> Can you re-state your AutoDJ scenario step by step? (You could replace
> the AutoDJ part with just "move the CF with the mouse.") Use the little
> text diagrams for each one and say if it occurs soon (within 50ms) or
> later than the previous. Remember | is the CO value (which AutoDJ or a
> mouse can change) and 'p' and 'n' are hardware values which only the
> user can change on the controller.
OK, I will try:
Line 5:
opposite close far later TRUE ----p|--n--
* Start, controller is in sync: ----p---- (p=|)
* the user moves the hardware slide to a new new position --n-p---- (p=|)
* p is close to (in this case equal), value is not ignored --p------ (p=|)
* a long or short time passed
* user GUI slider is moved by a second source (Mouse, AutoDJ or a second
mapping) the hardware slider remains on p. --p|-----
* a long or short time passed
* The user whants to moved the Mixxx control quickly to right by moving the
hardware slider --p|--n-
* softakovers should snap in when passing | independent from the moving speed
------p- (p=|)
IMHO a good real worlds model is the cable control of an old transistor radio.
The tuning knob pulls a cable. In the cable is melted a tiny plastic ball.
The frequency pointer has a fork on its lower end. If you open the radio, you
can move the pointer freely.
If you close it again, You have to turn the tuning knob until the plastic ball
on the cable passes the
fork of the pointer and snaps in. Before this happens Until you the pointer is
not moved by the tuning knob.
>>> You're right, it does indeed make a tiny jump, but it isn't noticeable
>>> in the audio. This window is needed for controllers that send messages
>>> slowly. Without it, controls lose sync easily (which is very frustrating!)
>> I cannot see this need anymore. Can you describe a step by step scenario
>> how a slow controller looses sync without the jump.
> Sure. On some controllers (I think Hercules RMX is one,) if you move
> sliders at a normal speed, the controller sends position messages that
> arrive more than 50ms apart but differ by 2 or 3 values instead of 1, e.g.:
> B0 10 00
> B0 10 01
> B0 10 02
> B0 10 04
> B0 10 07
> B0 10 09
> B0 10 0C
>
> Without that 3-value "gimmie" window, such a controller would lose sync
> on all but the slowest moves. (At the B0 10 04 step in this example.)
Since it is always P=| it should not happen.
If we use the transistor radio model as above any size jum is possible
without loosing track.
Softtakeover should also snap in at any size jump as it passes the
current value. I can only think of an issue when the controller is not
able to send the very maximum or minimum-
>> If
>> we think of a scenario where EQs are reset on track load, they will get
>> always out of sync if you have tweaked them in the previous track.
>> If you now just want to move the Controller EQ knob as well back to
>> center, the EQs are enabled and due to the opposite direction jump and
>> disabled again. Since enabling and disabling EQs requires come CPU, we
>> should avoid this, if possible.
> That's true, but avoiding it is not possible in light of the above. I'm
> glad you're paying attention to optimizing CPU usage though!
Think to the transistor radio model. I think it can handle it. ;-)
> Sincerely,
> Sean M. Pappalardo
> "D.J. Pegasus"
> Mixxx Developer - Controller Specialist
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>
>
> _______________________________________________
> 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
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
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
