unexpected keylock release behaviour

[mixxxbot]

Reported by: ronso0
Date: 2017-01-03T08:49:08Z
Status: Fix Released
Importance: Wishlist
Launchpad Issue: lp1653631

---

I explain what I'd expect:

• a track is playing with a rate of +5%, original key is locked
• releasing keylock should keep that locked key (original or not), but:
• from now on, any change of rate would change key as well
• use jogwheels to simulate an old, worn out cassette or to add 'accents' to instrumentals, which is fun and -when used rarely- really can spice up a mix!

That's a scenario currently not covered by "Lock current key" or "Lock original key" setting:
Right now, when releasing keylock while rate is above or below original, key jumps to that newly calculated key and thus sounds odd.

Could someone point me to where this lock/unlock is done in source?
I can't say if this SHOULD be covered by current settings or if a third option could handle this.

[mixxxbot]

Commented by: daschuer
Date: 2017-01-03T10:49:47Z

---

The related code is here:
https://github.com/mixxxdj/mixxx/blob/master/src/engine/keycontrol.cpp#L201

[mixxxbot]

Commented by: ronso0
Date: 2017-01-04T16:07:05Z

---

Thank you!

Since I only feel my use case (controller with jogwheels), I need some other opinion on that:
what does a DVS DJ expect? Would it be welcome at all to alter this behaviour or add another option?

[mixxxbot]

Commented by: daschuer
Date: 2017-01-04T20:14:27Z

---

The key lock mode was introduced here:
#415

One argument for the current behavior was that it should be possible to return to the original key without any pain. This is quired to go back to clean sound and save a lot CPU.

An other issue was that the key knob should not turn when enabling and disabling key lock.

Maybe we need an additional control for your mode.

Do you have experiences with other tools or player?

[mixxxbot]

Commented by: ronso0
Date: 2017-01-06T14:23:32Z

---

Okay, I will have a look at the code and the conversation and see if I can do something at all.

One argument for the current behavior was that it should be possible
to return to the original key without any pain. This is quired to go
back to clean sound and save a lot CPU.
I see.

An other issue was that the key knob should not turn when enabling and
disabling key lock.
Okay. So my wish would help since now it jumps when unlocking, wouldn't it?

Maybe we need an additional control for your mode.
I imagine the new feature being a checkbox below "Lock Original Key" and "Lock current key" with a label like this:
"[ ] when unlocking, keep locked key until next rate change"
When changing rate afterwards, formerly locked key would be base for any key change, no jumps.

Do you have experiences with other tools or player?
Nope, none. Just innocent expectations...

[mixxxbot]

Commented by: daschuer
Date: 2017-01-06T16:27:02Z

---

Greate. IMHO your use-case is valid and would be a nice addition as a
separate mode. The only question is how to add it reasonable to the
existing code, an visualise in the GUI.

Am 06.01.2017 3:30 nachm. schrieb "ronso0" <email address hidden>:

Okay, I will have a look at the code and the conversation and see if I
can do something at all.

One argument for the current behavior was that it should be possible
to return to the original key without any pain. This is quired to go
back to clean sound and save a lot CPU.
I see.

An other issue was that the key knob should not turn when enabling and
disabling key lock.
Okay. So my wish would help since now it jumps when unlocking, wouldn't it?

Maybe we need an additional control for your mode.
I imagine the new feature being a checkbox below "Lock Original Key" and
"Lock current key" with a label like this:
"[ ] when unlocking, keep locked key until next rate change"
When changing rate afterwards, formerly locked key would be base for any
key change, no jumps.

Do you have experiences with other tools or player?
Nope, none. Just innocent expectations...

--
You received this bug notification because you are a member of Mixxx
Development Team, which is subscribed to Mixxx.
https://bugs.launchpad.net/bugs/1653631

Title:
unexpected keylock release behaviour

Status in Mixxx:
New

Bug description:
I explain what I'd expect:

• a track is playing with a rate of +5%, original key is locked
• releasing keylock should keep that locked key (original or not), but:
• from now on, any change of rate would change key as well
• use jogwheels to simulate an old, worn out cassette or to add
  'accents' to instrumentals, which is fun and -when used rarely- really can
  spice up a mix!

That's a scenario currently not covered by "Lock current key" or "Lock
original key" setting:
Right now, when releasing keylock while rate is above or below original,
key jumps to that newly calculated key and thus sounds odd.

Could someone point me to where this lock/unlock is done in source?
I can't say if this SHOULD be covered by current settings or if a third
option could handle this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mixxx/+bug/1653631/+subscriptions

[mixxxbot]

Commented by: ronso0
Date: 2017-03-09T23:59:30Z

---

From what I understand so far, it would be enough to add a condition like
if (m_unlockKeyToOriginal->get() == 1)
here:
https://github.com/mixxxdj/mixxx/blob/master/src/engine/keycontrol.cpp#L216

So, that condition, a new CO called i.e. "unlockKeyToOriginal" and associated controls in Preferences dialogue would have to be added, right?

If there's not much more to it I could to that.

[mixxxbot]

Commented by: daschuer
Date: 2017-03-11T22:55:01Z

---

Yes, but I am not entirely sure.
You should give it a try, and test if this is enough.

[mixxxbot]

Commented by: esbrandt
Date: 2017-06-29T08:55:56Z

---

#1222

[mixxxbot]

Issue closed with status Fix Released.