Especially for plugins this could be a great experience (writing automation, etc.). Can you understand from the documentation, if it’s possible to have a touch bar view for the plugin, which is frontmost?
You can implement app-specific controls in the app region to the left of the Control Strip.
which makes me think, that the DAW / host will occupy that area. To use it in the plugin would need the host to aloww the plugin to display it’s icons and get back the feedback. This means changes to the SDKs like AU, AAX, VST, VST3.
So using it in Juce-applications eventually, but in plugins - unlikely IMHO.
As I understand it, it will behave like the OSX menu bar, which changes with the selected app. But a plugin is never an app, so the OS cannot know anything about the plugin. That’s why I assume we only get that feature, if the DAW will support that and also if it chooses to yield it for the plugin.
To use the Touch Bar, define bars in objects in your app’s responder chain. At runtime, the system traverses the responder chain to discover, combine, and show bars from your app and from frameworks you link against.
This sentence made me think it could be possible to have a custom touch bar interface for a plugin, but I don’t have a good understanding of Apple’s “responder chain”
Using the touch bar I experienced it being much more than that. The menur bar only changes globally for the whole app, while the touch bar changes content based on the context. (mostly depending on which element you clicked at within your app)
The NSCustomTouchBarItem class allows developers to provide their own NSView objects - there’s JUCE’s gateway to drawing its own components in the touch bar with likely very little work needed from the JUCE team…
When TouchBar support is available the NSWindow actually will have a property touchBar you can set. The responder system might not work so well with Juce. I made it work by just setting the Touchbar property when I want.