[FIXED] Grouped items split - erratic behavior. Some items not in new group

[Daodan]

Hi.
Recently I started using grouping more and noticed that after splitting, some items are not added to the new group.

Here is an example:

When I split item at 1.2 item on the 3rd track not added to new group. Same at 1.4 but both items not in new group. Definitely they should. rpp attached.

I made a new test project and got a different result:

Now everything OK with 1.2 and 1.4 but not 1.3.

In 3rd project it works differently again and this is how it should always work:


FIXED IN 6.60 THANKS!

[schwa]

The issue is that the items at 1.2.00 on tracks 2 and 3 are not positioned exactly on the beat. You can see this if you select the item at 1.2.00 on track 2 and open the media item properties dialog. If you then add the item at 1.2.00 on track 3, you will see the position field blanks out, because the values are not at exactly the same position.

If you type 1.2.00 into the position box (make sure the radio button in the position/length area is set to beats), then both items will be positioned exactly on the beat, and will behave consistently with respect to splits and grouping. However, notice that the logic groups items together that begin *after* the split point, not *on* the split point, so if you select only the first item and split at 1.2.00, the items at 1.2.00 on tracks 2 and 3 will not be included in the new group.

[Daodan]

Originally Posted by schwa

The issue is that the items at 1.2.00 on tracks 2 and 3 are not positioned exactly on the beat. You can see this if you select the item at 1.2.00 on track 2 and open the media item properties dialog. If you then add the item at 1.2.00 on track 3, you will see the position field blanks out, because the values are not at exactly the same position.

Thanks! Sorry for the late reply. That was my first thought so I cheeked media properties and saw that the values ​​are the same. I didn't think of selecting both items at the same time. Now I see.
But why might this happen? I tried to find out, but did not understand when exactly this happens. The only thing I can do is upload a project where you can reproduce the following:
1) Split items on tracks 1, 2 at 5.2.0 and 5.3.0
2) Copy item from track 3 to 5.2.0 and 5.3.0 (via mouse drag)
3) Items at 5.1 and 5.3 - OK, exactly same position. But not at 5.2 for some reason:


Also I noticed that copy mouse drag and ctrl+v works different:

All items not exactly at the same position. Shouldn't they?

Originally Posted by schwa

However, notice that the logic groups items together that begin *after* the split point, not *on* the split point, so if you select only the first item and split at 1.2.00, the items at 1.2.00 on tracks 2 and 3 will not be included in the new group.

Ouch. Can it be changed somehow? Would be great to group loops with one shots and when I split and move long item all other short grouped items under this new item moves together? As it is shown in the third gif in the first post.

Other than that, I was thinking about grouping empty item on folder track with items inside this folder to achieve some kind of "folder items" effect. Now it's dangerous

[schwa]

Hm, I think the reason the item on track 3 is not exactly as the same position as the split items on tracks 1 and 2 is a possibly meaningless rounding error. As a practical matter, if I copy the item on track 3 to position 5.2, and then group the items on all 3 tracks, the items do end up grouped as expected. But now I'm wondering if the fact that they end up as expected might be *because* of the rounding error rather than in spite of it.

In any case, it does seem reasonable that splitting grouped items should re-group all items that start at effectively the same position, even if they are technically misaligned by less than a sample. We will look at whether changing this behavior might have any unexpected side effects.

[Daodan]

Thank you schwa!