Works on windows.

I don't see the symptom on macOS either.

In this function:

void TrackList::AdditionEvent(TrackNodePointer node)
{
   // wxWidgets will own the event object
   QueueEvent( safenew TrackListEvent{ EVT_TRACKLIST_ADDITION, *node.first } );
}


If you replace it with:

void TrackList::AdditionEvent(TrackNodePointer node)
{
   // wxWidgets will own the event object
   TrackListEvent e{ EVT_TRACKLIST_ADDITION, *node.first };
   ProcessEvent( e  );
}

Does it improve?  But I have reasons not to trust that version.  What about this alternative:

void TrackList::AdditionEvent(TrackNodePointer node)
{
   wxTheApp->CallAfter( [=]{
      // wxWidgets will own the event object
      TrackListEvent e{ EVT_TRACKLIST_ADDITION, *node.first };
      ProcessEvent( e  );
   } );
}

(In reply to Paul L from comment #2)
> void TrackList::AdditionEvent(TrackNodePointer node)
> {
>    // wxWidgets will own the event object
>    TrackListEvent e{ EVT_TRACKLIST_ADDITION, *node.first };
>    ProcessEvent( e  );
> }
> 
> Does it improve?  But I have reasons not to trust that version.

No different,



> What about this alternative:
> 
> void TrackList::AdditionEvent(TrackNodePointer node)
> {
>    wxTheApp->CallAfter( [=]{
>       // wxWidgets will own the event object
>       TrackListEvent e{ EVT_TRACKLIST_ADDITION, *node.first };
>       ProcessEvent( e  );
>    } );
> }

That crashes on opening mixer board.

Which commit did you build?

I am very disappointed to hear about this Linux-only bug.

MixerBoard caused a lot of code pollution, requiring "push" notifications from too many other places in the code.  I did some cleanup by making MixerBoard listen for events instead.  It Binds to the TrackList which emits events when the set of tracks changes or when other track data change.  This is very desirable to make MixerBoard code more decoupled from the core, perhaps to spin it off as a plug-in in future.

The wxWidgets event propagation works as advertised on Windows and Mac -- why not Linux?

If you press mute or solo buttons or move pan or gain sliders in Track Panel -- does that fail to update MixerBoard too and is that a regression on 2.3.0?

When you add or remove a track, do you also fail to hit a breakpoint in TrackPanel::OnTrackListResizing?

(In reply to Paul L from comment #4)
My current build is 4f964c359b6471019fd052abb83d1810d431a512
I first noticed the problem on 29th Oct.

Mute, Solo, Gain and Pan are all echoed from tracks to mixer board and vice verse, but only for the tracks that are visible in the mixer board. Even when using these controls, the number of tracks shown in the mixer board is not updated.

I have a release build from Oct 9th and the mixer board is working properly in that version.

Tool Tips for the Gain and Pan sliders are still unreadable (just a black line), but that's an older problem.

If I add a break point at TrackPanel::OnTrackListResizing it gets hit when adding tracks, but not on removing tracks.

(In reply to Steve Daulton from comment #5)

The rest seems as expected.

When tracks are deleted, TrackPanel::OnTrackListDeletion should be hit instead.

Now I wonder if the problem is that wxEvent::Skip() isn't doing what it's supposed to do?  Because the problem happens only when TrackList and MixerBoard listen for the same object, and the system is wrongly considering the event as finally handled by TrackPanel despite the Skips?

Here's another one:  if you have tracks of two different names, and drag to rearrange them, does that update MixerBoard correctly?  (Because this is a different event type for permutation of tracks, which TrackPanel wholly ignores.)

(In reply to Paul L from comment #6)
> if you have tracks of two different names, and drag to rearrange them,
>  does that update MixerBoard correctly?

only for the tracks that are visible in the mixer board.
The ONLY way that I've found to update which tracks are shown in the mixer board is to resize the mixer board. Specifically, the mixer board must be resized HORIZONTALLY so the the available space in the mixer board gets close to a vertical edge of a "track strip".

Fix made at https://github.com/audacity/audacity/commit/6e75ff2

Testing on W10 with audacity-2.3.1-alpha-207-4c76e598d5859dc172e063d37287cc510fa7850f

The newly added tracks are now added correctly to the already open Mixer Toolbar.

Mixer Board also updates correctly when tracks are deleted from the project window.

Testing on macOS19,14,1 with Steve's 2.3.1-alpha build of 09Nov18

The newly added tracks are now added correctly to the already open Mixer Toolbar.

Mixer Board also updates correctly when tracks are deleted from the project window.

Tested on Cliff's 64-bit Mac build and ths works fine there too

The newly added tracks are now added correctly to the already open Mixer Toolbar.

Mixer Board also updates correctly when tracks are deleted from the project window.