Re: [PD] print all abstractions and externals
On Jul 11, 2008, at 2:24 PM, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: João Pais wrote: I meant the latest usable (which I have installed) builds of pd-extended, and the last version of pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also being unfair). I haven't being using pd too much these days for sound, but in the last builds of pd-ext I didn't notice anything that was behind pd-van. before I was using pd-van .41 because of the symbol grab feature in the data structures (which I only know about because I requested it, it's not documented). as this feature is now possible in the current build of pd-ext, I notice no differences between them. ok, but this seems to be a bit subjective evaluation. To add a rant to the subjective evaluation: For an installation I currently have to run Pd on a Mac. We chose pd-extended as it has a good integration into OS-X, and as some of the other installations that will be shown on that machine need the externals pd-extended has included. I don't need many externals, but the most important one isn't missing in pd-extended: pdlua, but as a hardcore user I could install it. But here we stumbled over another important difference between 0.40 and 0.41: EXTERN void class_set_extern_dir(t_symbol *s); was introduced to m_pd.h in 0.41, iirc. At least it's missing in 0.40. This function is used by pdlua to find lua-modules in the patch's directory instead of in the LUAPATH only, which becomes more important because it's overly complicated to start pd on OS-X (and on MS-Windows) from the command line in a certain working directory as I'm used to from Linux. Somehow I didn't manage to make the package.path trick work, which I myself suggested as a fix once on pd-list, so in the end we copied every lua-module to /usr/local/share/lua/5.1. As this installation involves 80-channel output, we also run jack, and cross our fingers that everything will hold up. In general I must say, working on the bloated OS-X is no joy for someone used to a snappy lean Linux system. If only the Fireface would support Linux... Hear, hear! I also recently had to use Mac OS X for an installation, that's why I wrote the standalone app generator. But I missed using Debian. It is so helpful to be able to uninstall every single piece of software that isn't necessary. The NY Times installation is the perfect example: it was a Linux kernel, busybox, Python and Pd. And basically nothing else :D .hc Rant end. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list All information should be free. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: João Pais wrote: I meant the latest usable (which I have installed) builds of pd-extended, and the last version of pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also being unfair). I haven't being using pd too much these days for sound, but in the last builds of pd-ext I didn't notice anything that was behind pd-van. before I was using pd-van .41 because of the symbol grab feature in the data structures (which I only know about because I requested it, it's not documented). as this feature is now possible in the current build of pd-ext, I notice no differences between them. ok, but this seems to be a bit subjective evaluation. To add a rant to the subjective evaluation: For an installation I currently have to run Pd on a Mac. We chose pd-extended as it has a good integration into OS-X, and as some of the other installations that will be shown on that machine need the externals pd-extended has included. I don't need many externals, but the most important one isn't missing in pd-extended: pdlua, but as a hardcore user I could install it. But here we stumbled over another important difference between 0.40 and 0.41: EXTERN void class_set_extern_dir(t_symbol *s); was introduced to m_pd.h in 0.41, iirc. At least it's missing in 0.40. This function is used by pdlua to find lua-modules in the patch's directory instead of in the LUAPATH only, which becomes more important because it's overly complicated to start pd on OS-X (and on MS-Windows) from the command line in a certain working directory as I'm used to from Linux. Somehow I didn't manage to make the package.path trick work, which I myself suggested as a fix once on pd-list, so in the end we copied every lua-module to /usr/local/share/lua/5.1. As this installation involves 80-channel output, we also run jack, and cross our fingers that everything will hold up. In general I must say, working on the bloated OS-X is no joy for someone used to a snappy lean Linux system. If only the Fireface would support Linux... Rant end. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
that 's an interesting idea but I don't know if this is possible with pd-vanilla, I didn't try it yet. I made this patch to be able to save all files that I need for one patch. As Luigi also noticed, it would be good if this patch searched for abstractions within abstractions, I might try this one of the following weeks (time... holidays:). I guess I'll have to save the main output in a new [textfile] object that will be printed after the searching is finished because a lot of error messages will be printed in the main screen once I try to open abstractions within abstrations (some of them will be externals which can't be opened...) I use vanilla because it's very good for teaching purposes, the structure is never hidden (as in an external where you have to be able to read the source file). I also got tired of wasting my time with looking for the right externals for windows and apple for my students, now I'm sure that everyone can use the files that I make. hans r Date: Wed, 09 Jul 2008 09:50:51 +0100 To: João Pais [EMAIL PROTECTED] From: Hans Roels [EMAIL PROTECTED] Subject: Re: [PD] print all abstractions and externals At 23:06 6/07/2008, you wrote: Hi, I would like to reply with a couple of suggestions: Have you thought about another technique? instead of making several [select]s with lots of variables (which will have to be checked now and then, as we don't know fow now which version of vanilla was your reference version), you could take on a more environment-dependent approach: pd scans the extra folder (including subfolders) for installed externals/abstractions and writes the names of the installed objects in a list (or [textfile] (or [msgfile]) ) - they're easy to find if you look for the endings .pd (abstractions), or .dll / .pd_linux / .darwin [actual non-windows extensions are wrong, I think]. That would create a personal database for each pd installation for each user (assuming that users add something to their extra folder or a user has several versions of pd installed). Then the patch-environment comparation process you already programmed would take place. Meaning, you could test quite easily if a patch you want to open has any elements your system doesn't have. One option to look automatically for objects in abstractions could be: pre-scan the patch folder (+ subfolders, if any?), and see if they come up in the results. if so, just open those files automatically afterwards. For what use did you thought the patch might be useful? I think it's quite useful if I want to make a standalone patch, which has to be packaged with the program with it - and for that vanilla+ is better as extended. But from my opinion, I don't know nowadays how many people are working with vanilla instead of with extended (except some hardcore users). I guess new users use extended, since both are now in parallel versions. As it was replied, [5] isn't wrong. for example, if [5] is triggered by another object (and not a message), it's more efficient to have [object]-[object] than [object]-[message(, as data types don't have to be converted. (as I read some years ago in this list) But if you (rightfully) don't want floats to go in your list, you can filter them out, a [route float] with no connection from the first outlet does it. (I just tried it) João Pais PS: for GUI design, I always say GOP is your friend - specially now, when you can even hide the creation name/arguments I've made a patch that might be useful for others. In the attached patch you can open a pd-file and the main window prints all the abstractions or externals that you need to make the patch work. It doesn't detect abstractions within abstractions though and it also prints objects like [5] or [$1], I didn't find a solution for this (small) problem yet. (I'd think it is bad pratice to use [5] in sted of [5( or am I wrong?) I wanted to make a patch that copied all the necessary abstractions and the file itself to a new folder but I ended up with this simpler solution... hans r -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Ubuntu GG Pd-Ext-0.39-2-t5, Pd Van 0.40-t2 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
João Pais wrote: Hi, I guess new users use extended, since both are now in parallel versions. with in parallel versions, do you mean the latest officially released versions Pd-0.41-4 vs Pd-extended-0.39.3 or not-yet released versions Pd-0.42.0-test1 vs Pd-extended-0.40-rc4? (admittedly the latter is a bit unfair, as Pd's 0.42 is imho not useable at all while PdX's release-candidate is almost there; anyhow it's not what i would call parallel versions yet) fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
with in parallel versions, do you mean the latest officially released versions Pd-0.41-4 vs Pd-extended-0.39.3 or not-yet released versions Pd-0.42.0-test1 vs Pd-extended-0.40-rc4? I meant the latest usable (which I have installed) builds of pd-extended, and the last version of pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also being unfair). I haven't being using pd too much these days for sound, but in the last builds of pd-ext I didn't notice anything that was behind pd-van. before I was using pd-van .41 because of the symbol grab feature in the data structures (which I only know about because I requested it, it's not documented). as this feature is now possible in the current build of pd-ext, I notice no differences between them. (admittedly the latter is a bit unfair, as Pd's 0.42 is imho not useable at all while PdX's release-candidate is almost there; anyhow it's not what i would call parallel versions yet) fgmasdr IOhannes -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Ubuntu GG Pd-Ext-0.39-2-t5, Pd Van 0.40-t2 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
João Pais wrote: I meant the latest usable (which I have installed) builds of pd-extended, and the last version of pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also being unfair). I haven't being using pd too much these days for sound, but in the last builds of pd-ext I didn't notice anything that was behind pd-van. before I was using pd-van .41 because of the symbol grab feature in the data structures (which I only know about because I requested it, it's not documented). as this feature is now possible in the current build of pd-ext, I notice no differences between them. ok, but this seems to be a bit subjective evaluation. by any chance, you are not running an amd64 system? (this is getting hot ground for me, as i am not so sure whether PdX actually does have some x86_64 patches incorporated; but chances are low) and you are probably also not very interested in audio-computation on demand... after all, if you don't need all the list-stuff and multiple-dollarg-expansion ($1-$2), you might as well not notice a difference between 0.39 and 0.40 gasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
I meant the latest usable (which I have installed) builds of pd-extended, and the last version of pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also being unfair). I haven't being using pd too much these days for sound, but in the last builds of pd-ext I didn't notice anything that was behind pd-van. before I was using pd-van .41 because of the symbol grab feature in the data structures (which I only know about because I requested it, it's not documented). as this feature is now possible in the current build of pd-ext, I notice no differences between them. ok, but this seems to be a bit subjective evaluation. it's not scientific at all, and I haven't been following the news. by any chance, you are not running an amd64 system? (this is getting hot ground for me, as i am not so sure whether PdX actually does have some x86_64 patches incorporated; but chances are low) my new desktop is a 64 d-core intel, I have windows and ubuntu there. it's still new, so I didn't work much with it so far. in windows works well, but I can't get ubuntu to access my quite normal home network, so I didn't got further on that. I can do some testing, if you want (just tell me what to do). and you are probably also not very interested in audio-computation on demand... my stuff isn't the most demanding in terms of cpu. I either play in my trio www.endphase.net (our patches aren't that heavy), or for my private composition tools, which in these days do more information than audio processing. I never even opened up a vst plugin in pd so far, and I'm happy with latency of 70ms in windows for now (didn't fiddled enough in ubuntu to try to bring it lower than that). after all, if you don't need all the list-stuff and multiple-dollarg-expansion ($1-$2), you might as well not notice a difference between 0.39 and 0.40 I can't even be sure of what you're talking about, so probably I don't (or maybe I would, if I was aware of it?). Were they properly documented somewhere? The one detail that made me stick to pd-van-.41 for a while was the symbol option in [struct] and the [set -symbol] feature (because of an important patch for me) - which I only know about because I asked for it (it's not documented, I think). Besides that I don't know exactly what are the benefits. But in a general remark I would say that pd-ext is making a very big step in improving the quality of the interface and its integration in the system (I speak mainly of windows) - as also with the developper community. That's an important step for users that aren't willing to make a big effort to stick with pd or have better things to do with their time [please don't bring up the if they would really want it... argument]. pd-van should check that out and try to catch up at some time as well (or just fuse into pd-ext, if there are no differences in quality - I'm not qualified to judge that). João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
João Pais wrote: by any chance, you are not running an amd64 system? (this is getting hot ground for me, as i am not so sure whether PdX actually does have some x86_64 patches incorporated; but chances are low) my new desktop is a 64 d-core intel, I have windows and ubuntu there. i was trying to say that you are obviously not trying to run a native 64bit system (with a 64bit kernel and running Pd as 64bit application) the good thing about amd64/emt64 is, that they can also run 32bit (i386). anyhow, if you want to run Pd in as a native 64bit app, you will need Pd-0.41 after all, if you don't need all the list-stuff and multiple-dollarg-expansion ($1-$2), you might as well not notice a difference between 0.39 and 0.40 I can't even be sure of what you're talking about, so probably I don't (or maybe I would, if I was aware of it?). Were they properly documented somewhere? it's not necessarily a matter of documentation (though both have been discussed on this list so many times, that at least the list-archives should serve well as documentation :-)). what i wanted to say is, that if you don't care for any _new_ feature, then it is clear that you will not see a difference between a version w/ and one lacking these features. their time [please don't bring up the if they would really want it... argument]. pd-van should check that out and try to catch up at some time i am not trying to start another religious war here. mfg.asdf IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
Great !!! Thats very helpful.. Is it diffcult to implement detecting abstractions within abstractions ??? That would be perfect Cheers Luigi Am 04.07.2008 um 13:20 schrieb Hans-Christoph Steiner: I've made a patch that might be useful for others. In the attached patch you can open a pd-file and the main window prints all the abstractions or externals that you need to make the patch work. It doesn't detect abstractions within abstractions though and it also prints objects like [5] or [$1], I didn't find a solution for this (small) problem yet. (I'd think it is bad pratice to use [5] in sted of [5( or am I wrong?) I wanted to make a patch that copied all the necessary abstractions and the file itself to a new folder but I ended up with this simpler solution... --- Luigi Rensinghoff [EMAIL PROTECTED] skype:gigischinke ichat:gigicarlo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
i was trying to say that you are obviously not trying to run a native 64bit system (with a 64bit kernel and running Pd as 64bit application) the good thing about amd64/emt64 is, that they can also run 32bit (i386). anyhow, if you want to run Pd in as a native 64bit app, you will need Pd-0.41 ah, that not yet. it should take a while until I get to that (if I do). after all, if you don't need all the list-stuff and multiple-dollarg-expansion ($1-$2), you might as well not notice a difference between 0.39 and 0.40 I can't even be sure of what you're talking about, so probably I don't (or maybe I would, if I was aware of it?). Were they properly documented somewhere? it's not necessarily a matter of documentation (though both have been discussed on this list so many times, that at least the list-archives should serve well as documentation :-)). what i wanted to say is, that if you don't care for any _new_ feature, then it is clear that you will not see a difference between a version w/ and one lacking these features. I brought the documentation up, because I'm not aware of the newest features that should make me (or anyone?) choose one version to the other (having not had to stolper on them during work). I can spend the whole afternoon looking in the list for fragments of opinios, but is that really a viable solution? you mentioned 64bit, and the other things, do you know of any place where to find a small reference about that? now I am curious. I usually update the version anyway, but more for sport than after a carefully-pondered reflexion (in the case of Pd). their time [please don't bring up the if they would really want it... argument]. pd-van should check that out and try to catch up at some time i am not trying to start another religious war here. me neither. I just see that kind of reply over and over, and I add this disclaimer now and then, just to make sure. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
João Pais wrote: you mentioned 64bit, and the other things, do you know of any place where to find a small reference about that? now I am curious. I usually update the version anyway, but more for sport than after a carefully-pondered reflexion (in the case of Pd). well, in theory it _should_ be in pd/src/notes.txt, but this is probably the worst maintained part of Pd :-( also the CHANGELOG.txt gives some wee hints (but not very satisfactory either) and generating a ChangeLog from the svn-commits helps even less. so in short, i don't know of any place where to find out what actually changed, apart from reading pd-dev, watching the sf-tracker for which patches got included by miller and diffing the code. i think that none of these options is nice. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
Hi, Yet another approach ;) I've got a suite of bash scripts that help narrow down which externals are missing. Here's a real-life-example: --8-- [EMAIL PROTECTED]:~/maximus/pdpatchinfo$ cat ../2007/d01234two/*.pd | ./objs.sh | ./externals.sh pd-0.41-4.txt | ./externals.sh Gem.txt | ./abstractions.sh ../2007/d01234two/ 0 1 analogue_adsr~ complex-mod~ expr expr~ hilbert~ #in mtx_.* mtx_diag mtx_mul #out repeat #store [EMAIL PROTECTED]:~/maximus/pdpatchinfo$ --8-- Which reminds me I need gridflow, zexy and iemmatrix to run that patch, plus some objs that are bundled with pd, and a home-brewed external. I patched one of my installed versions of Pd to print out every class registered with Pd during load time, which can then be massaged into a raw list of objects for each library (eg: Gem.txt). Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
On Tue, Jul 8, 2008 at 3:36 AM, Claude Heiland-Allen [EMAIL PROTECTED] wrote: Hi, Yet another approach ;) I've got a suite of bash scripts that help narrow down which externals are missing. Here's a real-life-example: --8-- [EMAIL PROTECTED]:~/maximus/pdpatchinfo$ cat ../2007/d01234two/*.pd | ./objs.sh | ./externals.sh pd-0.41-4.txt | ./externals.sh Gem.txt | ./abstractions.sh ../2007/d01234two/ 0 1 analogue_adsr~ Hi Claude, Speaking of analogue_adsr~, any plans to add it to Pd-E? It is my favorite envelope : ) (it's not hard for me to drop it in myself, but I bet others would like it too) Best Luke complex-mod~ expr expr~ hilbert~ #in mtx_.* mtx_diag mtx_mul #out repeat #store [EMAIL PROTECTED]:~/maximus/pdpatchinfo$ --8-- Which reminds me I need gridflow, zexy and iemmatrix to run that patch, plus some objs that are bundled with pd, and a home-brewed external. I patched one of my installed versions of Pd to print out every class registered with Pd during load time, which can then be massaged into a raw list of objects for each library (eg: Gem.txt). Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
Hi, I would like to reply with a couple of suggestions: Have you thought about another technique? instead of making several [select]s with lots of variables (which will have to be checked now and then, as we don't know fow now which version of vanilla was your reference version), you could take on a more environment-dependent approach: pd scans the extra folder (including subfolders) for installed externals/abstractions and writes the names of the installed objects in a list (or [textfile] (or [msgfile]) ) - they're easy to find if you look for the endings .pd (abstractions), or .dll / .pd_linux / .darwin [actual non-windows extensions are wrong, I think]. That would create a personal database for each pd installation for each user (assuming that users add something to their extra folder or a user has several versions of pd installed). Then the patch-environment comparation process you already programmed would take place. Meaning, you could test quite easily if a patch you want to open has any elements your system doesn't have. One option to look automatically for objects in abstractions could be: pre-scan the patch folder (+ subfolders, if any?), and see if they come up in the results. if so, just open those files automatically afterwards. For what use did you thought the patch might be useful? I think it's quite useful if I want to make a standalone patch, which has to be packaged with the program with it - and for that vanilla+ is better as extended. But from my opinion, I don't know nowadays how many people are working with vanilla instead of with extended (except some hardcore users). I guess new users use extended, since both are now in parallel versions. As it was replied, [5] isn't wrong. for example, if [5] is triggered by another object (and not a message), it's more efficient to have [object]-[object] than [object]-[message(, as data types don't have to be converted. (as I read some years ago in this list) But if you (rightfully) don't want floats to go in your list, you can filter them out, a [route float] with no connection from the first outlet does it. (I just tried it) João Pais PS: for GUI design, I always say GOP is your friend - specially now, when you can even hide the creation name/arguments I've made a patch that might be useful for others. In the attached patch you can open a pd-file and the main window prints all the abstractions or externals that you need to make the patch work. It doesn't detect abstractions within abstractions though and it also prints objects like [5] or [$1], I didn't find a solution for this (small) problem yet. (I'd think it is bad pratice to use [5] in sted of [5( or am I wrong?) I wanted to make a patch that copied all the necessary abstractions and the file itself to a new folder but I ended up with this simpler solution... hans r -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Ubuntu GG Pd-Ext-0.39-2-t5, Pd Van 0.40-t2 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
Hmm, sounds interesting. This would be useful for a better .app maker, where it only includes the files that are needed. (That would only apply on Mac OS X .app maker. The .deb maker I am working on will depend on the Pd-extended package) .hc On Jul 1, 2008, at 11:03 PM, Hans Roels wrote: hello, I've made a patch that might be useful for others. In the attached patch you can open a pd-file and the main window prints all the abstractions or externals that you need to make the patch work. It doesn't detect abstractions within abstractions though and it also prints objects like [5] or [$1], I didn't find a solution for this (small) problem yet. (I'd think it is bad pratice to use [5] in sted of [5( or am I wrong?) I wanted to make a patch that copied all the necessary abstractions and the file itself to a new folder but I ended up with this simpler solution... hans rprint-non-vanilla- objects2.pd___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
excellent! that is so useful. thanks for sharing. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] print all abstractions and externals
hello, I've made a patch that might be useful for others. In the attached patch you can open a pd-file and the main window prints all the abstractions or externals that you need to make the patch work. It doesn't detect abstractions within abstractions though and it also prints objects like [5] or [$1], I didn't find a solution for this (small) problem yet. (I'd think it is bad pratice to use [5] in sted of [5( or am I wrong?) I wanted to make a patch that copied all the necessary abstractions and the file itself to a new folder but I ended up with this simpler solution... hans r#N canvas 599 172 599 101 12; #X obj 118 144 openpanel; #X obj 116 240 textfile; #X msg 116 208 read \$1 \, rewind \, bang; #X obj 116 269 route #X; #X obj 179 297 t b; #X obj 179 324 s \$0-next; #X obj 33 144 r \$0-next; #X obj 33 173 del 4; #X obj 194 376 t b; #X obj 194 403 s \$0-next; #X obj 118 425 list split 2; #X obj 101 505 s \$0-next; #X obj 47 28 bng 15 250 50 0 \$0-start empty empty 17 7 0 10 -262144 -1 -1; #X obj 119 348 route obj; #X obj 553 1555 print; #X obj 248 488 list split 1; #X obj 173 776 select bang float symbol int send receive select route pack unpack trigger spigot moses until print makefilename change swap value delay metro line timer cputime realtime pipe; #X text 30 762 glue and time objects; #X obj 179 919 select notein ctlin pgmin bendin touchin polytouchin midiin sysexin noteout ctlout pgmout bendout touchout polytouchout midiout makenote stripnote; #X text 61 864 math objects; #X obj 180 987 select tabread tabread4 tabwrite soundfiler; #X text 64 946 midi objects; #X text 53 993 tables objects; #X obj 173 1017 select loadbang serial netsend netreceive qlist textfile openpanel savepanel bag poly key keyup keyname declare; #X text 81 1034 misc; #X text 49 1081 audio math; #X obj 172 1142 select dac~ adc~ sig~ line~ vline~ threshold~ snapshot~ vsnapshot~ bang~ samplerate~ send~ receive~ throw~ catch~ block~ switch~ readsf~ writesf~; #X text 58 1156 audio glue; #X text 66 1469 GUI; #X text 35 1599 extra folder in vanilla; #X text 49 1421 abbrevations; #X obj 46 65 tgl 15 0 \$0-extra \$0-rextra empty 17 7 0 10 -262144 -1 -1 1 1; #X text 70 64 include standard extra folder in pd-vanilla; #X text 47 1219 audio osc; #X obj 176 1208 select phasor~ cos~ osc~ tabwrite~ tabplay~ tabread~ tabread4~ tabosc4~ tabsend~ tabreceive~; #X obj 173 1257 select vcf~ noise~ env~ hip~ lop~ bp~ biquad~ samphold~ print~ rpole~ rzero~ rzero_rev~ cpole~ czero~ czero_rev~; #X obj 167 1314 select delwrite~ delread~ vd~ pd table inlet outlet inlet~ outlet~; #X text 41 1320 audio delay; #X text 42 1333 subwindows; #X text 41 1273 audio filters; #X text 38 1370 data templates; #X text 37 1387 accesing data; #X text 53 1405 obsolete; #X obj 187 1467 select bng tgl nbx vsl hsl vradio hradio vu cnv; #X msg 557 1530 \$1; #X obj 286 321 print; #X obj 324 233 print; #X obj 135 171 t s s; #X msg 322 206 ---start-searching-\$1; #X msg 287 295 ---end-searching--; #X obj 227 1579 select expr expr~ fexpr~ rev3~ rev2~ rev1~ hilbert~ complex-mod~ sigmund~ pique lrshift~ loop~ fiddle~ choice bonk~; #X obj 638 1437 r \$0-extra; #X obj 489 1504 spigot; #X obj 555 1505 spigot; #X obj 642 1671 print; #X msg 646 1645 \$1; #X obj 633 1466 == 0; #X obj 408 380 loadbang; #X msg 408 407 1; #X obj 410 434 s \$0-rextra; #X text 74 26 open pd-file; #X obj 125 115 r \$0-start; #X obj 165 1071 select +~ -~ *~ /~ max~ min~ clip~ q8_rsqrt~ q8_sqrt~ wrap~ fft~ ifft~ rfft~ rifft~ framp~ mtof~ ftom~ rmstodb~ dbtorms~ rmstopow~ powtorms~ sqrt~ rsqrt~; #X obj 172 848 select + - * / pow == != = = | || % mtof powtodb rmstodb ftom dbtopow dbtorms mod div sin cos tan atan atan2 sqrt log exp abs random max min clip; #X symbolatom 25 463 10 0 0 0 - - -; #X obj 29 398 print one; #X text 18 446 controle test; #X obj 248 523 select list; #X msg 247 550 1; #X msg 293 553 0; #X obj 248 624 spigot; #X obj 203 590 == 0; #X obj 159 620 spigot; #X obj 200 454 t b a a; #X obj 171 654 list split 1; #X obj 301 649 list split 2; #X obj 333 675 list split 1; #X obj 689 763 print; #X obj 380 706 select split append prepend trim length; #X msg 693 737 list \$1; #X text 265 146 !!objects like [\$1 \$2] or [2]; #X text 363 508 filter out the list objects (2 words!); #X obj 176 1367 select struct drawcurve filledcurve drawpolygon filledpolygon plot drawnumber pointer get set element getsize setsize sublist namecanvas template; #X obj 181 1424 select b f i s r t sel del v r~ s~; #X connect 0 0 47 0; #X connect 1 0 3 0; #X connect 1 1 49 0; #X connect 2 0 1 0; #X connect 3 0 13 0; #X connect 3 1 4 0; #X connect 4 0 5 0; #X connect 6 0 7 0; #X connect 7 0 1 0; #X connect 8 0 9 0; #X connect 10 1 73 0; #X connect 13 0 10 0; #X connect 13 1 8 0; #X connect 15 0 67 0; #X connect 16 26 63 0; #X connect 18 17 20 0; #X connect 20 4 23 0; #X connect 23 14 62 0; #X connect 26 18 34 0; #X connect 34 10 35 0; #X connect 35 15 36 0; #X connect 36 9 82 0; #X connect 43 9 52
Re: [PD] print all abstractions and externals
On Tue, 1 Jul 2008, Hans Roels wrote: or [$1], I didn't find a solution for this (small) problem yet. (I'd think it is bad pratice to use [5] in sted of [5( or am I wrong?) [5] is not a replacement for [5(, it's an alias for [f 5]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
