Horizontal Shift for Audio Clips

[topisani]

I have always wanted to be able to change the start point of audio clips, like the end can be changed using the red bar. The current "easy" way to do it is: reverse clip, change end, reverse back.

I first looked at implementing a similar green start bar (which would probably be the most intuitive), but i understand why rohan left it out now - it introduces some complexity with being able to scroll left of zero etc. I do have a partial implementation of some of this, and if i can find good, intuitive behavior for it, i might submit that as well.

But for now, i chose to instead implement horizontal shift for audio clips. This is the feature where ▲▼ is held while ◀▶ is turned. It works the same as for instrument clips, except it does not wrap around, only shift along the underlying audio, and it cannot go left of zero (will display a "CAN'T SHIFT PAST START" message)

[sichtbeton]

Wow, very cool! Would this work for loops or leave a gap at the start?

[topisani]

Wow, very cool! Would this work for loops or leave a gap at the start?

Not entirely sure actually, it depends on whether loops are recorded to a single file, or multiple. It will work the exact same way as moving the start point using the waveform editor or the reverse->length->reverse flow

[sichtbeton]

Wow, very cool! Would this work for loops or leave a gap at the start?

Not entirely sure actually, it depends on whether loops are recorded to a single file, or multiple. It will work the exact same way as moving the start point using the waveform editor or the reverse->length->reverse flow

Nice!

[sichtbeton]

alright couple of findings:

• it works! finally we can shift an audio clip
• if the audio ends but the clip itself is longer its silent (as expected)
• would be cool if it wraps around (but you said its complicated)
• if you shift all the way to the left (no audio anymore visible) it crashes
• couldnt tell if it respects the margin feature yet

very cool indeed! thx for your work on this. a lot of people asked for this.

[topisani]

@sichtbeton helped me test this on a 7seg unit. The latest changes fixed some edge cases. I believe this now works as intended.

• Fixed shifting past the end of the sample
• unassigning and reassigning the voice fixed some issues that happened when shifting during playback.
• Fix shift direction so it is consistent with instrument clips
• Fix shifting of automation so it is consistent with audio.

Currently, the automation will be wrapped around like in instrument. I think this behavior is acceptable, as the use case probably is not that important, and it is still consistent, usable behavior. Also, This feature will probably often be used to either trim dead space off the start, in which case the automation will be removed from the end afterwards, or to shift the whole clip to the next loop, in which case keeping the automation in sync might make sense. I am not completely sure how automation is currently handled when an audio clip is reversed and trimmed anyway, but i think this makes at least as much sense as that. Do tell me if you disagree, i can look at implementing another solution, but id prefer not to let this minor UI improvement propagate all the way through the paramManager etc.

[sapphire-arches]

I think style check is going to get mad (see below) but this mostly LGTM. Thanks!

[sapphire-arches]

startPos == sampleLength is OK?

[topisani]

I had the same thought, but the sample marker editor allows it, so i assume it is ok

DelugeFirmware/src/deluge/gui/ui/sample_marker_editor.cpp

Lines 220 to 221 in 9701434

	if (newMarkerPos > waveformBasicNavigator.sample->lengthInSamples)
	newMarkerPos = waveformBasicNavigator.sample->lengthInSamples;

[topisani]

Addressed review comments, I have played around with this a bit more, and see no issues

[sapphire-arches]

this was probably broken by the 2 big merges recently actually, but other than maybe fixing some style troubles this LGTM