Project Beats: add skip controls

[sanchitmalhotra126]

Adds outside of playback skip forward/backwards controls. These advance the playhead forwards or backwards by one measure. Also clicking a measure number or the measures header background will move the playhead to that position outside of playback. To show the current start position, we show the playhead outside of playback in a neutral light color, which switches to the current active yellow when playback starts.

Skip.Controls.Updated.mov

Links

Music Lab Functional Spec

Testing story

Tested locally.

[levadadenys]

LGTM!
Wow, the progress with Music Lab is awesome. Looks like web version of Ableton/FL studio to me (which is awesome 😄) already or at least is getting closer and closer to it

[breville]

Very cool. Some initial UI thoughts:

• I really liked the Run button being the full width of the panel. Could we possible put these buttons in the empty space below the triggers?
• With white backgrounds, these buttons feel more prominent than then Run button. Could we tone them down or consider purple?
• We should disable them when playing, since they don't do anything.
• Would it be worth having a third button which jumps the playhead back to the beginning?
• This exposes the deeper issue that we don't support playing a sample that's not at its beginning. Most noticeably, if you start from one bar into the song, but the song comprises two-bar long samples (which we use a lot), then you don't hear that sound at all. Should we consider updating our audio implementation to support starting a sound from partway through?

[sanchitmalhotra126]

• I really liked the Run button being the full width of the panel. Could we possible put these buttons in the empty space below the triggers?

No strong preference here. I went with the current mockups that have the Run and Skip buttons in one row.

• With white backgrounds, these buttons feel more prominent than then Run button. Could we tone them down or consider purple?

No strong preference here either. Maybe a more neutral grey?

• We should disable them when playing, since they don't do anything.

Good call.

• Would it be worth having a third button which jumps the playhead back to the beginning?

Hmm, yeah that would be helpful. Alternatively, in discussing with @mikeharv another idea could be to have a separate play button that plays from the current location, while "Run" always plays from the beginning?

• This exposes the deeper issue that we don't support playing a sample that's not at its beginning. Most noticeably, if you start from one bar into the song, but the song comprises two-bar long samples (which we use a lot), then you don't hear that sound at all. Should we consider updating our audio implementation to support starting a sound from partway through?

Yep true, though this would be a little trickier to support. I'd defer to @moneppo on how necessary this feels?

[breville]

One other thought: should we parameterize the appearance of this feature? It feels like we might want to introduce it at a later point in a tutorial sequence, when things start to get more complex.

[breville]

Two issues we discussed offline:

• after hitting stop, the highlighted Blockly blocks don't unhighlight.
• for the disabled buttons, we can try making the existing ones opacity: 50%.

[sanchitmalhotra126]

@breville revisiting this PR, addressing the feedback we discussed

• after hitting stop, the highlighted Blockly blocks don't unhighlight.

this should be fixed now!

• for the disabled buttons, we can try making the existing ones opacity: 50%.

Done

One other thought: should we parameterize the appearance of this feature? It feels like we might want to introduce it at a later point in a tutorial sequence, when things start to get more complex.

This feature is now hidden behind a config flag (skip-controls=(enabled|disabled)). I've also gone ahead and put keyboard shortcuts behind a config flag as well (keyboard-shortcuts=(enabled|disabled)). Both will default to disabled if not specified.

[breville]

super nit: we use true and false for other values in the menu. enabled and disabled are definitely nice, but should we be consistent with whichever we choose? One factor might be what works best in the context of levelbuilder parameters.

[sanchitmalhotra126]

Oh good call, I'll make this true/false for consistency.

[breville]

Great feature!