Public Channels vs Global Channels

yar · July 31, 2025, 4:04pm

Not long ago, I noticed a change related to the “Global Channels”. Now, there is a “PublicChannel” (it was also introduced during the global meeting). I don’t fully understand the purpose of the change or why it was necessary.

My intuition tells me that one of the main advantages is the bindings. However, I’m not really sure because I’m not completely familiar with how it worked before. It looked difficult. I also noticed that now “public channels” have their own file, which is saved alongside the patch. It’s great that you can access subchannels via a path.

I understand that there will most likely be a more complete post or explanation. Could you perhaps give it some attention and tell what the main motivation and driver behind this decision are? You could do so briefly or in detail.

joreg · August 9, 2025, 5:26am

Here are our official introductions on the topic:

please read those and come back here if any questions remain.

seltzdesign · August 11, 2025, 12:37pm

I think Public Channels (and Global Channels before that) are a huge deal, because they make something visible, that was usually hidden - the parameters/variables of an application.

Having worked on applications in vvvv for a long time now, managing the parameters and more importantly “binding” them - which is just a different word for updating or syncing them from different sources - is always challenging and gets more challenging the bigger the application gets.

In most cases you want some user-updateable settings at some point. If there are a lot of parameters to tweak you will want a UI at some point, then you might want to save and restore presets. Further down the line you might want parameters to be controlled by physical hardware or synced to a database.

All this is now very visible and useable without having to patch everything.

You can of course still do it the old-school way, but it opens up an important area in building applications to people who like to work more visually (which is kind of the case if you are using vvvv instead of just coding in C#).

Just to give some idea, this is what binding our parameters to RCP looks like as a patch:

You could now do the same with Public Channels and binding in a hand full of nodes or completely without nodes by using the UI.

yar · August 11, 2025, 1:08pm

I have had a look at everything, but it seems that during the development process you simply gained a different perspective, so I would like to rephrase the question slightly to make it clearer.

Are Public Channels what you initially saw Global Channels as (or while you were gaining experience using GC), and that is why you decided to create, roughly speaking, Global Channels V2.0?
Can Global Channels be considered obsolete with the release of Public Channels and ‘better not to use for the new design’?
Is the development of a separate entity related to the fact that you did not want to touch the legacy and are developing a new feature that will completely replace the old one?

I immediately found several minor bugs. For example, when I create a new sketch and create Public Channels in it but don’t save it, then when I create a new sketch again, this data is loaded into the sketch because they have the same name. I understand that this is ‘by design,’ but should it work this way? In general, I’m not sure that a separate file is a good idea, because any additional file in projects is a headache with assets. The question immediately arises: can’t I choose a custom location for this file for a specific project? I also found out that the Channel Browser and the opened channels were not unloaded after the patch was closed. I also found something strange in the examples with custom transitions, but I think the help patches will be updated and will work better.

What bothers me quite a bit is the channel browser. Please don’t think I’m being picky, but I can’t bring myself to call it convenient. I understand that tools and human resources are limited, but the constant practice of creating tools without gathering feedback is a path to creating tools that are convenient only for a very limited number of people. It took me a year to start using the log and accept it as it is, and I can’t say I’m thrilled with the experience. Can’t imagine what it feels like for less experienced people. It’s clear that a lot of work has been done, but please collect feedback from a truly diverse group of people. UX/UI matters.

Overall, this is a very powerful step forward, a cool story, I feel a lot of potential. Maybe one day it will be possible to create modular interfaces for project management like in TouchDesigner — drag and drop and you quickly have an interface for managing your project.

yar · August 11, 2025, 1:31pm

Also, something strange is happening with the OSC nodes:

As far as I understand, this is simply a consequence of the fact that it has only just been rolled out as a feature for public beta testing. Therefore, it is expected that there will be many minor bugs.

seltzdesign · August 11, 2025, 3:33pm

Weren’t Global Channels always just a preview feature with notes that breaking changes will happen?

From what I gather they simply renamed Global Channels to Public Channels to distinguish that this is the version of it that will make it to the stable.

As for bugs, please report them and note that we are still not at stable, so bugs are normal.

I find the channel browser convenient in that it exists at all. I can have a large datatype with many subtypes, hook up one node and see the whole tree in the channel browser. I can also see if any channels have binding and how their values change. That alone is a great feature.

I am more than aware that vvvv is anything but accessible. It tries to be minimal, it has a lot of keyboard shortcuts that you need to know, etc. From a pure UX point of view it is a nightmare. I think the Channel browser is actually a welcome change in my opinion in that it actually exposes a lot of functionality and follows some more mainstream UI conventions.

From my experience the devvvvs are always open to suggestions and feedback. So if you have something concrete you would like to see changed, you should create a post for it.

Doing proper UX and UI design is fulltime job (I know because I used to do UX full-time). Its usually not even a job one person can do full-time. I don’t think they have the resources for that. But we can utilize the community and help them by giving feedback and suggesting improvements!

yar · August 12, 2025, 10:07am

My main suggestion is to use the drag-and-drop feature of Imgui at last. Most of the UX/UI issues in the channel browser interface are minor and could be avoided by using this approach. It’s time to take control and implement drag-and-drop, which would eliminate over 50% of existing UX issues. I previously demonstrated that drag-and-drop is possible with Imgui. This may require writing an entire engine for transferring data between different parts of the software by dragging and dropping. This is probably the main difficulty. On the other hand, I imagine that I could create a tool that allows me to drag and drop channels on it, and it gives me goosebumps. In addition, there are many places within the browser itself that beg for this feature.

Little bit offtopic and thoughts about UX/UI

I'll say it again, I don't mean to be picky. Although I realize that I probably sound that way. Don't be judgmental. Honestly, VVVV Gamma and the many recent changes are the best thing that has happened in a while and the quantity and quality of work done is beyond praise. It's a work of engineering art.

But I will relentlessly pay attention to the UX/UI every time. Because if you don’t give feedback to the engineer, the UI would be nothing but consoles and keyboards, command lines and configuration files. And the answer to the question “is there any way to make it convenient?” would always be “you should be happy that it works at all”.

Good UX/UI is practically no different in time and labor costs than bad UX/UI. The significant difference is that bad UX/UI can become core legacy, so the earlier there are voices paying attention to nuances or flaws, the better chance for progress.

Maybe. I’d just like to hear the developers’ thoughts on it from that perspective. Global channels have been part of both preview and stable releases for a long time. It’s therefore interesting to consider the future of this feature.

gregsn · August 14, 2025, 1:04pm

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.
drag drop

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:

Screenshot865×668 30.1 KB

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?

catweasel · August 15, 2025, 9:32am

One thing I think would be useful is a standalone patch for the built in channel editor, so it can be included in an exported app / as part of your own gui. Maybe you can already, but I never managed to find where in HDE the preset editor lived. My quest for gui’s has always been to make building a user facing interface as easy as possible, otherwise you spend more time building the gui than the app.

yar · August 19, 2025, 9:59am

There is such a thing with the log window, for example. Very convenient, I’ve already used it several times. Would be great to have something similar with channels.

I just want you to catch my idea. Many things in the browser could be done by drag and drop. I was intuitively trying to drag and drop channels into presets, for example. Channels from presets I wanted to drag and drop into an “editable field”. Moreover, imagine: you have a window with a grid (let’s say 10x10) and you can drag channels into this window and as soon as you release this channel, a slider or knob appears inside this grid. Would that be cool?

This may not be too relevant. I'm not sure after trying to understand how the channel browser works.

By pressing to the name field search field is activated.
It feels really strange. Intuitively, I’m expecting to be able to rename it. Can we at least consider making it possible via a right-click? This place is very controversial in general, honestly.

Okay. I created something in the edit area. Renamed it (far from the first time, because “rename” is deep in the menu). Added a parameter there via “+”. Now I have it in the presets. I pressed “X” to remove it from the edit area. How do I get it back into the edit area? Intuitively I want to just drag it from the presets to the edit area, but I end up in front of a window without any prompt or hope of figuring out what to do next.

Why is there even an ‘editable area’ like this? I don’t get it.

It’s VERY odd in general that there’s no right-click context menu. I can’t say I insist on it, but I just intuitively click it to create or edit something and then suddenly nothing happens. I always think about the scenario on touchscreens and if you can do something without a context menu, you’d better do it without a context menu. But here obviously that was not the driver of the lack of a context menu.

Overall, I understand that this is a tool that was developed to debug a feature. In general, it’s even a working tool in production. But you should see my face when I try to work with it. I believe that it can be a very handy tool, although I am sure that it needs to be rewritten almost from scratch. It’s as if there is no core, no clear vision of the user experience (otherwise, I don’t understand, but there are no clues). I’m trying to work a bit with the channel browser right now to write some sort of extended commentary, but I can’t do it simply because I’m falling through the constant “what the heck”. I emphasise - I say this with all due respect for the labour and work done, I just want there to be a better experience for everyone.

Maybe we can think about some things together? Maybe a separate topic is needed? I’d like to see some initiative before some not so good solutions become core functionality. There is a very good chance that I simply don’t understand the concept and that it is actually a very convenient tool. But can we at least have a discussion on this topic?

yar · August 19, 2025, 10:10am

small bug:

gregsn · August 20, 2025, 5:14pm

HowTo Own ChannelBrowser.zip (30.0 KB)

Burn After Reading

I can’t guarantee you that this will always work. We didn’t discuss.

it might stop working at some point or
it might cost extra to use parts of vvvv in this way or
it might get extra easy to use

We just don’t know yet.

The attached patch is directly using part of vvvv. It does so by declaring a “friend” dependency on HDE:
<NugetDependency Id="SrM03Kcc0U4LiAqW5E1LQq" Location="VL.HDE" IsFriend="true" Version="0.0.0" />
This means we here use some internals of vvvv that might change and might break our patch.

Don’t sell as yours

Don’t use if you are not ok with these terms and short-wiring techniques.

I just want you to catch my idea.

Amazing! That’s helpful.

Moreover, imagine: you have a window with a grid (let’s say 10x10) and you can drag channels into this window and as soon as you release this channel, a slider or knob appears inside this grid. Would that be cool?

This is another UI. Do not expect this to be part of the channel browser. It reminds a lot what RCP does. @joreg What’s your take on that?

I pressed “X” to remove it from the edit area.

Note: if you want, you can also hide the preview columns by clicking the Cam-button:

If this what you wanted. To just hide the presets.

What you call “editable area” in fact is not editable. There is nothing there. The last column in your case in this screenshot is the “y” preset column.
That’s maybe where lots of the confusion comes from. As you refer to this area as editable repeatedly.

It’s VERY odd in general that there’s no right-click context menu.

Well ok, since we didn’t expect this area to be editable - and when monitor is enabled it is not even there - as the monitor takes away this space - it has not been designed with any UX resulting in not having a context menu.

Note that we have context menus on the channel and on the binding column header. So we are big fans of them as well.

Overall, I understand that this is a tool that was developed to debug a feature.

Well, it can be used for debugging, but it’s more about designing the surface of an app and making the most relevant application data explorable and manage this data in any way.
As far as I remember correctly, it was always meant to give you this explorability and different view onto your app.

There is a very good chance that I simply don’t understand the concept and that it is actually a very convenient tool. But can we at least have a discussion on this topic?

Sure. We already had some testers and real world usage of that thing.
So it’s not completely out of thin air. It is designed to scale to bigger applications. That’s why it might look a bit overloaded.
Let’s see if we find the time to go deep into the workflows and explain how we use it.

I think you have just some ideas of how it should work, drag-drop-wise and are confused as the workflow it is not explained thoroughly. We absolutely appreciate the input and your ideas, but please give us more time, as some of the UX team are not available until mid-September.