How do I can detect what changed after play?

I missed when it happened.

Now if I play session, then the name of the session show up asterisk. This means that there have been some changes. I save the session. Asterisk disappear.

If I try save the session during playback then asterisk shown always. This means that changes occur always.

I presumed it can be generation of vertices/points for envelope of automation with “write” mode. I checked all existing automations for all tracks and all of them are set in “play” mode.

What more can generate changes during playback?
How / where can I see debugging info that help me?

Ah - thank you for that explanation. I was wondering myself why the file showed as changed when I was sure I hadn’t “changed” anything.

I think this is actually a bug: it happens whenever there is any automation control set to “Play”, but not if they’re all on “Manual”, which doesn’t seem like sensible behaviour to me.

I've made a bug report at http://tracker.ardour.org/view.php?id=7070.

@colinf thanks for bug report.

But, guys, for this question still need answer: How / where can I see debugging info that help me?
Because this is not a single situation.
This info should be allowed.

Why would you expect to be able to see what changed ? How would you expect to see it?

@paul just history of events that changed session state. Log messages, maybe with args. Ex.: “Item %1 of %2 changed to %3”

I can see no conceivable use of such an event log for 95% of all users. The undo history already records that sort of thing anyway, if someone really wants to look at it.

About 10 years ago, I cooked up a version of Ardour that supported the “branching history” model that Cubase had just tried out. This required actually presenting the undo/redo history to the user in some GUI dialog, and allowing them to jump to arbitrary states.

I cancelled the whole thing after a few months when it became clear that the whole design caused so much confusion among most DAW users (i.e. the ones who have no programming background). Along with it went the thing that showed the undo/redo history, and nobody has ever asked for it back.

But it is more complex than just the undo/redo history. We have many things that cannot be undone (or redone) - notably most signal flow/processing changes. But these things still mark the session as dirty. In some cases, describing the change is either needlessly complex or sometimes not possible at all.

This strikes me as a perfect example of a DAW corner case: a feature of great use to a tiny number of users. If we employed 20+ programmers, perhaps it could be justified. As it stands, I cannot justify it.

@paul

For first, I don’t require.
No branching history. No jumps to arbitrary states.

I mean readonly log, maybe like debug info. What for? For example I have many automations. Long checking to find the problem.

I just think.
Hmmm… This can be very similar to global solo or mute alerts. But more concretized, summary info. Maybe not need logging, maybe separate window in which the critical states: specified tracks of set as solo, specified automations of set as write, specified tracks which level overload, something else.

More: specified tracks with enabled record

Sorry, I can’t justify the work involved in doing this.

@paul

This is dirty example of my idea: https://jsfiddle.net/u5qzkmgc/

I not have any skills for GTK (just write simple apps on wxWidjets). If I was sure I could do it myself and give you patch, I be did. I understand this may require more time for devs. For any case, you decides what need and what is not.

btw, the original issue that triggered this thread has been fixed.

@paul nice news!