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 object
6. 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



--
a.


_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list