As apology, I offer my humility: 10 hours-straight work later, I know some of what i thought of is beyond my knowledge limit and capacity to continue working on.

That all being said,...

My idea (which I thought would be Very simple, yet learned that PD, no matter how sweet She is, does not behave like the linux shell) was simple:

Make a rack of a set of vradios (i chose 8 due to the cpu limit on my laptop, but more could easily be added) which each denote a set of effects;

Send the results to a shell control along with the "slot" in the stack;

Have it copy that effect into an eff(ects)/tmp folder (mapping over the dummy files that were there),

so when the adc~ > eff1 > eff2, etc., chain runs they would be loaded as copies of the desired effects abstractions.

My intention was to empower the usage of multiple instances of the same effects abstractions as well as cut the wiring required in many/my pedal rack/s I have seen to almost nil.

That Was accomplished.

And I DO like the "idea".

On the other hand, I learned, to my chagrin, 2 VERY important lessons:

1. pd loads all subpatches on startup
   and
2. there is no (this is were I bow to higher minds than myself) way to "refresh" the patch, shy of closing and reopening it (because while you can do this sort of thing in linux, you can not in pd "underwrite" a subpatch and presume it will know the change has been made).

I Did pursue trying to load via "cat" the effect file-contents into a pd (sub)patch object, but could not figure out how to make that work, even with subtracting the file accouterments, i.e.#X, #N.

In closing I will say that the goal, though only partially achieved, IS one worth pursuing if it is a domain you are more knowledgeable about than myself.

I have attached a zip of my work.

It includes:

a shell script to start extended (it must be started this way, if the shell object is to know where the resource folder is located;

a folder, "res", which includes: /effs (where you put your effects abstractions), /effs_tmp (with 8 dummy files, where your effs get copied to), and /helper (where Mother is located)

and

a Mother_effsmap.txt file, where you list your effects, by filename (including the ".pd" extension", which it cross-references the vradio index to the line number on the file to know which file to copy.

Also,
I have found that it does copy correctly, but then you are left with the stack of controls to contend with. But I have yet to figure that out and think it better to go ahead and share it.

-peace, thanks for listening, and I hope it gives you some new ideas to work with.

svanya

Mother.zip

Thanks, for getting back with me, heyok.

I checked out the info/patches you sent, and while being very, very useful information, what the loadbangs do does not actually fulfill what I need.

But a picture (see below) is much more representative of what's involved than what I said before and in the ensuing 24 hours I have learned a lot about this facet of pd, and at least, though bad, one way to resolve the "problem".

You might be able to tell from the picture, that what I am doing, and have asked pure data to bend over backwards to resolve, is only access the file when it is needed. Which I have found it Does and perhaps can't do.

The technique I am using which has dropped my cpu load 5 fold, is using a cache/directory of abstraction, if you will "classes". So when the patch is in rest position it has empty abstractions (holders of just inlets straight to outlets) as /effs_tmp/eff1~, /effs_tmp/eff2~, etc.

Then when the user clicks the vradio, it tells the shell to make a copy of the class effect and copy it from, for instance, /effs/chorus~ onto /effs_tmp/eff1, 2, 3, etc.

I had thought, mistakenly and I guess naively, pd only accessed its abstractions when they were being called.

But it does not. It loads them all on "open". So while a loadbang message updates the variables/parameters within its patche, subpatch, and abstrations, it already has them all in memory, so only updates their values and does not reload/first-load the patch.

I thought it might seek them out (so I could sneak in under the table and rewrite the file without it knowing) so each time it went to access the file it would have an entirely new file. (Which in the shell is a very common thing, for me atleast to do.)

The Fix:

This rewiring in the background Does work, and will allow for multiple/indefinite instances of an abstractin (in part. since I have gone in and rewired all the class abstractions so both the classess and objects point to one joint folder at the same level as /effs and /effs_tmp, but in a different directory called /helpers.

This would be such a great thing for pd to be able to do, or at least add as an option in onload: "static load" or "dynamic load" perhaps.

In the meantime, I will just continue, to build the racks (and save them since I have added a presets control), and close/reopen to instantiate them.

Thanks again for your help. I DO really appreciate it and what you taught me is Sure to prove useful in the future.

-peace and thank you, for being so helpful. It was what I am continuing to praise this forum's users for here and abroad.

Sincerely,
svanya

Peace.

In that regard, I sought out a dropdown box to replace the grid and found "popup, a popup menu for PD. Copyright Ben Bogart 2004, 2005 Released under the GPL."

So I consolidated that ugly grid into a cool, synced dropdown box where you pick a slot, then an effect type and an effect from the autoloaded popup menu. Much cleaner and smaller (see below).

I over-wholeheartedly agree:

It's comforting to know that what we do Not know today we may someday.

Peace and good cheer to you and yours.

Sincerely,
-svanya