Yop, had quite a small ever growing collection of ideas on how to improve vvvv, and thought I would share it.
As every software there’s stuff I like/dislike, so let’s get rocking!
Things I like:
- Quick/Minimalist/Simple but easy to use interface. Just all connections/shortcuts bring your productivity to the max.
- Spread/Bin size, once you get used to it, is just great, the autofill makes life so easy.
- Animation filters are second to node, look at any software which already has built-in damper/oscillator/deniro…
- Plugin Interface (ah no never used that one, so can’t really comment on it ;). Bringing any of your code for this exotic device, and interface is really striaghtforward.
- Cool devvvs which bring new features ;)
- New dynamics is great too, i dont use it so much myself apart for quick tests, still enjoy my good old visual studio, but that brings some really nice ne possibilities.
- Great community : people who chatted with me on some subjects at node will know what about i’m speaking of.
Ok know let’s stop praise the devvvs (couldn’t praise them enough but that’s not the point of the post) and give them some stuff to think/work on ;)
Gonna split it in different parts:
Graph level
- UI tied to mainloop: having my gui dropping at 1 fps when i set my mainloop/or on the other hand, having my patch going down 10fps when i move an iobox is one of the things which could be a major improvement.
- No ability to change the evaluation mode for a node (the AutoEvaluate in a plugin or any native node). Means it become very cumbersome to use a lot of switch/s+h to make sure the “whole” subgraph is not evaluated (specially when using LFOs, Dampers…)
- Disable a node: Option to just fully disable a node would rock (specially for a decently big subpatch). Just in that case do not call evaluate as all, while still having the advantage of resources preloaded in memory.
- Singleton nodes+ alias: Whereas S+H is quite handy, it doesnt cope very well with multiple variables type. So we could declare a node as singleton, and then create an alias in a subpatch (inputs would then be disabled and another color). Internally we could just evaluate the singleton only once, then create some internal links. When you have some config files and xpath queries that you need in several places can come in very handy.
- Threaded node: Any node which is “heavy” could be marked to run in a thread as soon as all it’s own dependencies are satisfied, so other “smaller nodes” could still be run in the mean time. That would need to bring in some priority system (you want your heavy node to be executed asap, not last otherwise it’s useless), also you need some node evaluation statuses, so threaded node can notified when it’s done. I would not think that doing auto threading is a good idea. but more give the option to the user to decide (non threaded by default), as a node evaluation speed can change drastically upon some parameters.
- Threaded node (again): node which executes outside of the mainloop, with Input/Output pins synced in the evaluation.
- Node pooling: Some kind of advanced CreateNode. You create a list of nodes which have the same inputs outputs,and register them to a pool, with a preload/switch option.
- More information about graph evaluation process: Some kind of inmproved timing node. Also ability to “watch” a node (evaluation/error) and get the data into a patch would be very useful for profiling.
Node level:
- Threading+SIMD: lots of nodes could benefit from new pc architecture, we are not gonna have faster cores for a bit, so using cores+new possibilities is definitely something not to neglect. You can obviously do some cool stuff with GPU, but cpu still stands in between, I class them at friends as they both need each other. Ideally the user could choose if he want to enable threading/sse optimizations, as they useless (and make things slower) for low spread count.
- Other optimizations: There’s a lot of little tricks which can be worked on depending on usage, thinking about Select for example, could have a High Spread mode/Low Spread+high select mode
- More control on evaluation: For example we could decide if a node executes blindly every frame, only on pin change, or have a bang to specifically mention we want it to evaluate.
- Common model for devices nodes: Midi can have the same device on multiple nodes (so somewhere a singleton is kept), UDP server can’t (so the node itself reserves the port). Ideally all of them should behave identically.
- Any node which can’t work/fail should have a error pin: Reader (File) should for example be able to tell me if it can’t read a file because it doesn’t exist, or i don’t have read access to it, already in use…
Pin Level:
- Ok let’s start by the big one. The biggest problem I see in vvvv now is: non consistent datatypes. Color is double, Value is double, Matrix is float. That would mean somehow we could say “change matrix as double and that’s fine”. But problem is most of the render engines/gpus are optimized for float, meshes are float, textures are byte/float, and same is color. so having a proper consistent datatype would avoid loop/cast and enable direct copy, which is a hige performance improvement, and also helps a lot to make code cleaner. I know it’s a VERY drastic change, but I definitely believe the reward is worth the effort (did i mentionned box2d/bullet/physx/any good geom library also use floats? ;)
- Float is cool, but Float16 is better :) Cpu read memory by block of 4, so a float could be 16 bits aligned by default. Apart from the improved read/write operations (which also work on gpu, copy is around 20-30% faster with aligned data), it also enables the use of simd as mentionned above (you can still do sse with unaligned data, but a loadu call is so slow compared to load it’s very often not worth it).
- Color/Transforms: Would of course also benefit from alignment (even more as color = 4 floats, matrix = 16 floats = 4*4 floats), so a lot of operations could be heavily streamlined for it. Not going too much into details as it would be 10 pages on it’s own ;)
- GPU types + conversion: Having data being stored in gpu instead of cpu and options to bring it back and forth. Nodes could have an option to switch between cpu/gpu types. Also some operations like mesh/texture building could have a huge improvement using gpu types, so having a streamlined system would bring vvvv to the top ;)
- Categories for configuration pins: Would be a nice thing to have so when you have a lot of those, so they would be sorted somehow.
- Polymorphic types: A bit like the node type, but we could have more inference (like inheritance). Also being able on the first connection what we want to accept (like is i connect a Box, which is also a Shape, if could choose if the node wants to accept Box only or any Shape).
- Some device related pins as types. Thinking UDP/Midi for example. Would be great to have a UDP stream type which sends an event when data is received instead of just a string. This kind of data should not be tied to mainloop.
Thanks for reading, got lots of other ideas but I’m tired typing now ;) If you want me to explain some stuff more in details feel free to ask.
PS: In thread type you have statement,bug,feature,question, maybe you should add “Long post of random stuff to keep devvvvs busy” :)