Linked Patternblocks

[BloodyRain2k]

I have been using LMMS for a few days now and I really like it.
That said, my first contact with music making software was way back with Music2000 on PSX.

It's pretty much cheap gaming console LMMS without a single synth and just a ton of kinda LQ samples, but they had to fit all that onto a normal CD and then into the tiny memory of the console so that's understandable.

Anyways, Music2000 had a really nice way of handling it's pattern blocks which was that by default blocks were linked, which also removed it's need for LMMS beat line thingy.
So for example you'd made a simple melody 2 measures long and copied that all over where you wanted that to play.
The difference to LMMS was with that that you could edit any of these blocks and all others would reflect that change because they were essentially linked copys of that one pattern.
That's something I'm missing in LMMS, there is makes independent copies by default and when you change one you have to delete ALL others and copy the changed one over anew : (

So I was thinking about how the linked behaviour could be best added into LMMS, it could in theory also replace the beat editor, but wouldn't have to.
In Music2000 were all blocks colored to reflect whenever or not they were the same pattern.
If you were to make an independent copy of a pattern you'd clone it (which is the same in LMMS) and you'd get a new instance of the pattern that's no longer linked to the others and can be edited without affecting the others, and this one would have a different color to reflect that.
https://thump-images.vice.com/images/2015/04/13/was-music-2000-the-sickest-bit-of-software-ever-body-image-1428929535.png

The first row of blocks has up to 2 notes playing at once, the rows in M2k were actually the PSX's sound channels so only one per channel was doable, and 4 measures long, repeated 3 times.
The 2nd row has up to 3 notes playing at once and is also repeated 3 times but the 4th is a different color, so it's likely a clone that was changed a little.
I think you could name blocks and change the icon, which the game picked by default based on the assigned sample used, or something like that.
(The one per channel limitation also took care of an issue I personally have with LMMS which is the ability to stack notes infinitely on the same spot, but having no indication that that was done until you get to the note and your ears explode because it played a dozen at once simultanously x.x)

In LMMS there's a partial repeat functionality for pattern blocks, but it's limited to the beat line.
When you take a beat block it will repeat the pattern and indicate how long the actual pattern is with notches in the block, that's very nicely done.
So for starters could that be added to normal patterns too because the same stretching functionality does nothing at all there.
The next step would require adding the linked blocks which would be done by copying, which currently pastes a cloned independent copy instead.
Cloning would then need to be added to the context menu and would simply make that block independent.
As for the ability to tell them apart, I'd suggest going for colors too but there are finite amounts until the difference becomes too small, so maybe give them also a small number in a corner so that for example red 4 and red 12 would easily differentiated?

So far so good, but there's now the possibility for a memory leak due to having patterns that are currently not placed anywhere on the board.
M2k handled that by having a list of all patterns currently in memory and how often they were used (I think) with a seperate option to do a clean up which removed all patterns not used anywhere.
That list also allowed to just paste a block which for example was useful to not have to scroll all the way to the beginning of the song just to grab a piece and use it at the end again.
The options for LMMS would either be to do the same, or just auto clean patterns no longer used anywhere. Might do the latter while the UI for the former is being made?

This is obviously no simple task but I'd love to see it being implemented at some point and for the beginning just being discussed about.

[rjamesnw]

I like the linking idea. I never used LMMS before, but the first thing I always check is if there is pattern linking. In FL Studio patterns are linked by default in the song editor, and that works great for most of the song. FL Studio also contains a "make unique" option that creates a new pattern variation from the selected one (unlinks it and creates a new pattern that is a copy). Sometimes the same patterns are repeated in various places of the song (drums and baselines are the most obvious) and it's a major pain to find out you made an error and now it's in 20 places. Most DAWS never get this right, so I never switch.

[ballerburg9005]

I wrote the issue "patterns should be passable by reference #5608" as linked above, and I urge anyone to read it in addition to this issue. Because it expresses quite tangibly and verbosely what the feature really means, what it means to not have it and how it could be expanded on.

While I also agree with this issue, as it describes in essence the same thing, it puts it into a perspective of "this other DAW has it, maybe it could be useful to have". And I believe nothing could be further from the truth than that.

In truth the implications are huge and consequences are game changing or deal breaking. We are not talking about adding some visual effect preview here. This feature is as elemental and essential as being able to copy and paste anything in the editor at all.

And it can be way more useful than that if further developed. It is also very simple in nature and easy to implement. As it has been implemented by any kind of music production software that in part focuses on music composition since over 40 years.

I would be willing to implement it. But I would also like to have assurances that if I make a PR and the code quality is good and all that, that it won't be left to rot for years because no one cares about it. And also that it won't be dumped for negligible reasons (e.g. that it breaks file format backwards compatibility with some 10 year old stuff, or something along those lines).

In other words, before I make the effort, I would like to have confirmation that this feature is the way to go forward, and that it is to be considered as important as I reasoned it to be.

[Spekular]

@ballerburg9005 responding to your post on the PR freeze here to keep that one on topic.

There are good ways and bad ways to write linked clips. The way I see it (and I'm in no way claiming to represent the whole team) the good way would require sweeping changes, and I don't know if it's a good time for that. I would liken the codebase to nature and say that every PR should leave it cleaner than you found it. You say this feature is "easy" and you only need a "brief" chat with any given developer, and with those assumptions in mind you got upset thay no one was willing to respond. In reality I think the feature is tricky and requires in depth discussion so everyone is okay with the implementation we decide on.

Now then, some notes on my thoughts linked clips.

Linking makes sense for MIDI, automation, and sample clips, but not for BB clips. It also makes BB tracks mostly irrelevant (especially in combination with some other features). Ignoring BB tracks for a moment, this means it makes sense to unify the clips as much as possible, so we can extract as much as possible into a shared base. A relatively simple example would be ensuring thay every clip can be resized from both ends. At the moment MIDI clips are the only ones that can't be resized from the right and sample clips are the only ones that can be resized from the left. When linked clips are added, I think all the clips should share a base class that handles the linking behavior (I'm thinking a ClipContent class held by a Clip, for example).

Now obviously, we can't unify the clips like this if BB tracks are around. Therefore, getting rid of BB tracks and adding linked clips should happen relatively closely together (certainly within one release). That means we should strongly consider adding group tracks before linked tracks. We also need an upgrade routine to convert BB tracks to linked clips. We should find a UX that makes it as easy as possible to loop linked tracks like one would with BB tracks.

On the topic of UX, it should be easy to link clips (including those that don't currently share identical patterns), unlink clips, create linked and unlinked copies, and tell which clips are linked.

We also need to ensure that clips can be linked between tracks, which means that the clip content instances can't be stored in the track. Clips that aren't linked, but are identical, should be copy-on-write. Linked clips should be stored effectively and correctly when serializing/deserializing (saving/loading projects), reducing project file size. Considering the fact that we might abandon xml for JSON or another format, it's worth considering how these efforts will affect each other.

Off the top of my head, these are some of the issues I've considered regarding linked clips. As you can see, it's most certainly not a topic I've turned a blind eye to, and I have to imagine the same applies for many of the other devs. The reason you didn't get a response, I would wager, is that this is a huge can of worms to open, and LMMS's development is full of those. I'm of the belief that implementing changes in a well thought out order is vital if we want to whip LMMS into a more maintainable state, and the current reorganization is an easy win to get out of the way first. (Except, of course, that it's evidently not that easy to get done.)

[vlad0337187]

Probably, each new pattern (block with notes in Song Editor) could have unique name (written in top-left corner).
So linked patterns will have same name.

[zynskeywolf]

Recently I started to work on such a thing, although there's not much usable code yet. In my solution the current behavior would be kept as it is, but there would be a new type of clip that doesn't have any data by itself (except for the position, muted state, etc.) but they would use the data from a normal clip that it is linked to. The original clip would remain unchanged but the new copy would be of this new class, which then could have an option to be converted back to a normal clip so it could be edited independently after that. Deleting a clip that has linked copies could show a warning about that as they would become unusable in this case.
This seems to be a reasonable first step because this way old projects would remain compatible but we would already have some level of the new functionality. Then if it turns out good, we could then think further. This is just my idea personally.
I'll have some time now in the summer break so I can probably start implementing this if y'all are ok with it.

[Spekular]

That seems like a very awkward solution to me, and I don't think it'd be much easier than a more proper one.

[zynskeywolf]

I mean yeah, "reasonable first step", definitely not the final goal. Of course we could then move the clip data entirely under the hood and present linked copies only. But because of this feature requiring quite fundamental changes to how clips are currently handled (clips and the bb editor are frighteningly integrated together, which causes problems), I think it would be a good idea to do this in smaller steps.

[allejok96]

I don't think we need to rework Clip from the ground up. De-duplication of SampleClip is already underway. So the linked clip philosophy only makes sense for AutomationClip and MidiClip.

there would be a new type of clip that doesn't have any data by itself

This is btw very similar to how PatternClip works

The original clip would remain unchanged but the new copy would be of this new class

Instead of mixing different classes, turn all clips on a InstrumentTrack into some form of smart pointer and keep the actual midi data somewhere else hidden, even if it's only used by one clip.

which then could have an option to be converted back to a normal clip so it could be edited

"Make unique" or "Unlink" or whatever. We'd have to visualize it or do it in some way that shows the users what clips are connected. I don't know about UI, just interested in the implementation right now.

Deleting a clip that has linked copies could show a warning about that as they would become unusable in this case.

Keep a counter and when all links are deleted, delete the clip data from the heap.

[Spekular]

I don't think we need to rework Clip from the ground up. De-duplication of SampleClip is already underway. So the linked clip philosophy only makes sense for AutomationClip and MidiClip.

There's a difference between sample caching and linked samples though, just like MIDI patterns could be de-duplicated without necessarily linking them. Linked sample clips would let you replace hundreds of copies of a kick with another kick sample in one go, for example.

Instead of mixing different classes, turn all clips on a InstrumentTrack into some form of smart pointer and keep the actual midi data somewhere else hidden, even if it's only used by one clip.

Then do the same for automation and sample clips, then extract the common logic :P