Well, one simple trick is to have pd-vanilla installed on another machine (or a virtual machine). This will be the test environment, a neutral one with just pd-vanilla. Prepare your folder with Main patch and abstractions. Open it in the other/virtual machine. You will get the console with a lot of messages alla “pink~ couldn't create”. There you get the list of all things needed. Then work out everything until there's no more “couldn't create ..” You can collect all needed abstractions in a folder say “absz” an use [declare -path absz] and also collect all externals in “extz” and use [declare -path extz] or the same with lots of folders to include the licences i.e “extz/cyclone” (-path extz/cyclone) and the same for other externals which is more correct. This also allows to include externals compiled for the 3 Os. Simply extract the 3 zips of “cyclone” and unify their content in one cyclone folder. (if you want you can exclude the binaries that you don`t need) If more you need more in depth let me know.

Mensaje telepatico asistido por maquinas.

From: williamahuston@gmail.com Date: Mon, 6 Jun 2016 22:02:17 -0400 Subject: Re: [PD] Determine library dependency tree for a patch? To: lucarda27@hotmail.com CC: pd-list@lists.iem.at

Yes, my plan is to include whatever abstractions in my own libraries. But I do not know what those dependencies are!! That is the problem.

My goal is to have a script or program which can a) examine an arbitrary patch, (example: "BillsPatch.pd") and b) examine my Pd runtime environment

... and build a dependency tree. Something like this:

$ perl ShowPdDependencyTree.pl BillsPatch.pd

BillsPatch.pd |--------/home/bh/pd/abstractions/BillVerb~.pd | ---------- /home/bh/pd/pd-0.43.4-extended/extra/freeverb.ld |--------/home/bh/pd/abstractions/flanger~.pd | ---------------/home/bh/pd/abstractions/autophase12~.pd | ---------------/home/bh/pd/abstractions/autopan12~.pd | ---------- /home/bh/pd/pd-0.43.4-extended/extra/flatgui/knob.ld |--------/home/bh/pd/abstractions/MultiOsc~.pd | ..... (etc.)......

Make sense? I want this to be able to work anywhere why Pd works (OSX, Windows, Linux).

Thanks, BH

On Mon, Jun 6, 2016 at 9:30 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:

Hi William, You can include all the externals that you need in your distribution. You know that pd-vanilla will be there and you supply a folder (probably with sub-folders) with all externals (for all platforms if needed). Then you simply use [declare] That`s it. You can download the zips of the externals with deken or from puredata.info. Hope this helps,If you need more clarification on how to do this write back. Or you are trying to do something that I don't understand. Salutti,Lucarda. Mensaje telepatico asistido por maquinas.

From: williamahuston@gmail.com Date: Mon, 6 Jun 2016 16:52:32 -0400 To: pd-list@lists.iem.at Subject: [PD] Determine library dependency tree for a patch?

My idea is, I want to distribute a patch.

But I build my patches with layers of abstractions.

So I want to make a recursive map of the dependency tree, including any external libraries needed, so I can know what needs to be included when I distribute the patch.

Has anyone tried this?

I will probably do this with an external program, probably Perl (not within Pd).

First it seems I really need to understand how to Pd does conflict resolution in case of name clashes.

Next, it seems one must know the search path.

This is a bit easier on Linux systems b/c it just requires parsing a flat file.

On Windows it requires parsing the Registry (which I admit is still a big mystery for me).

On My machine, I am finding the search path here:

HKEY_USERS\S-1-5-21-1970324843-3388967453-2642309065-1000\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Pd\

npath=12 means 12 directories to search, each being path1=(path1) path2=(path2) ... path12=(path12)

I also find this repeated here:

HKEY_USERS\S-1-5-21-1970324843-3388967453-2642309065-1000_Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Pd One question is, where does this strange string come from? Is this guaranteed to be the same on every Windows systems?

S-1-5-21-1970324843-3388967453-2642309065-1000 S-1-5-21-1970324843-3388967453-2642309065-1000_Classes

Ugh. Anyway, just looking for some general guidance here.

Thanks, BH

Why guesswork? -> file search, Why 2 machines? –> virtual machine. AnywayGood luck! Mensaje telepatico asistido por maquinas.

From: williamahuston@gmail.com Date: Mon, 6 Jun 2016 23:38:51 -0400 Subject: Re: [PD] Determine library dependency tree for a patch? To: lucarda27@hotmail.com CC: pd-list@lists.iem.at

Lucas, I thought about your method, but it potentially involves several iterations and guesswork, and two machines.

I appreciate the help, but the method I want to pursue is the one I described.

I'll bet someone has already done this...

BH

On Mon, Jun 6, 2016 at 11:32 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:

Well, one simple trick is to have pd-vanilla installed on another machine (or a virtual machine). This will be the test environment, a neutral one with just pd-vanilla. Prepare your folder with Main patch and abstractions. Open it in the other/virtual machine. You will get the console with a lot of messages alla “pink~ couldn't create”. There you get the list of all things needed. Then work out everything until there's no more “couldn't create ..” You can collect all needed abstractions in a folder say “absz” an use [declare -path absz] and also collect all externals in “extz” and use [declare -path extz] or the same with lots of folders to include the licences i.e “extz/cyclone” (-path extz/cyclone) and the same for other externals which is more correct. This also allows to include externals compiled for the 3 Os. Simply extract the 3 zips of “cyclone” and unify their content in one cyclone folder. (if you want you can exclude the binaries that you don`t need) If more you need more in depth let me know.

Mensaje telepatico asistido por maquinas.

From: williamahuston@gmail.com Date: Mon, 6 Jun 2016 22:02:17 -0400 Subject: Re: [PD] Determine library dependency tree for a patch? To: lucarda27@hotmail.com CC: pd-list@lists.iem.at

Yes, my plan is to include whatever abstractions in my own libraries. But I do not know what those dependencies are!! That is the problem.

My goal is to have a script or program which can a) examine an arbitrary patch, (example: "BillsPatch.pd") and b) examine my Pd runtime environment

... and build a dependency tree. Something like this:

$ perl ShowPdDependencyTree.pl BillsPatch.pd

BillsPatch.pd |--------/home/bh/pd/abstractions/BillVerb~.pd | ---------- /home/bh/pd/pd-0.43.4-extended/extra/freeverb.ld |--------/home/bh/pd/abstractions/flanger~.pd | ---------------/home/bh/pd/abstractions/autophase12~.pd | ---------------/home/bh/pd/abstractions/autopan12~.pd | ---------- /home/bh/pd/pd-0.43.4-extended/extra/flatgui/knob.ld |--------/home/bh/pd/abstractions/MultiOsc~.pd | ..... (etc.)......

Make sense? I want this to be able to work anywhere why Pd works (OSX, Windows, Linux).

Thanks, BH

On Mon, Jun 6, 2016 at 9:30 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:

Hi William, You can include all the externals that you need in your distribution. You know that pd-vanilla will be there and you supply a folder (probably with sub-folders) with all externals (for all platforms if needed). Then you simply use [declare] That`s it. You can download the zips of the externals with deken or from puredata.info. Hope this helps,If you need more clarification on how to do this write back. Or you are trying to do something that I don't understand. Salutti,Lucarda. Mensaje telepatico asistido por maquinas.

From: williamahuston@gmail.com Date: Mon, 6 Jun 2016 16:52:32 -0400 To: pd-list@lists.iem.at Subject: [PD] Determine library dependency tree for a patch?

My idea is, I want to distribute a patch.

But I build my patches with layers of abstractions.

So I want to make a recursive map of the dependency tree, including any external libraries needed, so I can know what needs to be included when I distribute the patch.

Has anyone tried this?

I will probably do this with an external program, probably Perl (not within Pd).

First it seems I really need to understand how to Pd does conflict resolution in case of name clashes.

Next, it seems one must know the search path.

This is a bit easier on Linux systems b/c it just requires parsing a flat file.

On Windows it requires parsing the Registry (which I admit is still a big mystery for me).

On My machine, I am finding the search path here:

HKEY_USERS\S-1-5-21-1970324843-3388967453-2642309065-1000\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Pd\

npath=12 means 12 directories to search, each being path1=(path1) path2=(path2) ... path12=(path12)

I also find this repeated here:

HKEY_USERS\S-1-5-21-1970324843-3388967453-2642309065-1000_Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Pd One question is, where does this strange string come from? Is this guaranteed to be the same on every Windows systems?

S-1-5-21-1970324843-3388967453-2642309065-1000 S-1-5-21-1970324843-3388967453-2642309065-1000_Classes

Ugh. Anyway, just looking for some general guidance here.

Thanks, BH

Seems to me like you'd want some kind of script to parse your Pd patch, iteratively look through all the objects declared and look for them in pre-defined search paths.

I'm not 100% on what the hierarchy is in Pd, but probably start with paths added by [declare -path], relative sub directories, global user defined paths in Pd, and the normal Pd extern folder?

You'll probably want to compile a list of internal objects to check against as well.

On 7 June 2016 at 10:43, Frank Barknecht fbar@footils.org wrote:

On Mon, Jun 06, 2016 at 10:02:17PM -0400, William Huston wrote:

...

Yes, my plan is to include whatever abstractions in my own libraries. But I do not know what those dependencies are!! That is the problem.

My goal is to have a script or program which can a) examine an arbitrary patch, (example: "BillsPatch.pd") and b) examine my Pd runtime environment

... and build a dependency tree. Something like this:

Maybe for starters you can start with Pd itself in a shell-like script and examine its output? With "-verbose" you get explicit error lines for every object missed and found like this:

$ pd -stderr -noprefs -verbose somepatch.pd [...] tried /tmp/somepatch.pd and succeeded tried /tmp/a/in-b.l_ia64 and failed tried /tmp/b/in-b.l_ia64 and failed tried /tmp/in-b.l_ia64 and failed tried /home/fbar/pd-externals/in-b.l_ia64 and failed tried /usr/local/lib/pd-externals/in-b.l_ia64 and failed tried /usr/lib/puredata/extra/in-b.l_ia64 and failed tried /usr/lib/pd/extra/in-b.l_ia64 and failed [...] tried /usr/lib/pd/extra/in-b/in-b.pd_linux and failed tried /tmp/a/in-b.pd and failed tried /tmp/b/in-b.pd and succeeded

Look for all "tried ... and succeeded" lines and extract the path or file.

When testing if you have everything copyied, use "-noprefs" as well to ignore your own preferences.

Ciao

Frank Barknecht _ ______footils.org__

---

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