hey guys, sorry for the delayed answer. Thanks for stepping in @seltzdesign
let me try to structure my answer.
Naming and concept
PublicChannel just seemed more accessible to us than GlobalChannel.
Of course there are plenty of ways to think about those entities, and we discussed different naming options and that’s just what we then settled on in the end.
You can see them as channels with a name and after establishing all the bindings they kind of can still be thought of as global, but that’s just one of many takes on the topic. Application Parameter is a completely valid take on it as well. It’s just a variable that everyone can access without the need of thinking in terms of data types. You just need a path, which then makes it easy to establish the surface area of an application that allows to interoperate with designers, devices, protocols via primitive data types.
PublicChannel node
We made sure that it feels much like the Channel node. Signature-wise. Pin namings and types matter when you want to quickly replace them. The behavior of the GlobalChannel node was just a tad different and that’s why we didn’t come up with a converter and just kept the old obsolete nodes. They still interoperate just fine. No need to switch, but it might be confusing to have them flying around. But it’s not breaking to stick to them.
Development stage
We made the general feature - with it’s sub-features like presets, transitions, bindings, meta-data, publish, browser UI - public early on in order to have a better interaction with users in the prolonged development phase. Marking it experimental was our way to communicate that this is work in progress. This is now coming to an end with certain guarantees regarding stability of API, metaphors, namings, workflows.
Channel Persistency
They have their own file to be able to reestablish them on startup early on. Which helps when you want to trigger a preset on create. No need to make sure that channels get created programmatically before, as this is taken care of the persistency system already.
interplay with Publish:
If e.g. a Publish node now gets executed, it will benefit from the potentially already initialized channels and feed the object graph (the properties of your data type) with the data that you triggered via preset early on. Side note regarding Publish: If you didn’t write to the channels yet, the channels will get initialized with the current values of the properties of the object graph. However, we still mark that Publish node as experimental as we are still working on some details to make it as easy to use as possible.
Configurability
Regarding request to specify the file name: that could happen in the future much like the way that you can configure the name of the presets folder.
UX
That’s ongoing effort. We have some ideas on how to glue it to your patch faster and make it as effortless as possible. For now: the newer versions allow to drag & drop channels from the browser to your patch resulting in PublicChannel nodes.
It could feel good to be able to drag values from cells to cells. (basically something that already works for colors in certain cases.) Let’s see how easy it is to integrate without making it look more complicated.
For sure, capture and playback can be seen from different angles and buttons could look different allowing to trigger capture and playback on a cell level and stuff like that. We’ll collect more feedback on it and refine accordingly.
Also, your remark about the browser still showing a glimpse on the already stopped application got tackled. It feels more consistent like this.
So yes, feedback gets heard. Not always, but yes. And it’s not proven yet if much praise or much criticism is the best way to get heard, or neither of. Keep it coming though!
ImGui drag & drop
I previously demonstrated that drag-and-drop is possible with Imgui.
Holy moly. Sorry, I didn’t see that before. Somehow slipped through. That is quite good!
In the case of dragging from browser to patch I had to go for another API in order to be able to drop on patch, but yeah we should finish delivering the feature for purely inside ImGui drag&drop.
Regarding future ImGui node-set development let’s continue in the other thread. But I see that you yourself are already able to do all things drag&drop, so maybe fine for now, but on the list for integration into StdLibs.
OSCClient warning
Also, something strange is happening with the OSC nodes:
Hm. Maybe I wanted to show the inner troubles and wanted to translate some exceptions into warnings as they are not hurting. But I should recheck if that particular exception is caught in a such a pleasant way that it shouldn’t be reported at all.
Or is it not working. Or is it false alarm?