If I have a mixture of muted and unmuted parts contained inside a folder , and then if I
mute the folder event, all the parts inside that folder part become muted (as expected)
BUT if I then choose “Edit… Undo” then ALL of the parts become unmuted !!!
ie . the mute status of all the parts is lost!
I might expect this behaviour if I muted the folder part then unmuted it again,
but I feel that an “undo” should always get back to the correct previous state (? )
yeah, its always been like this unfortunately… i think the past 2 versions had this issue…
any chance this could get some lovin?
Yea that is a hassle
+1 “Hassle” is putting it nicely. Deciding which parts should be muted/unmuted can be part of the compositional process. Throwing those out is like throwing out a good take. And I haven’t tried C6 yet, but if it doesn’t save that state even across mute/unmute (not just mute/undo), I’d argue that that’s wrong too.
Why should mute and/or solo come under process history?
It is best remembered as an automation.
it’s not an offline process, so will not appear in the process history.
Use the Mute tool “X” and click on a folder event that contains a mixture of muted and unmuted parts.
Then do edit->undo.
The wrong state is restored
Sounds like an awful oversight in the design. Like discovering that your alarm clock wakes up dead people.
As a work-around, would it be practicable to have one folder for the muted parts and one for the unmuted? Not much fun, of course. There’d be duplication of tracks, and you’d sometimes have to move parts between folders if you changed your mind about which parts were and weren’t to be muted. But no more zombies.
@OP
Sorry, I was talking about the Edit History.
No, you would have to duplicate the tracks themselves in order to do this.
Like the 20+ tracks i my “Keys” folder right here, would all need separate tracks, if they were to be in two folders at once.
If the folder contains a whole load of events that you have lovingly comped into a good take, like a vocal, then they are all reset when the "undo " is done. Your comp is lost and you have to go back to an earlier version of the CPR to get it back cos UNDO doesn’t work either.
This has got to be a bug!
Maybe it is a bug but at the same time we must ask is it a good idea to be using the Edit History for such functions.
I think you are misunderstand the problem.
It affects MIDI parts as well as audio parts.
When you mute then undo a single part, or many muted and unmuted parts, the "undo"works OK.
So the mute state of all the parts is being remembered, then restored.
The edit history is working fine here. Try it yourself
BUT not when muted/undone thru the folder event itself! The mute/unmute status is forgotten, then all are unmuted in error!
Well that might indicate the fact that I don’t use the Edit History to remember mute states.
In fact I’d argue for a mute group system independent of automation unless it exists already and I’ve overlooked it, my personal disposition though would be to remove mute/solo from edit history altogether.
Yes, but that’s exactly what I meant …
It would be as if you’d started with two copies of the tracks, one copy with all the tracks muted, and then, from the un-muted tracks, had deleted any parts that were to be muted, and, from the muted tracks, had deleted any parts that were to be unmuted. That’s why I said “Not much fun”. 
And those two sets of tracks would become the two folders that I referred to. Of course, if every part on a track was to be muted, or every one unmuted, you could delete the whole track from one of the folders.
A PITA, perhaps, because it would be inherrently error-prone, and you’d have to take care to avoid errors. But it would work, wouldn’t it? – “No more zombies.”
It is irrelevant whether or not you believe that muting / unmuting SHOULD go in the edit history.
The fact is that it DOES go in the edit history every time you mute or unmute a part, whether you want it to or not, It is designed that way, it works fine 95% of the time - however there is a problem with it under certain circumstances, and that problem needs addressing otherwise information can get lost! Steiny?
bump!
BUMP!
Reported (28598)
Gr,
JHP