#Add ability to loop clips

1 messages · Page 1 of 1 (latest)

lone patio
#

If allowed to, I would like to try solving this issue : #7907 (Add ability to loop MIDI clips), but it would involve significant changes to the code and the ux, so I want to be sure that I'm going in the right direction before I start doing anything.

Let me explain how I imagine the functionality :
I like the idea proposed by AW1534 in the issue description:
Personally, I like the way GarageBand (and presumably Logic Pro) handles this. It has a dual handle design, in which dragging from the top right of the clip initiates a loop, while dragging from the bottom right initiate a resize.
A loop would be a clip of any length, whose start position is the end position of the original. The content of the loop would be the content of the original repeated as many times as needed. Any change made to the original clip would impact its loop.
Midi clips (and maybe sample and automation clips) created in the song editor would be loopable, but not those created in the B+B editor.

  • Moving the loop would move the original and vice versa.
  • Double click would open the original clip in the piano roll (or automation editor or whatever...).
  • Using the knife tool on a loop would create a copy of the original clip on the right side of the cursor, as well as its own loop of the right length.
  • Deleting the loop would only remove the loop, deleting the original clip would also remove the loop.
  • The loop could be independently resized with its right grip,
  • If the original clip is resized, the length of the loop would be updated so the end of the loop stays at the same position.
craggy parrotBOT
lone patio
#

And how I would implement it :

  • The new class ClipLoop would inherit from Clip, and be extended by MidiClipLoop (and maybe AutomationClipLoop and SampleClipLoop). It would have as attribute a reference to a Clip object (the looped clip), and would encapsulate the public methods of that clip.
  • Clip would have a new Clip* attribute pointing toward its loop or equal to nullptr if no loop exists. It would also gain two virtual methods loopable() and isLoop().
  • Track classes would handle clip loops as standard clips
  • ClipView would do the same but taking advantage of isLoop() to allow visual differences
    I am not sure any of this is a good idea. The main flaw I see is the need to a lot of unsafe casts, and the fact that modifications made to Clip could easily break ClipLoop without the author being aware of it.

imo, such a functionality would be a great qol improvement.
I hope to get your green-lights, thanks for your time and attention 😉

long estuary
#

I don't like the idea of introducing a new clip type. You can attach any number of views to a model, why not take advantage of this?

#

So essentially I would implement this feature using instances, not by having a new type of clip.

#

I don't know what others think, I've made #8221 that introduces a grid, and song editor is a grid, so maybe if your idea requires a big refactor, it could also use 8221 grid model

craggy parrotBOT
long estuary
#

It is unreasonable now, but if Instances were to be implemented, a storage layer I called "Store clip view instances in tracks" would have to be introduced, and at that point 8221 could handle that layer

novel moat
#

Here is how I would implement this:

Or reimplement 'bump-to-disk' and then expand the length of clips that AFP can handle, and simply loop AFP with the bumped segment for as long as any note inserted. No UI changes, and no significant general changes in architecture. It would almost not change anything at all

long estuary
lone patio
novel moat
# long estuary They would like to loop automation too

They would like to loop automation too
I was just writing this... Independent of what is in AFP..? Not sure i understand, -when i realised that LMMS can do this already!
The only 'thing' would be length of segment that AFP can handle,but otherwise making loops inside LMMS is already possible.
This is how:

  • Mute all instruments of the project.
  • Enabled only those that should be in the loop,and the Automations that these track have.
  • Open export dialog
  • select
    (Image)
  • Insert an AFP and point to the exported segment
  • In the AFP track draw a A4 note for as long as the loop should play
  • Set AFP UI as
    (image)

Now the enabled tracks that was exported to disk can be deleted. They are all inside the exported soundfile.
The AFP will play the loop for as long as the A4 note was drawn, and that segment can ofcause be duplicated if the loop returns later in the song.
That makes LMMS use loops already

#

Stupid Discord dont show images
This is AFP settings

image.png
#

This is Export-dialog:

image.png
novel moat
daring monolith
#

I know very little about coding but i just wanna say this is a great feature i cant wait

long estuary
real surge
#

I could imagine storing the loop start/end positions relative to the internal clip content within Clip, and then modifying the code for playing tracks and drawing the ClipViews to essentially treat the rest of the clip bounds as repeating copies of the region in the loop.

long estuary
lone patio
#

I gave up on my original idea, and have started tying a simpler one :

  • ClipViews can now be created with an offset, this allow to have several views for a single clip.
  • Clips start/end positions would not change, but there would be an attribute keeping track of the number of times the clip is looped.
    I'm not sure yet how to modify getClipsInRange() of Track to account for loops
hollow pike
long estuary
# lone patio I gave up on my original idea, and have started tying a simpler one : - `ClipVie...

You need 2 kinds of data:

  • position data
  • clip data

What you are doing is this:

  • position data clip data pair with additional position data for the offsets

Maybe this is a reasonable solution that balances ease of implementation and maintainability.
I would recommend having the "position data" and "clip data" in separate objects from a maintainability standpoint. "position data" would be the new clip model and "clip data" would store the data from the old clip model that isn't position. "position data" would store a pointer to "clip data".

How clips work in song editor is okay, so maybe 8221 shouldn't be introduced, but if this isn't the case, then 8221 would benefit from "clip data" and "position data" separation

novel moat
lone patio
novel moat
#

the loop is not edited with the clip, which is imo the main interest
Well explained! Yes that would need a new export, and a remake of loops in my model.
👍