at slow speeds, "keylock" should fall back to vinyl emu scaling

Bug #749396 reported by Owen Williams
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Wishlist
Owen Williams
1.11
Confirmed
Wishlist
Owen Williams

Bug Description

Pitch-independent scaling really falls apart at slow speeds, making cueing nearly impossible. I've heard there are specific bugs in Mixxx with regard to slow-speeds and keylock, but I don't think it's possible for PITS to work well enough to, say, scratch back and forth over a kick to find the down beat. It would be a nice touch if, at very slow speeds , keylock would temporarily disable itself and fall back on vinyl pitch mode to make cueing easier. Then once playback starts and the rate goes up, keylock would reengage itself. There probably would not be a smooth transition between the two scaling methods, but the idea is just to make cueing usable.

RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: New → Confirmed
importance: Undecided → Wishlist
tags: added: keylock soundtouch
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Waveform scratching in 1.10 really brings out the worst in this bug. Keylock sounds horrible here. I've changed it so if you are scratching (via the scratch_position CO -- so waveform/spinny only for now) then keylock is disabled until you stop scratching.

Is this something you think should be applied to vinyl control too?

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Also, my main problem with speed-based switching is how to determine what speed to switch and whether it will be confusing that their keylock starts sounding crappier and crappier and then suddenly switches to chipmunk mode.

Changed in mixxx:
milestone: none → 1.10.0
assignee: nobody → RJ Ryan (rryan)
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

I guess being able to tell when vinylcontrol is scratching vs. not is tricky.

I think that the main problem with ST sounding so crappy while scratching is that it is not meant to deal with rapidly changing rates.

The other issue is that keylock sound quality degrades severely once you get outside the +/- 10%ish range.

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

This problem is present on all time-stretching devices (CDJs with Master Tempo, key lock turntables, etc.) My vote is to not try to guess what the DJ is trying to do and just let them turn it on and off as they require. (I.e. leave it as it is.) That also future-proofs it if we ever add a better algorithm with a larger useable range.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 749396] Re: at slow speeds, "keylock" should fall back to vinyl emu scaling

The main problem (I believe) is that SoundTouch is just not meant to handle
rapidly changing rates. CDJs with master tempo, etc. generally don't
degrade into unusable audio quality when you scratch with keylock on. I
think if keylock worked at slow speeds or with rapidly changing rates then
we could leave it on and let the DJ decide, but as is the audio just
becomes a stuttering mess when you turn it on, which makes features that
cause that response unusable with keylock on.

On Mon, Oct 31, 2011 at 7:54 AM, Sean M. Pappalardo <
<email address hidden>> wrote:

> This problem is present on all time-stretching devices (CDJs with Master
> Tempo, key lock turntables, etc.) My vote is to not try to guess what
> the DJ is trying to do and just let them turn it on and off as they
> require. (I.e. leave it as it is.) That also future-proofs it if we ever
> add a better algorithm with a larger useable range.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/749396
>
> Title:
> at slow speeds, "keylock" should fall back to vinyl emu scaling
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/749396/+subscriptions
>

Revision history for this message
Owen Williams (ywwg) wrote :

Yes, detecting scratching would probably be too hard. One option would be to kick in pitch shifting at -10% speed but keep the key locked to where it was at -10%. This should be possible to do in soundtouch. This would avoid a massive pitch-shift as we cross the threshold.

@Sean, the problem is leaving it as-is is that with keylock enabled the waveform gets crazy out-of-sync with the music really quickly when scratching. It's not just difficult, it's impossible to use.

For the purposes of 1.10.0, I'd say just fix the problems with keylock getting out of sync with the waveform (that's a separate bug https://bugs.launchpad.net/mixxx/+bug/738468). A change in behavior would be a new feature better suited for the next release.

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Has anyone tried Phil's rubberband branch? Does that do any better at slower speeds?

Revision history for this message
Owen Williams (ywwg) wrote :

Here's an option: I have code in vinyl control to detect when the pitch is "steady," ie it is not changing rapidly. This steady value controls the Play status and waveform stretching. It has a threshold so that it ignores minor wobbles in pitch, but catches larger changes like when the DJ pushes or pulls the vinyl slightly. I could increase the threshold so it ignores all but the biggest changes in pitch, and that could be used to detect when the DJ is scratching.

I'll put together a test patch and see how it behaves.

Revision history for this message
Owen Williams (ywwg) wrote :

Here's my test patch. It works well although there's an audible pop and pitch change when the scaler flips from linear to keylock. At least the sync doesn't get all messed up. I had to create a steadypitch class to keep track of the two values -- one more sensitive for the original vinyl usage, and another much less sensitive for this purpose. (The sensitivity is low enough that doing a turntable motor-off trick, causing the platter to slow down gradually, changes speed at a low enough rate that the engine never decides to switch over to linear. I think this is good.)

I'll try doing a mix this afternoon to make sure it works, but right off the bat it seems to do the trick.

Revision history for this message
RAFFI TEA (raffitea) wrote :

Just comment from my side.
All these key-lock issues have been present from Mixxx 1.8 onwards.
I've been using Mixxx with keylock at all times -- beginning with Mixxx 1.6 -- but I've noticed the sound issues from Mixxx 1.8 onwards where the engine was rewritten for looping and other crazy stuff.

Having used SoundTouch in all previous versions, I suspect it may not be SoundTouch issue. But you guys are the experts for low-level audio. I just wanted to keep track of this information.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Can some other people report on whether Owen's patch worked for them?

I'm a little troubled that it would create a tiny pop when switching between the modes. But maybe that's a lesser evil than the desync issues with keylock on.

Changed in mixxx:
assignee: RJ Ryan (rryan) → Owen Williams (ywwg)
RJ Skerry-Ryan (rryan)
Changed in mixxx:
milestone: 1.10.0 → 1.10.1
RJ Skerry-Ryan (rryan)
Changed in mixxx:
milestone: 1.10.1 → none
Revision history for this message
Owen Williams (ywwg) wrote :

This works and stuff.

Changed in mixxx:
status: Confirmed → Fix Committed
milestone: none → 1.12.0
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.