Again some urgent improvement requests on the (good) old v4, after the completion of a project that was actually to big for v4 as we know it.
1.) Lazy Evaluation
When we look at what makes using v4 complicated, a major amount of work doesn’t go into patching logic or design, but only into making the patch perform again–and in itself incurs the use of many nodes that are there just for computation management.
In our usecases, for rendering the actual scene only a few of all nodes in the patch are required at a time. The rest needs to be put to sleep manually. And a large set of nodes is actually only there to manage the project flow, or to set initial values and never changes. For many computations it doesn’t matter, whether their result arrives in one frame or the other. And also de-evaluated parts of the graph still consume ticks.
So here’s the proposal.
We need a possibility that is integrated into the UI, that sends parts of the graph to a lazy evaluation thread, to make room in the main thread for the actual scene. In large projects 50% of CPU power is consumed by v4 infrastructure nodes–and we already use A LOT of evaluation logic.
Think from the perspective of a boygroup client. As a boygroup client, you get only the part of the graph that you actually need for the scene - and control and initialization data comes from the outside. That is what you actually want - But on a local machine. Decide, which parts of the graph are sent to the MainLoop, and which can be evaluated lazy.
Of course you could say that you can do this in a boygroup setup (And the 'we can also patch it in VL‘ theory). But on a local machine there are so many more possibilities and ease of use. Even branches of the graph that have node outputs could be on a lazy thread.
As in boygrouping, let the user decide and learn what works and what not.
Use Ctrl-B to send nodes to a boygroup. Use Ctrl-H not to hide the nodes, but to send them to a lazy thread. Or come up with another state for the nodes.
The proposal is kinda old and around since a long time, but I think it needs to be revisited and can be addressed with less concerns regarding timing accuracy and IPC. For the deep shit we’ll learn VL. But for the time being, we need a way to expand the magintude of v4 projects. It’s at the limit of what it can do in it’s current form.
2.) UI in a separate thread.
Get a grip and move the UI rendering to a separate thread. This is the single most annoying thing to constantly explain people that this stuttering on the LED is normal, because v4 has to render the interface in the same thread–and we need to keep on working. It’s really bad, and I think justifies touching the code of the plugins that manage their own windows.
Smaller issues and proposals.
The keyboard is actually very empty. Every shortcut starts with a Ctrl-. So … we have a whole keyboard of unsed modifier keys free! Like in other applications, where you can change the tool with a single key, you could have many more operations on the keyboard in v4. Or just get rid of the Ctrl-Key all over. Just press B for Boygroup. etc. Because: The letters are only needed in the node browser, or when you are in node-creation mode, or edting an IObox, etc. All separate states. But when you’re just navigating the patch, none of the keys has a function.
S-R nodes. Finally we have a sorted list of senders/channels. How about selecting the channel that match the letters that you type? Still a lot of unnecessary scrolling / searching.
Highlight pins containig non-default data (for example when pressing the letter P ;) )
