CO needed for single deck vinyl control toggle

Bug #813046 reported by William Good
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Wishlist
William Good

Bug Description

In order to use the single deck vinyl control feature, one must be able to move control by a vinyl control signal from one deck to another, quickly and easily. This can be accomplished with MIDI scripting, but as keyboard and GUI control can only be accomplished through mappings to ControlObjects, a ControlObject must exist for a user to (say) map the space bar to "toggle vinyl control to next deck" or a GUI widget to the same functionality.

Tags: control vinyl
Revision history for this message
William Good (bkgood) wrote :

Committed a fix in lp:mixxx/1.10 r2842 and r2843

There's a new ControlPushButton at [VinylControl],Toggle. It does one of a few things (assuming at least one vinyl control input is setup -- if not, nothing's going to happen):
* If vinyl control isn't enabled on any decks, enable it on the first one we're receiving samples for.
* If vinyl control is enabled on a single (exclusive) deck, and another deck is setup to receive samples, disable it on the former deck and enable it on the next eligible deck (ordered by deck number).
* If vinyl control is enabled on multiple decks, don't do anything (as there's no intuitive behaviour I know of here, and is far more likely to just end in disappointment on accidental usage).

Any qualms? I didn't commit a keyboard mapping change, that's for someone else to decide (if we even want to map it to the keyboard, it's only useful to the subset of mixxx users wanting to control multiple decks with one vinyl deck)

Also, Owen, would you mind vetting my changes real quick? I did make a change to VinylControlProxy, VinylControl children require an ::isEnabled method, and VinylControlProxy was just returning some unused data member. I changed it to provide the result of the the proxy's VinylControl object's isEnabled if the object exists, or false otherwise. http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/release-1.10.x/revision/2842?start_revid=2843&remember=2843 (link includes combined changeset for both revisions)

Changed in mixxx:
status: Confirmed → Fix Committed
Revision history for this message
Owen Williams (ywwg) wrote :

Looks good. My only worry is could there be some way that the only enabled proxy gets disabled before the while loop? vinylcontrol has its own thread so hypothetically that value could be set at the wrong time. It doesn't look like it's a problem now, though.

Thanks for implementing this. I also like that it works with n-decks.

Revision history for this message
William Good (bkgood) wrote :

It's possible, but all it'd do is cause (if a 'next' proxy is found) ToggleVinylControl(false) to be called on it again, and then ToggleVinylControl(true) to be called on the 'next' one. The window of opportunity is absolutely tiny though, and it would only really make a difference if something in software automated disabled vinyl control for the deck, because a user activating [ChannelX],vinylcontrol_enabled and [vinylcontrol],toggle within a sufficiently small window might as well be impossible.

One thing that can't happen is a pointer going stale, the lock on m_proxies ensures this (sorry, not sure which 'enabling' you were referencing, as the term fits for both "input is enabled for this deck and a vinyl control proxy exists for it" and "input is being used to control the deck").

Thanks for looking over it!

Revision history for this message
jus (jus) wrote :

+1 for having it mapped to the keyboard.
Whats the opinion from regular vinyl control users, would it not make sense in this context to map the other VC functions (ABS/REL/CONST and HOT/ONE/OFF) too?

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/5952

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.