Replicate by Python Dictionary or List

A mode to replicate containers based on a nested Python dictionary or list would be useful. You can currently dump out a list of keys or items into a table and replicate that way, or replicate by number and set the expression to len(list) or len(dict.keys()) , and then attempt to grab the correct item programmatically from within the seperate container, but it feels a bit kludgey. Perhaps instead, there’s a replicate by python option in the drop down. This could activate 2 fields. The first would be a field that would look for a list or dict returned by a python expression, that would control the main replication. However the second would be a field that would be the name of a custom parameter to assign the nested object to automatically (whether it’s a primitive data type, or list/dict). This would be a very fast way to unroll complex data storage objects that need to map to actual operators in touch.

For example, if I had a Dictionary for output mappings like {'screen1':{'sources':['input1'],'screen2':{'sources':['input2','input2']}} , I could use 2 layers of replicators. For the first, I would hook in the main dict, and then assign the subitems to the new custom parameter of Screenmapping. This would give me 2 containers representing each screen. Then each screen container would already have screencontainerop.Screenmapping assigned, so screencontainer2.Screenmapping would return the dict {'sources':['input2','input2']} . At this point, a second replicator within the screen container could point to Screenmapping.sources as it’s main input, and then create a container handing that input and so on.

Obviously screen mapping you could handle in a much different way, but if you try to think about nested object oriented data, it’s hard to convert that into meaningful operators without multiple layers of scripts that can be confusing to debug later.

I set up some of these networks with a table DAT and a id, parent and type column. I can get the depth via the parent and depending on the type, each replicated COMP is either of another replicator type or of a “regular object”.
The master operator for the replicator is of the basic type of what the nested tree is made for: containers for Screenmappings, Geo COMP for things like KantanMapper, Base COMPs for playlist items etc.

I don’t use much scripts for this, just a lockup into a table that maps the type to a clone source. The replicants use the cloning parameter to fetch the right source and the replicator callback turns cloning off.

As an example create a couple shapes and groups in KantanMapper and then check kantanMapper/project/allShapes
The groups and shapes are saved in the tree Table DAT. The replicator callbacks call a smallish function in the Layerizer Extension.

Is that going into the direction of what you are looking to get simplified?

Cheers
Markus