When I instantiate a VST3 plugin in Ableton Live 11 that overrides AudioProcessor::updateTrackProperties I see that the function is called three times. The first call reports an empty name string and a default initialised colour, the second call reports the valid track name along with a default initialised colour and the third call reports an empty track name along with the valid colour.
A bit of debugging reveals that JuceVST3EditController::setChannelContextInfos is indeed called three times by Live, probably to report three different context informations, including name, colour and a third one not handled by JUCE. Due to the way Live reports it, from within the plugin it is hard to distinguish between the cases where the user actually set an empty track name, which we might want to handle different from a case where the updateTrackProperties callback is caused by some other property being set and an empty name string is a side effect of the current implementation.
I can think of two possible solutions to that:
One would be to change the struct members of juce::AudioProcessor::TrackProperties to std::optional so that we could distinguish between the cases of a property just not being reported and a property explicitly being set to a default value by the user.
The other one would be to add an additional listener interface which exposes granular callbacks for track names, colours and hopefully even more properties which are simply called in case that a change of a certain property is reported.
The new listener class would probably be more extensible and non-breaking, however would add some more complexity to an already complex class.
In any case, I’d highly appreciate if you considered adding a solution to the problem, no matter how that solution would look like. Would be glad to hear some thoughts from the JUCE team!