Since Im working for years in node based environment I can insure it’s a completely different level.
USING containers you can have a clean and Modular structure of the patch
I didn’t ask this in context of idea of a container module, I asked about specific implementation proposed.
I’m perfectly aware how sub-patches or containers work in more traditional modular environments, but Grid is different in few ways, so I’m still not sure how to replicate it in a way that makes sense for Grid.
In other modular environments it’s common thing to have inputs and outputs of different types of signals: audio and data maingly, mostly also different types of data, like array or even bitmap.
In Grid though, we have everything in audiorate, there’s no true arrays yet, no other types of data either. inputs and outputs Grid operates with have to do with upper level stuff like stereo pair that device receives or hardware in/out, and interpretation of midi/note signals as inputs and then the Note output.
So, I think that container module needs to break apart from that a bit and have unique set of arbitrary input and output modules, that would only be available in container editor, as it would make no sense for Grid on the device chain level. Those arbitrary in/out modules then could be assigned names and would appear on the UI of the module you edit, so you can put as many as needed that way. So far so good, but what about polyphony? Surely, one of the perks of container/sub-patch is ability to also stack it (and not get limited at 5 stacks either) and address different ‘voices’ in it separately if needed. We don’t even have modules that could let us address voices directly in regular patches, so that’s a whole another can of worms to deal with. Introducing something like Array type signals as well would help with this though. But all in all, I can understand why this takes forever to implement if they even plan to do it at all.
+1 it is needed to go out from the current “per project spaghetti” state to a reusable framework