Oni Shogun

I am building a patch to manage mappings and assignments to the Livid Code controller. This involves multiple patches, each handling the settings for a single control on one of four banks, that's 45x4=180 abstractions. As for each abstraction contains several interdependent pattr objects which are managed by a toplevel pattrstorage, recalling presets causes lag issues. I have got into the habit of using poly~ abstractions for multiple instances where needed, despite these handling data only and no signal chains; the question I am currently targeting is whether a poly~ 45 abstraction would accelerate the process of pattr updates or if the method of chaining 45 abstractions into a bpatcher is quicker… ?? it would be quite involved to test the difference for the abstraction would have to be entirely restructured to be used with poly~. So far the parent bpatcher is comprised of 45 abstractions chained to one another to provide them with indexes and joint values, would perhaps thispoly~ and less patchcords smoothen the data process? I don't know whether I am being clear enough, I have only a year's worth of experience in Max so any hints or feedback is always welcomed.

hi everyone,
I am building a patch to manage mappings and assignments to the Livid Code controller. This involves multiple patches, each handling the settings for a single control on one of four banks, that's 45x4=180 abstractions. As for each abstraction contains several interdependent pattr objects which are managed by a toplevel pattrstorage, recalling presets causes lag issues. I have got into the habit of using poly~ abstractions for multiple instances where needed, despite these handling data only and no signal chains; the question I am currently targeting is whether a poly~ 45 abstraction would accelerate the process of pattr updates or if the method of chaining 45 abstractions into a bpatcher is quicker… ?? it would be quite involved to test the difference for the abstraction would have to be entirely restructured to be used with poly~. So far the parent bpatcher is comprised of 45 abstractions chained to one another to provide them with indexes and joint values, would perhaps thispoly~ and less patchcords smoothen the data process? I don't know whether I am being clear enough, I have only a year's worth of experience in Max so any hints or feedback is always welcomed.

poly~ instead of multiple abstractions?