"Siloed" Beat/Bassline Editor Proposal

[tresf]

This enhancement is a recommendation to isolate instrument groups on separate Beat/Bassline Editor tracks.

The Good The philosophy behind the Beat/Bassline Editor is great as it allows the grouping of related instrument patterns into a single Song-Editor pattern.

This allows a pattern like this in BB Editor:

To shrink to a size like this in the Song Editor:

How its used This "grouping" is so fantastic that some composers choose to make their entire composition out of Beat/Basslines due the ease of fast pattern rearranging (example provided):

The problem this creates The problem with this approach is that as the number of BB Editor tracks grow the Editor becomes more difficult to use. This is because of the many instrument tracks in the BB Editor, only a handful of them -- at one given time -- are actually used. This causes the "overflow" scenario seen here:

Melody tracks overflow the BB Editor

When the overflow is large enough, each time a BB Editor is opened, it's becomes necessary to scroll to the very bottom to adjust or change a pattern.

Worse: How Newbies Fix This For newcomers, the natural instinct to fix this to "clean up" the unused tracks to help isolate the melodies from the beats:

Remove unused instruments to clean up this BB Editor...

!? But we know this doesn't yield the results that are expected:

BB Editor with the wrong instruments removed:

Proposal This proposal is to allow the list of instruments to be stored specific to a Beat/Bassline.

"Clone This Track" would still clone the instruments used in the copied Beat/Bassline:

Clone Track functionality (remain the same)

However new BB Editors would be a clean slate:

New BB Editor functionality (proposed "clean slate")

A mockup allowing the instruments among otherwise unrelated tracks to have completely different instrument collections

Proposed "Siloed" BB Editor

This isn't meant to be solely a proposal to help confused newcomers, but rather its a proposal to allow the existing BB Editor functionality to scale to the more complicated and advanced BB Editor use cases.

[lazerblade]

So, I'll be running an instance of the same VST for every pattern that uses it? That seems to needlessly create a huge jump in CPU usage, which is a very important thing to avoid for audio software.

We would need to instead have some kind a pattern specific list of visible instruments or something else, which would take quite the brainstorm to design effectively and would probably be a challenge to implement. I'm not totally against the idea of some way to group particular instruments to particular patterns, but your current design does not seem feasible to me.

[tresf]

So, I'll be running an instance of the same VST for every pattern that uses it?

Please see proposal #454, which would introduce pattern variations withing a single track.

-Tres

[rawthought]

I'm not sure to understand well but maybe a simple switch button for hiding/unhiding empty instruments should do part of the thing, and will be far more simple to code...

[diizy]

Well, this is going to be horribly inconvenient for anyone who DOESN'T use the bb-editor in this "build your songs entirely out of bb-patterns" way. Anyone who uses bb-tracks in the traditional way - to build beats and basslines (imagine that! where do they get that idea.. ;) ) is going to get hugely frustrated: you create your first bb-track, add bassdrums, snares, hats, cymbals... create the main beat - then add a new bb-track to add percussion - but wtf, it's empty? What now... add all the same instruments again? Waste memory by duplicating the same instruments 12 times?

And no, cloning the track already has a functionality - it clones the track. We shouldn't overload it with other purposes... that's not good UI design, it's not intuitive that you have to "clone" the bassdrum track in order to create percussions (if you already happen to have the percussion instruments there)...

Then there's the technical considerations: like I mentioned about memory? This would cause a huge explosion of memory usage, because you'd have to duplicate the same instruments on different tracks. And what if you create something like a drumfill, you clone it 3 times to create variations, but then you want to edit the drum instrument... but now you have 3 copies of the instrument, you have to edit them all? Not very ergonomic...

So yeah, this has too many problems that I can see right now. There has, however, been discussion of a feature that will show/hide unused tracks in the bb-editor. I think this would be a better solution for now, it solves the problem of "omg too many tracks" while keeping the idea and concept of the bb-editor intact.

For the longer run, I think rather than modify the bb-tracks (which IMO are fine in what they do), we should introduce something like "group tracks" that allow grouping several tracks into one. But that's another story, for another time...

[musikBear]

agrees with diizy. the overhead of duplicate instrument is bad. Both show/hide and group, would be good added functionality.

[tresf]

this is going to be horribly inconvenient for anyone who DOESN'T use the bb-editor in this "build your songs entirely out of bb-patterns"

It becomes more consistent with how the Song Editor behaves for Piano Roll segments. Whether not this is convenient depends highly on each person's composition process.

On a personal note, this is not how I use the BB Editor, and the example was made as a purely hypothetical, as LSP has shown me this is a common approach among our LSP contributors.

you'd have to duplicate the same instruments on different tracks. And what if you create something like a drumfill, you clone it 3 times to create variations

This is why proposal #454 was created to mitigate this.

There has however, been discussion of a feature that will show/hide unused tracks in the bb-editor. I think this would be a better solution for now

Certainly simpler, which helps the implementation of it.

but now you have 3 copies of the instrument, you have to edit them all?

Perhaps. Perhaps not if #454 were implemented first. There's a chance the user would unknowingly choose to clone, but that's an existing problem with cloning anything. Once something is cloned the user is left with two separate working copies. The question would be would the variations generally help or hurt the average composer.

On a personal note, I don't know the answer to this and I'm not here to advocate for the change, rather sketch up and offer the idea. I'm in general agreement that if this functionality were implemented as to internally show/hide it would reduce the memory footprint yet still solve the problems outlined above. I don't particularly use BB Editor a lot, so show/hide wasn't a consideration I made writing the original request but I'd happy edit it to reflect that idea if that becomes the general consensus as the rest of the screenshots and proposal wouldn't really change, except the addition of a show/hide screen.

[Sti2nd]

Like before I am only up for the button "hide unused tracks".

[vlad0337187]

My proposal for this is just to add "alert" window before removing track short description what would happen.

Here I wrote my proposal how to solve problems with that extra patterns take extra space: https://github.com/LMMS/lmms/issues/454#issuecomment-348445277 And there I referenced to my proposal of instrument grouping: https://github.com/LMMS/lmms/issues/3025