A minor display issue mentioned in a recent thread. It's submitted to development (not as a feature request) so I guess it's a bug...
 
[Steps to Reproduce the Issue]
1. Create a new project.
2. Insert two audio tracks.
3. Select the tracks, right-click on one of the tracks and choose Move To Folder > New Track Folder.
4. Adjust the height of the tracks so that the Archive buttons on the tracks are visible.
5. Color the tracks to make the folder apparent if you like.
6. Click the Mute, Solo, Record and Input Echo buttons of the first track, followed by the Archive button of the second track.
 
[Expected Result]
The Archive button on the track folder is only half lit, just like the other buttons on the folder.
 
[Actual Result]
The button is fully lit, failing to correctly represent the status of the tracks in the folder, like this:
 

 

Issue #: CWBRN-23756
Reported on Jan 31, 2014
Confirmed and submitted to development on Feb 4, 2014

Time to start Googling before reporting. You advised another poster last November that this should be a feature request:
 
http://forum.cakewalk.com...e-arc39d-m2939597.aspx

Regardless the of that, it's clearly a bug. The button should only be half lit up, rather than fully lit up. It is misreporting the current status (if an ON button is lit up when something is OFF it is being misreported). Mute/Solo/Record and echo are reporting the status correctly so should the archive button. Not only that Cakewalk says it's a bug as it is submitted to development.
 
On another matter. When the archive button is pressed the SOLO button is disengaged for the track. Shouldn't this happen with the mute and echo button as well? (I wouldn't argue this is a necessarily a bug, then again maybe it is, but is it appropriate behaviour considering the group buttons are doing another thing?). It is consistent with what is going on?

Solo (and record arming) are the antithesis of Archive, so it makes sense to disable them. Mute is a close cousin of Archive, so it makes sense to leave it enabled. The one I would question is leaving forced Input Echo enabled; it becomes inactive on an archived track so it really should be gray, and bad feedback could result if you were to un-archive in input-echoing track with a live mic input and output going to monitors in the same space, so I would be inclined to have it disabled as well. But I would also categorize this as a feature request.
 
Things get tricky when you throw grouping in the mix. In a perfect world, I would say all active buttons should display some half-grayed state on archive and be functionally disabled but maintain sync with grouped widgets such that those widgets can still be controlled and the archived tracks' buttons states are synced with the group when unarchived. Right now if you archive a track that has widgets grouped with some active track, you can run into problems.
 
 

brundlefly
Time to start Googling before reporting. You advised another poster last November that this should be a feature request:
 
http://forum.cakewalk.com...e-arc39d-m2939597.aspx

That's the thread I was referring to in the original post. At that time I thought it was a design flaw, but afterwards some other issue I'd been considering as a design flaw turned out be a bug (confirmed by CW), so I thought maybe this one's a bug too. Also, the aim of the series of bug report threads I've been posting is to have the issues listed in Alex's X3 known issue thread, which I believe is quite helpful for those thinking of upgrading to or purchasing X3 as well as those wondering if the issue they've just encountered has already been report to CW and confirmed by them. If I was to buy Cubase for example I'd not only try the demo but also check the bug list in their forum (maybe doing so before buying the usb e-licenser to try the demo is wiser). And, a new thread with the first post explaining that it is an issue and has been confirmed by the developer can save the reader's time IMO, compared to a thread that discusses whether it's a bug or a design flaw or simply a user error.

My view is that threads like this can help cakewalk get a good overview and gage the priority (well what other people think outside their organisation), especially if you supply a URL to in the bug report so they can reference it. Otherwise each bug report is effectively an island with a giant barrier around it. The times I hope Cake would comment is when some bug report is rejected for some reason (otherwise a waste of time for them) just in case it has been misreported to them, or they have misunderstood it.

According to Jlien X not fixed in X3E.