Horizontal Shift for Audio Clips #141
Conversation
topisani
changed the title
|
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! |
topisani
force-pushed
the
feature/audio-clip-rotate
branch
from
fce0bd6
to
3a6ad4c
Compare
|
alright couple of findings:
very cool indeed! thx for your work on this. a lot of people asked for this. |
topisani
force-pushed
the
feature/audio-clip-rotate
branch
5 times, most recently
from
d53c604
to
a12f7cf
Compare
|
@sichtbeton helped me test this on a 7seg unit. The latest changes fixed some edge cases. I believe this now works as intended.
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. |
topisani
force-pushed
the
feature/audio-clip-rotate
branch
2 times, most recently
from
3378a27
to
c88d4b8
Compare
topisani
changed the title
| int64_t newStartPos = int64_t(sampleHolder.startPos) - getSamplesFromTicks(amount); | ||
| uint64_t sampleLength = ((Sample*)sampleHolder.audioFile)->lengthInSamples; | ||
|
|
||
| if (newStartPos < 0 || newStartPos > sampleLength) { |
There was a problem hiding this comment.
startPos == sampleLength is OK?
There was a problem hiding this comment.
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
topisani
force-pushed
the
feature/audio-clip-rotate
branch
from
46e96ea
to
4273796
Compare
|
Addressed review comments, I have played around with this a bit more, and see no issues |
|
this was probably broken by the 2 big merges recently actually, but other than maybe fixing some style troubles this LGTM |
…alues I don't actually know if the latter is needed, but the sample_marker_editor does it when changing these values, so it seems reasonable to do as well. I also removed the "CANT" message when shiftHorizontally fails, as i felt it to be a bit redundant - usually it fails for trivial reasons, such as start or end reached
topisani
force-pushed
the
feature/audio-clip-rotate
branch
from
4273796
to
479a27b
Compare
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)