"slip_resync" control

[Craig]

Running Mixxx 2.0.0 (build 1.12 r5772) on Windows 10

Discovered while attempting to create a mapping for the Behringer CMD Studio 4a. (Be-ing on GitHub requested I report this).

In my mapping I was trying to "re-sync" slip playback (i.e. slip was already active) by doing this in a single JS button "call-back" function:

engine.setValue(group, "slip_enabled", 0);
engine.setValue(group, "slip_enabled", 1);

This had no effect. It seems that flipping this parameter, (perhaps all parameters??), in the same function (i.e. without returning to Mixxx first), has no effect, or more likely, only the last call will have an effect? (so that in this case I was just setting slip_enable to 1, and it was already set to 1 before the function was called so had no effect?) I'm guessing here that parameter change processing only happens when a JS function returns to Mixxx??

Since there is no other way to "re-sync" slip-playback I was forced to work-around this problem using a very short on-shot timer like this:

engine.setValue(group, "slip_enabled", 0);
engine.beginTimer(50, function() { engine.setValue(group, "slip_enabled", 1); }, 1);

This works but is incredibly ugly (and I suspect most people who need to do this sort of parameter flipping won't think of this).

I think there are 2 possible solutions to this:

1) The engine.setValue() call be altered so that it does the right thing, (e.g. triggers at least one round of parameter processing when called so that any "reset" behaviour works as expected when flipping param values).

2) A "special case" call/param be added that "re-syncs" slip-playback without needing to flip slip_enable off then on again. (I'm new to Mixxx so don't know how common this problem is, perhaps slip_enable is the only parameter where this is a problem??)

[RJ Skerry-Ryan (rryan)]

The way slip_enabled works is particularly vulnerable to this since you have to enable slip and then the audio processing engine has to run its callback and notice that you changed it. If you change it then immediately change it back, there's a race.

Some major restructuring of our engine has to happen to fix this -- I'm interested in doing it but it's not going to get done anytime soon (it's a really big project).

It's not particularly related to the fact that you do both sets in one callback. Even with your timer workaround there's still a race condition that you set it to 0 and then back to 1 before the engine processes the 0. Basically, you can't use slip_enabled in this way (to "resync" the slip). We would need to add a dedicated control to provide this (your option #2).

[Craig (craigeastonuk)]

Ahh I see!

This probably explains why I had some problems when I tried the timer work-around. Sometimes the re-sync just didn't seem to work. I experimented with different timer-settings and 50 seems to be OK most of the time, (but it still fails occasionally). Any longer and I was concerned that I might create my own race condition with two button presses in quick succession, (although thinking a bit more about this now, I suspect that the user wouldn't notice any ill effects from this so perhaps I should just increase the timer to something like 100 on the basis that 1/10th of a second for a slip "re-sync" delay when you release a button *probably* wouldn't be noticed.)

I agree that the most sensible option to fix this now would probably be to add a dedicated control for this "slip re-sync" function.

Thanks for the info.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8456