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

[mixxxbot]

Reported by: Be-ing
Date: 2017-05-20T21:31:34Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1692261
Attachments: Capture.PNG

---

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.

[mixxxbot]

Commented by: ronso0
Date: 2017-05-26T14:48:06Z

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2017-05-26T15:06:06Z

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2017-05-26T15:23:28Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2017-05-27T23:57:15Z

---

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.

[mixxxbot]

Commented by: henrik-seip
Date: 2018-08-15T16:55:41Z
Attachments: Capture.PNG

---

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

[mixxxbot]

Commented by: daschuer
Date: 2018-08-15T20:09:24Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2018-08-15T20:10:48Z

---

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

[mixxxbot]

Commented by: ronso0
Date: 2019-01-19T16:19:40Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2019-01-19T20:25:47Z

---

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

[mixxxbot]

Commented by: ywwg
Date: 2022-02-14T16:05:20Z

---

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?)