make brake, soft start, and spinback part of the effects system

Bug #1692261 reported by Be
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Mixxx
Confirmed
Wishlist
Unassigned

Bug Description

The controller scripting system provides a way to simulate braking, starting, and spinning back a vinyl turntable. This is an awkward place for such functionality because controllers do not have buttons for it. It would make more sense to provide these as effects.

Revision history for this message
ronso0 (ronso0) wrote :

Most controllers have shift buttons and it's easy to map Shift+Play to Brake, Shift+Cue to SoftStart.
Even though I agree it would be cool to make those features accessible to mouse users, I don't feel they should be in effect units because they are basically transport controls.
On the other hand, in effect units one could adjust the parameters.

Could they be longpress actions of Play button, depending on the play state, like it works with beatloop/beatlooproll?
Parameters would be in Preferences then. I use brake quite often and once adjusted, I never felt the urge to alter the parameters.

Revision history for this message
Be (be.ing) wrote :

Long pressing the cue button already has its own behaviors with cue_default. IMO shift + cue is better used for jumping to the beginning of the track and stopping (start_stop Control), and this is how I've designed the CueButton in Components. But long pressing the play button is an option. This could be implemented in the Components PlayButton pretty easily.

Revision history for this message
Be (be.ing) wrote :

On second thought, long pressing the play button would not work, because we cannot introduce a delay to determine whether to toggle the play Control or do the soft start/brake. With the play Control toggled immediately on press, soft start/braking would then be really awkward.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

The right click play has different features across the skins.
I have never actually used it. So it is a good candidate for soft start and stop.
I would be relay happy to have this accessible from the skins.

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Henrik Tronslin Seip (henrik-seip) wrote :

Why cant it be done like it is done in serato?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

We can do it like this. It would be an improvement over the current state.
We just need a contributor, who had interests and time to implement it. A conditional soft start and brake however would be reasonable though.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Can the user enable/disable it on the fly in serato?

Revision history for this message
ronso0 (ronso0) wrote :

Yes we could make this an effect, but I actually wouldn't sacrifice one or even two effect slots for this feature.

IMO it would be better to have those functions available
1) as separate effects: a) brake/softStart b) spinBack
2) as optional GUI buttons with parameters set in Prefs:
  a) brake/softStart* b) spinBack
3) for controllers so that users can map it individually

*can share one effect/button as only one or the other can be active

> IMO shift + cue is better used for jumping to the beginning of the track
> and stopping (start_stop Control), and this is how I've designed the
> CueButton in Components.

Can users override this default behaviour without having to mess with components itself? IMO that should be possible as components more complex that a midi mapping, and it affects all mappings that rely on components.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Yes, a hard coded engine solution sounds reasonable.
This is the inner play function:
CueControl::updateIndicatorsAndModifyPlay()
this is the speed function:
RateControl::calculateSpeed()

I think it can be done similar to rate_temp_down/up except that it starts and stops at zero
RateControl::processTempRate() is the function

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

Braking is pretty easy, but ramping up pressing play will be very hard for our quantize code to handle. Do we just do a seek at the end of the ramp period to resolve sync issues? Or do we try to calculate the acceleration so that it arrives at the correct sync point?

(Which controller has the best implementation of this feature?)

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

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

Bug attachments

Remote bug watches

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