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 [email protected]
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.

[Sti2nd]

Well, editing the group as a whole could be functions added... later

[curlymorphic]

Going to have a look at this, but before I start I have a few questions. It would be nice to have some specs to work to. even if they do have to be re evaluated.

How are we going to visually differentiate between child and parent, icon, color, border, font?

is this all to be done from the gear icon ( parenting, unparenting, collapsing, expanding )?

is it fair to assume, when you parent a track, it uses the next above parent track?

when parent track moves, all child track follow?

you cant move a non child track inbetween children, skips to above next parent?

can't move a child out of it;s parent group?

children can be moved within the group?

cant delete parent track while it has children?

How do we represent that a track has hidden children, maybe reduce hidden height to 1px, so can still see when the child objects are?

parent can unchild all children in 1 go?

child tracks can join leave on there own?

A Track with children, can not itself become a child track?

Parenting and visibility are to be saved?

What happens with solo, mute, unsolo, unmute behaviour on both parent and child tracks?

All track types can be parents bb,automation,sampler, instrument?

All track types can be children?

Im not responsible for artists logic, if a bass synth is parent to the automation of the cutoff of the hats how do i know thats thats genius or not?

From a logic pov, it's the TrackView's that are being grouped?

sorry for all the questions ( there may be more ), I have worded them using the assumptions I would have made. but would rather have input now while im at the planning stage.

[tresf]

You may want to target 2.0 for this... I sounds like quite a design change which requires more prototyping than most enhancements and that version/branch may be a good candidate for it.

[tresf]

Also, the OP seems to focus mostly on Automation tracks, which can quickly start to take up a lot of space... perhaps the concept of nesting those (under a parent track) could segway into this concept a bit...

[Sti2nd]

nesting those - @tresf

I wouldn't like to group my automation tracks together... but it is a temporarily solution :)

[Sti2nd]

How are we going to visually differentiate between child and parent, icon, color, border, font?

@diizy Is probably the one who tell you that. I am picturing the parent like a Beat/Bassline track where the icon is a folder, and maybe you could colorize the children in the same colour? This is the among the most important to figure out now, indention won't work, right?

is it fair to assume, when you parent a track, it uses the next above parent track?

Well, if you are going to have a context menu for it, why not list up the available track folders you can put it in? Yes, I would say it is fair to assume that. Could probably implement a drag and drop on top of folder with shortcut keys later.

As I said I am thinking of this very similar to a folder which can be expanded to show its content, so you can probably understand what my thoughts are on many of your assumptions/questions :)

Many of your assumptions/questions are thinking a lot further that I feel you need to go, I think a simple implementation is the first thing to achieve, really cool that you have been thinking about this 👍

[Spekular]

Well theres a big difference between parent/child style and folder style track groups,
so we need to decide on that. For BB patterns I can see making alt versions
the child of the base, but in other cases/in general I feel a folder
style is more flexible. It might look really odd, but what if we squished
all the tracks in a group into the vertical space of the groups (same as a
regular track I'm thinking). Mockups on the way.

Mockup 1 (Closed Group):

It doesn't scale very well (Ba Dum Tss) for more than maybe 4 or 5 tracks visible, but with the text the user will still know how many are contained. Also, I feel that folders without multiple levels lose a lot of the point and their usefulness, so if it's possible to create groups within groups that would be ideal. A maximum number of folder levels (oh no magic numbers!) would be fine with me though. That way we could actually do things like indentation, with an extra 25 px wide track labels and 5px text indent per level or so.

[Spekular]

Here's an idea for an open group where the group track disappears and only the children are visible. Clicking the (ugly mocked up) label would close it.

[Spekular]

Here's a much better idea and a much better mockup for open track groups (ignoring the extra space on the "child tracks"):

[curlymorphic]

Im liking the indentation, very clean.

Well theres a big difference between bparent and folder style track groups,
so we need to decide on that

Yep, that is one of the fundamentals

squished all the tracks in a group into the vertical space of the groups

This sounds cool,

[Reaper10]

will the group track in B&B editor?

[tresf]

will the group track in B&B editor?

What?

[Reaper10]

will the group track be in B&B editor? ...... sorry

[Sti2nd]

Maybe, but probably first coming to Song Editor

[Reaper10]

Will a user be able to use a Group track inside of another Group track ie a sublayer in a layer?

[tresf]

@Reaper10 probably not, at least not at first, but this feature is hypothetical, so no one can answer that question for certain.

[StakeoutPunch]

This issue is about grouping tracks in the song editor and does not apply to the mixer in any way shape or form.

[lukas-w]

Here's a mock-up made by @vlad0337187, see #3025 for his proposal of this feature.

[Spekular]

It would make a lot more sense to me to have the collapse/expand arrow on the right, or just clicking anywhere on the track to collapse/expand.

…

On Tue, Apr 24, 2018, 09:28 Lukas W ***@***.***> wrote: Here's a mock-up made by @vlad1777d <https://github.com/vlad1777d>, see #3025 <#3025> for his proposal of this feature. [image: image] <https://user-images.githubusercontent.com/2879917/39172304-a6bcded6-47a1-11e8-8cdd-bc0cecf5f964.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#735 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIgVmnmlf0-dIaG-UmBfjhib3uEiuD_0ks5trtQQgaJpZM4B76vs> .

[vlad0337187]

Also, as Beat/Bassline editor is organized in a same way,

hope, it would be possible to create some "common" classes to use them in both:
Song Editor and Beat/Bassline Editor.

Also it would be good to display not just bars
(like Song Editor displays Beat/Bassline's patterns now),
but bars with notes
(like Song Editor displays Piano Roll's pattern now).

[Spekular]

Consolidated into #4877, but I'll leave it open for now. I'm also going to remove the 1.3 milestone because I don't see it happening. Obviously the milestone can be re-added if progress suddenly happens on this and it becomes realistic to include in 1.3.

[Hipposhark]

Here's a much better idea and a much better mockup for open track groups (ignoring the extra space on the "child tracks"):

Yes I like that

[vlad0337187]

@Spekular ,

more sense to have the collapse/expand arrow on the right

Don't know, probably you're right.
I'm just used to treeview plugins like Atom, etc (they have errors on the left side).

Btw, idea to display directory and open it by click is good too (see comment above)

[TheSheepEvolo]

Is this a feature which could be added soon?