Extremely odd "Group" behavior as opposed to "Quick Group"

[winkpain]

There is something very obviously not right here! I am noticing some very odd behavior in grouping controls. I see it in the current release and tried rolling back to previous release and found it to be the case there as well. A quick description of examples and videos:

I have several tracks that I want to toggle the alternating Mute states of in an "A-B" manner, so grouping the Mute buttons is in order. I mute every other track, then do a CTRL-A, select All, and CTRL-click any of the tracks' Mute buttons in the "Quick Group" manner and get the expected behavior, both in Track View and in Console View. This is shown in the "Working correctly" video.

Next, I set the tracks up similarly with alternate tracks muted, do a CTRL-A select All, CTRL-right click and Group all the Mute buttons with a group letter and color (not Quick Group, in other words). After doing this, I expect that clicking any of the now grouped Mute buttons will have the effect of the toggling achieved in the previous arrangement. This is not what happens as you can see in the "NOT Working correctly" video. On the contrary, none of the Mute buttons work in the expected way except the last one (I have tried with different numbers of tracks, and it is always only the last track that works as the group toggle), and that is only the case in Track View. In Console View it's all very, very...odd. I show this in the video by clicking on each of the Mute buttons in both views, and well, you can see what happens. (In addition, at the end trying a CTRL-right click and "Remove from group" with all tracks selected does not function as expected here.)

This is, for sure, not right. Quick Grouping works for my toggling purposes at the moment, but why this behavior with "permanent" grouping?? Surely there is something wrong...

Edited June 4, 2021 by winkpain

[Base 57]

I see you are assigning the mutes to an already existing group. What happens if you assign them to a New Group? 

It's working correctly for me but I used a New Group.

[winkpain]

3 minutes ago, Base 57 said:

I see you are assigning the mutes to an already existing group. What happens if you assign them to a New Group? 

It's working correctly for me but I used a New Group.

Same thing.

It perhaps showed as an "existing" group in video because I had sampled the scenario a few times. But Starting a new empty project, setting up as seen in video, choosing New Group, etc. all behaves in this same odd and incorrect way.

I noticed it when working on a project and wanting to set up this grouped Mute toggle situation, but I have now tested it with, as I say, new projects, closed and re-opened, rolled-back to previous version, and re-installed current version. It is consistently f***ed up   in all scenarios.

[winkpain]

Further evidence:

The Group function works as expected with Audio or MIDI only tracks. So, the issue is only with the special combo "Instrument" tracks, and no matter what virtual instrument they are connected to.

 

[Base 57]

Okay I can duplicate your problem now. Audio or Midi tracks work properly. Instrument tracks however (as your video shows) don't. For me it is only after opening the Console View.

I see you beat me to it

Edited June 1, 2021 by Base 57

[David Baay]

This is an old issue that I reported way back in 2016. Last worked as expected in X3e.

[winkpain]

9 minutes ago, David Baay said:

This is an old issue that I reported way back in 2016. Last worked as expected in X3e.

Wow! OK. Perhaps it was an issue when Instrument Tracks came in that never got ironed out?

If it's been 5 years, I guess it's not on the table, then.  Good to know about, at least.

[Starship Krupa]

On 6/1/2021 at 12:18 PM, winkpain said:

If it's been 5 years, I guess it's not on the table, then.  Good to know about, at least.

I would discourage taking this viewpoint. The company to which @David Baay submitted that bug report hasn't even existed for the past 3 1/2 years. In that time, the entire staff was laid off, then some of the engineers got re-hired by a new company to continue development of a new product based on the SONAR code. Since then, new development staff has even been added directly from the Cakewalk user base.

So a new organization, with visibly different priorities. Even if to us, who are using a program that looks pretty much like the old one, it's the same user experience continued. Something that was tabled as low priority in the Gibson years might be a bigger deal in these better days of BandLab, so take a few minutes and submit it. Worst that can happen is nothing.

I understand the frustration of going to the trouble of submitting a good report and having it seemingly shrugged off. Believe me I do. But things are different now, and the current dev team seem to take a lot of pride in the number of longtime bugs they've fixed. They'd probably like to fix some more. Even if the old bug database survived the transition intact, there can be an assumption that if an issue has been sitting there for 5 years, it's probably not ruining everyone's day. So a ping about these old things might be in order.

[David Baay]

4 hours ago, Starship Krupa said:

...there can be an assumption that if an issue has been sitting there for 5 years, it's probably not ruining everyone's day. So a ping about these old things might be in order.

This is likely a big factor in this case - not enough reports to make it a priority. I had forgotten about it myself because I only stumbled on it the one time. It just sounded familiar enough that I looked back through my old bug reports to find it. 

[winkpain]

7 hours ago, Starship Krupa said:

I would discourage taking this viewpoint. The company to which @David Baay submitted that bug report hasn't even existed for the past 3 1/2 years. In that time, the entire staff was laid off, then some of the engineers got re-hired by a new company to continue development of a new product based on the SONAR code. Since then, new development staff has even been added directly from the Cakewalk user base.

So a new organization, with visibly different priorities. Even if to us, who are using a program that looks pretty much like the old one, it's the same user experience continued. Something that was tabled as low priority in the Gibson years might be a bigger deal in these better days of BandLab, so take a few minutes and submit it. Worst that can happen is nothing.

I understand the frustration of going to the trouble of submitting a good report and having it seemingly shrugged off. Believe me I do. But things are different now, and the current dev team seem to take a lot of pride in the number of longtime bugs they've fixed. They'd probably like to fix some more. Even if the old bug database survived the transition intact, there can be an assumption that if an issue has been sitting there for 5 years, it's probably not ruining everyone's day. So a ping about these old things might be in order.

These are all excellent points. And I was coming just back on board to do something along the lines of "re-pinging" the issue, as it is, in fact, quite an annoying one.

I have found that the odd behavior noted above leaves behind curious "remnants" that cause confusion. In my examples with grouping the Mute functions as seen in the second video, I have found that, going back into the project where I first noticed the problem,  tracks that I had been working with in the manner shown have remained mysteriously muted without any indication on the track's Mute button. This is likely (I guess?) related to the Mute buttons not responding correctly as you see in the second video in that, maybe tracks are being muted without the indicator on the track showing it. I don't know. But I found that toggling the master Mute button on/off in the control bar would relieve it, although...not consistently.

Suffice it to say, there is something very weird going on when grouping Instrument Tracks that warrants looking into.

[winkpain]

3 hours ago, David Baay said:

This is likely a big factor in this case - not enough reports to make it a priority. I had forgotten about it myself because I only stumbled on it the one time. It just sounded familiar enough that I looked back through my old bug reports to find it. 

And on that note, @David Baay, could you put up a link to your post on the old forum for curiosity and comparison?  Is it still available?

[David Baay]

Doubt I posted about it. Just reported directly to the Bakers.

[winkpain]

.... I just sent in a Support request on this as well.

 

 

[Starship Krupa]

This also illustrates how for one user something can be a nasty, while for another, they might never see it. For instance, I never use Instrument tracks, only split MIDI/Synth. I like to experiment with different synths on the same MIDI material and there are advantages to just switching the output on the MIDI track.

[Starship Krupa]

2 hours ago, winkpain said:

Suffice it to say, there is something very weird going on when grouping Instrument Tracks that warrants looking into.

My guess would be that it has to do with an Instrument Track being a conjoined set of Synth and MIDI tracks, like the Grouping is failing to apply to the audio track. If it once worked correctly and then broke, that makes it relatively low-hanging fruit. A programmer with access to the code before and after can diff them and see what was changed.