I would think so, but then one table with a couple of different formats in it is harder to read, so how much better is it?
My question is:
I’ve developed a custom component, which contains two tables in it. One to store some settings and one to give some info about itself - including where the code to manage the component resides (so the code is common to all components of the same type and doesn’t need duplicating).
Thing is, such components are going to be everywhere in my system, from buttons to more complex structures, so having one table instead of two per component may save a few hundred operators.
Derivative gurus, given that I want to keep settings and info on individual components, do you have any advice? (1 table per component instead of two, 1 big table somewhere - which may then get cooked too often though), etc.?
It’s hard to tell until it’s tried really. But in general I think a mid-level amount of compartmentalization is good. So using different tables for different types of information is good. This will help avoid overcooking while still keeping things organized. Using one mega table will be hard to optimize well, although we are trying.
Trying to avoid extra DATs probably isn’t worth the time, the node count in a synth doesn’t really matter that much (unless they use up large amounts of memory like SOP and TOPs ofcourse), just the number of nodes that are cooking.
Besides memory, an really important node count drawback is the file load time. With a total component based workflow you quickly have 20k+ nodes in your file, so I’m trying to reduce node count wherever I can. This also becomes important if you wanna load a component’s UI from a tox (or script-create it) on demand, as you can’t create/load components independent of the main render loop.
It’s gonna be interesting how your new, component based parameter editor will behave, as from a quick look in /UI the various components have a very high node count (e.g. border logic everywhere, …).
Dani, I would go with two tables (if I understood your setup). I did it like this:
Each component has an admin container, inside is a table holding various properties of the component (component type, timestamps, …). In component/local I have another table which holds all the parameter values of that component, so when you update that component to a newer revision all values you need to persist are in that table. Together with some additional admin nodes I have a minimum opcount (for a no UI component) of ~8, which is much, but OK.