Collapsible Song Editor Groups

[StakeoutPunch]

I think it would be awesome if there was a way to create groups of tracks in the song editor. Let's say I have an instrument with 5 separate automation tracks. I set the instrument as the parent and the 5 automation tracks as children, now I can toggle the children's visibility using the instrument. I suppose the group options would be included under the gear icon where the existing track options go.

Maybe more specifically, tracks can have one of two group states: Parent or child. By default all tracks are parents. When a track is set as a child it associates with the closest parent track above it. Parent tracks (or children tracks) would be styled differently to denote the difference. Possibly another feature (yet assuredly more complicated) would be for the parent track to mute all its children when it is muted.

I think this addition would be useful for hiding tracks that aren't being worked with to provide a more organized work space and to reduce the amount of scrolling in huge projects. I got the idea from working in Photoshop, this idea is kind of similar to how layers can be grouped.

[diizy]

I agree completely and support this suggestion 100%.

[musikBear]

yes! 👍
The feature is also in ableton, but they also uses it in piano-roll, in a somewhat ingenious way :
As the user compose, he can actually choose to 'collapse' the piano-roll, so not used notes, simply is hidden! I have thought about this, and it definately has pros -big ones. The con is only if the user collapse before 'best-notes' are found. But if ghost-tracks #696, are implemented, then a collapseable piano is a over complicated feature

[StakeoutPunch]

I just want the actual tracks in the song editor to be able to collapse, regardless of their type. I'm not entirely sure what you are suggesting @musikBear, but collapsed tracks would not be permanent but rather a toggle so users can quickly hide or show a parent's children tracks. This function would also only be in the song editor so what about the piano roll? The only way I'd see collapsing a piano roll usefule is if you wanted to collapse notes that aren't in the current scale being used.

I'd say let's stick to having parent and children tracks in the song editor first, then maybe add funtionality to the piano roll if it's deemed logical and useful.

[StakeoutPunch]

Is this just totally dead? D:

[Sti2nd]

Everyone loves it, I guess? Right now there is a desperate need for it, IMO! And in the future these future enhancements is more acceptable with grouping: Unremovable tempo track, unremovable (?) notation track, convert to sample track -option (alternative to freeze function).

[StakeoutPunch]

Making tracks that can't be removed is a bad idea...

And let's slow down and just focus on getting parent/child grouping first ha

[diizy]

On 05/27/2014 06:24 AM, StakeoutPunch wrote:

Making tracks that can't be removed is a bad idea...

In general yes but in this case no. If you read the mailing list, the
reasons why this is sorely needed are explained there. Show/hide track
will be available so unremovability is not an issue.

[diizy]

The above referring to the tempo track, I mean. Comment tracks were never meant to be unremovable.

As far as track groups go... while I fully support the idea, this is definitely not going to make it to 1.1, I can say that much. Even 1.2 is uncertain, because we already have plenty of work queued for that version as well (not to mention people will be on summer vacations...) Unless maybe someone comes along and offers to implement this track grouping for LMMS.

Problem is that it's a moderately complex feature, even if it is mainly a UI thing - it's going to make the song editor's track moving code a lot more complex, when right now we can just make do with "what's the mouse position? is it above us? move track up! is it below us? move track down!"

But, I'm sure this will get done eventually so there's no need to lose hope. Just a healthy dose of patience...

[Sti2nd]

I think this should be high on the priority list, together with MIDI export. I am working on trying to get hold of more devs in addition to a lot of other things 💯

[softrabbit]

One question that pops to my mind is:
Should this grouping be multi-level (tree-like), or would it be enough to have groups that only contain an array of tracks, to put it in programmer-speak?

[diizy]

On 05/27/2014 06:32 PM, Raine M. Ekman wrote:

One question that pops to my mind is:
Should this grouping be multi-level (tree-like), or would it be enough
to have groups that only contain an array of tracks, to put it in
programmer-speak?

I don't see the point of making it tree-like... should be enough to just
make it as single-level grouping. Simpler too.

[StakeoutPunch]

I believe that it would only need to be parent/child, more layers would just be over the top and probably confusing to most average users.

Would it be fair to add this to 1.3?

As for the moving code, wouldn't it stay relatively unchanged? I'd suggest that parent tracks don't move their children.

[diizy]

On 05/28/2014 12:13 AM, StakeoutPunch wrote:

I believe that it would only need to be parent/child, more layers
would just be over the top and probably confusing to most average users.

Would it be fair to add this to 1.3?

It's fair to "add" this whenever, just it won't be included in 1.1 since
we're past feature freeze for that version. If someone implements this
before the feature freeze of 1.2, it can get in 1.2. Otherwise it's
always postponed for the next point release.

As for the moving code, wouldn't it stay relatively unchanged? I'd
suggest that parent tracks don't move their children.

Parents/groups (depending on how it's decided this should be
implemented, which should be discussed more) probably would have to move
their children, otherwise the song editor layout gets easily just too
confusing. Think of directories in a file browser, or group layers in a
graphics editor. It's very confusing if they're not represented
coherently visually.

This means that children of a group need to be directly below the
group/parent when the group is expanded, and hidden when it's collapsed.
And this means that it makes it more complex to determine a track's
position in the song editor stack, because we have to take groups in
account. Right now we can just take the y position of mouse and look at
which track it falls on, by adding together the heights of the tracks.
If we have groups, we have to take in account the state of each group
(collapsed/expanded), know the state of its children and the track
heights of its children, and then add them up so that we know our
position. So it does need some changes and added complexity.

[StakeoutPunch]

Oh, I see what you mean about having to rewrite stuff for this to work.

What I was going on about earlier was that when tracks are set as children they could look for the nearest parent track above them, and if that parent is moved they simply change to the next nearest parent. I just assumed this way would be easier to implement, while still providing basic functionality. Now that you've pointed out just how much would have to be changed to even begin including this, I can see why going all out would be a better use of time.

[HDDigitizerMusic]

This would be nice for saving CPU if you could just shut off a whole
section. :D

On Wed, May 28, 2014 at 7:22 PM, StakeoutPunch notifications@github.com
wrote:

Oh, I see what you mean about having to rewrite stuff for this to work.

What I was going on about earlier was that when tracks are set as children
they could look for the nearest parent track above them, and if that parent
is moved they simply change to the next nearest parent. I just assumed this
way would be easier to implement, while still providing basic
functionality. Now that you've pointed out just how much would have to be
changed to even begin including this, I can see why going all out would be
a better use of time.

—
Reply to this email directly or view it on GitHub
#735 (comment).

Digitizer out.