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
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
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
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
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
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
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 timei 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.
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
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__
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
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<-- claude@minimus:~/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 claude@minimus:~/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
On Tue, Jul 8, 2008 at 3:36 AM, Claude Heiland-Allen claudiusmaximus@goto10.org 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<-- claude@minimus:~/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 claude@minimus:~/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
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
João Pais -
Luke Iannini