I think this can be done with Pd-l2ork. [find(|[canvasinfo] This will return a list of pointers to all the objects on the parent canvas. For each one you can send the pointer to the right inlet of [objectinfo] and do this: [class(|[objectinfo] I also have [classinfo]. Now, there's a special "objectmaker" class in Pd that has a method for each "creator" symbol for every loaded Pd class. I have a method for returning those methods, though I can't remember what it is atm and I'm not in front of a machine running Pd.
Putting that altogether, you can:1. Run Pd-l2ork with no externals loaded, and walk the "objectmaker" methods using [classinfo]. This will give you a list of symbols that are essentially the class names and aliases for "core" Pd. (Plus some other stuff that we can ignore for the moment.)2. Save that list of symbols in an abstraction.3. Run Pd-l2ork with all externals loaded, and load an arbitrary patch.4. Use [find(---[canvasinfo1] inside your abstraction to get a list of the objects on the parent.5. Use [class(--[objectinfo] to get the class of each object6. Compare that class to your list of "core" classes from #1 above. If it matches it's a "core" object. If not, it's an external. Caveats:1. For Pd Vanilla objects, you probably need to manually prune the internal objects that have been added in Pd-l2ork-- preset_hub, preset_node, and my introspection classes above.2. I can't remember if I have a way to drill down into a subpatch or abstraction with [canvasinfo]. But I can add that. 3. For externals that try to override internal objects, all bets are off. (But there may be a way to check for that, too.) I'll try coding it up later. -Jonathan
On Monday, February 29, 2016 9:46 AM, Alessio Degani via Pd-list <pd-list@lists.iem.at> wrote:
On 29/02/2016 12:11, cyrille henry wrote:
Le 28/02/2016 20:25, Alessio Degani via Pd-list a écrit :
Hi Cyrille,
On 28/02/2016 14:14, cyrille henry wrote:
this is certainly possible, if someone spend time working on this. but my concern is : why is this important?
i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.
but if you do care about conservation or portability, then load pd with only a minimal set of externals, and "declare" the other only when you need them.
I do care of both. I've used to write my patch with pd-extended, that eliminates the problem "from the root".
pd-extended did not solve this problem: pd-extended create this problem!
Again, I totally agree with you! :)
In this way my patch will work (almost) certainly with pd-extended across each platform and from now on.
But I've decided to abandon extended for all the reason that we all know :) The problem, now, is:
- If I want to distribute my patch, it would be great to write down
the dependencies, for example in the README. And virtually, since I've used to work with pd-extended, I've in some way "lost" the border within vanilla objects and extended objects, so I've to manually check each time (i.e.: hummm spigot~ is vanilla? NO, ok... let me check... oh ok... is in the unathorized package -> each time for each object).
- I use different machines with different OS, etc... and sometimes I
use "fresh" pd vanilla installation. Ideally, I want to install only the externals that I need. If I have a list of externals needed for my patch, this process would be much more easy (few clicks with Deken)!
i think you should first reduce number of external you need : spigot~ can be certainly be replace with a *~...
Yes, I'm going to proceed this way in order to reduce the number of abstraction. That's the way I've used to work before starting to use pd-extended. I prefer to implement the object as abstraction by myself, but pd-extended has spoiled me :) I guess that I will have to do a lot of work in vanilla-izing all my old patches.
Anyway, I think that a method to "attach" a list of "used externals" to a given patch would be useful!
Cheers
you can replace lot's of externals using abstractions. that's a lot of work, but your patchs will be lot's more portable.
cheers c
So, my advice is : better than making a mess and try to fix it latter, it's easier to make things clean in the 1st time.
I totally agree with this! :)
Cheers
cheers c
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list