This is a list of some of the error messages that I received using the most recent test build of Pd-extended, using a G4 Powerbook with OSX 10.4.6.
- iemmatrix library does not load
e.g. when trying the cylinderExample.pd file for the shapeSynth abstraction:
load_object: Symbol "mtx_-_setup" not found load_object: Symbol "setup_mtx_0x2d" not found mtx_- ... couldn't create load_object: Symbol "mtx_+_setup" not found load_object: Symbol "setup_mtx_0x2b" not found mtx_+ ... couldn't create error: inlet: expected '' but got 'matrix' ... you might be able to track this down from the Find menu. error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix'
- when trying the formantdynwav.pd from creb examples:
onecomp~ ... couldn't create fdn: maximum nb of delay lines 8, total buffer size 65536 samples (1.486077 seconds)
- when trying to use the tbEnvify~-help.pd patch in abstractions/tb
I could not load the assert abstraction, nor the !- abstraction.
- when trying the examples/hid/mouse-tracker.pd I get this message
in the terminal: mouse ... couldn't create grid: version 0.6, written by Yves Degoyon (ydegoyon@free.fr) error: inlet: expected '' but got 'open'
- when trying the examples/hid/polar_joystick.pd I get this message
in the terminal: joystick 3 ... couldn't create hid_invert ... couldn't create hid_cube ... couldn't create expr, expr~, fexpr~ version 0.4 under GNU General Public License hid_polar ... couldn't create hid_log ... couldn't create error: inlet: expected '' but got 'open'
- when trying the examples/hid/spiral_joystick.pd I get this message
in the terminal: hid_invert ... couldn't create hid_cube ... couldn't create hid_spiral ... couldn't create joystick 3 ... couldn't create error: inlet: expected '' but got 'open'
- trying examples/gyre/gyre.pd yields:
gyre.stereoloop~ loop1 ... couldn't create gyre.stereoloop~ loop2 ... couldn't create gyre.stereoloop~ loop3 ... couldn't create gyre.stereoloop~ loop4 ... couldn't create gyre.stereoloop~ loop5 ... couldn't create gyre.stereoloop~ loop6 ... couldn't create
- trying examples/ix/nob-demo yields:
beware! this is widget 0.1, 19th alpha build... warning (Widget): no file 'setup.wid'... using built-in defaults beware! this is tot 0.1, 19th alpha build... error: makefilename: no method for 'bg' widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details
In fact, all of the ix library does not work. There are probably more, but I have limited internet access right now, so these are all I've recorded for the moment during my useage.
~Kyle
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
ok,
...see if ya notice a pattern here:
On Jul 16, 2006, at 5:54 PM, Kyle Klipowicz wrote:
- iemmatrix library does not load
e.g. when trying the cylinderExample.pd file for the shapeSynth
abstraction:load_object: Symbol "mtx_-_setup" not found load_object: Symbol "setup_mtx_0x2d" not found mtx_- ... couldn't create
[iemmatrix/mtx_add], [iemmatrix/mtx_sub], etc..
- when trying the formantdynwav.pd from creb examples:
onecomp~ ... couldn't create
...not all of the creb externals are included atm...
- when trying to use the tbEnvify~-help.pd patch in abstractions/tb
I could not load the assert abstraction, nor the !- abstraction.
...hmm, dunno about this...
- when trying the examples/hid/mouse-tracker.pd I get this message
in the terminal: mouse ... couldn't create
[hid/mouse]
- when trying the examples/hid/polar_joystick.pd I get this message
in the terminal: joystick 3 ... couldn't create
[hid/joystick]
- when trying the examples/hid/spiral_joystick.pd I get this message
in the terminal: hid_invert ... couldn't create
[hid/spiral_joystick]
- trying examples/gyre/gyre.pd yields:
gyre.stereoloop~ loop1 ... couldn't create
[gyre/gyre.stereoloop~]
- trying examples/ix/nob-demo yields:
beware! this is widget 0.1, 19th alpha build... warning (Widget): no file 'setup.wid'... using built-in defaults beware! this is tot 0.1, 19th alpha build... error: makefilename: no method for 'bg' widget's error: creation failure see standard error for details
In fact, all of the ix library does not work. There are probably more, but I have limited internet access right now, so these are all I've recorded for the moment during my useage.
- hmm...ix's stuff often requires either tcl/tk 8.5 or extra
tcllibs, which aren't (yet) distributed in pd_extended...
james
Hallo, james tittle hat gesagt: // james tittle wrote:
...see if ya notice a pattern here:
The pattern may be, that in Pd-extended objects additionaly have different names than those, their developers gave them. I know why this is so (namespaces etc.) but with externals and abstractions developed outside of Pd-extended such things will happen.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jul 17, 2006, at 2:47 AM, Frank Barknecht wrote:
Hallo, james tittle hat gesagt: // james tittle wrote:
...see if ya notice a pattern here:
The pattern may be, that in Pd-extended objects additionaly have different names than those, their developers gave them. I know why this is so (namespaces etc.) but with externals and abstractions developed outside of Pd-extended such things will happen.
...yeh, I'm not passing judgement on this one way or the other, it
simply is (but isn't mentioned in, say, the Readme.html?), and
definitely a loose-end, at that...
james
Hallo, james tittle hat gesagt: // james tittle wrote:
On Jul 17, 2006, at 2:47 AM, Frank Barknecht wrote:
Hallo, james tittle hat gesagt: // james tittle wrote:
...see if ya notice a pattern here:
The pattern may be, that in Pd-extended objects additionaly have different names than those, their developers gave them. I know why this is so (namespaces etc.) but with externals and abstractions developed outside of Pd-extended such things will happen.
...yeh, I'm not passing judgement on this one way or the other, it
simply is (but isn't mentioned in, say, the Readme.html?), and
definitely a loose-end, at that...
It is a loose end. For example, my collection of list abstractions is installed in a directory called "list-abs" in CVS and in pd-extended. I've seen some people use e.g. list-drip.pd like [list-abs/list-drip] now, which not only is ugly because of the double "list", but also creates problems for users, who don't have the directory above "list-abs" in their path. "list-abs" actually was never intended to be a namespace prefix, it's just the name of this collection (the actual name is "[list]-abs" to be really obsessed.) The real, old-style namespace prefix is the "list-" in the name of every abstraction included there. Many other older collections work like this, while others do not.
If [list]-abs would get a directory prefix, it should be something like "list" and the "list-" in the abstraction name should be dropped, so only "list/drip" remains. But then one would *have* to use it like that, otherwise it would nameclash with Zexy's [drip] and a lot of the other list-objects in my collection would clash with other objects as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jul 17, 2006, at 9:44 AM, Frank Barknecht wrote:
Hallo, james tittle hat gesagt: // james tittle wrote:
On Jul 17, 2006, at 2:47 AM, Frank Barknecht wrote:
Hallo, james tittle hat gesagt: // james tittle wrote:
...see if ya notice a pattern here:
The pattern may be, that in Pd-extended objects additionaly have different names than those, their developers gave them. I know why this is so (namespaces etc.) but with externals and abstractions developed outside of Pd-extended such things will happen.
...yeh, I'm not passing judgement on this one way or the other, it simply is (but isn't mentioned in, say, the Readme.html?), and definitely a loose-end, at that...
It is a loose end. For example, my collection of list abstractions is installed in a directory called "list-abs" in CVS and in pd-extended. I've seen some people use e.g. list-drip.pd like [list-abs/list-drip] now, which not only is ugly because of the double "list", but also creates problems for users, who don't have the directory above "list-abs" in their path. "list-abs" actually was never intended to be a namespace prefix, it's just the name of this collection (the actual name is "[list]-abs" to be really obsessed.) The real, old-style namespace prefix is the "list-" in the name of every abstraction included there. Many other older collections work like this, while others do not.
If [list]-abs would get a directory prefix, it should be something like "list" and the "list-" in the abstraction name should be dropped, so only "list/drip" remains. But then one would *have* to use it like that, otherwise it would nameclash with Zexy's [drip] and a lot of the other list-objects in my collection would clash with other objects as well.
There are no classes that have different names in Pd-extended AFAIK.
There are namespaces, which aren't part of the class name, but can be
part of the name of an instantiated object. In terms of the "list-
abs" library, its your library, call it whatever you want. I just
took the name from CVS since almost all libs in CVS are in a folder
with the same name as the library.
As for the [list command] syntax, I think its a bad kludge. Its
inconsistent with the rest of Pd while providing no benefits.
Everywhere else, the second atom in an object box is an argument.
Classname prefixes like "list-", "gem_", "cxc_", etc. are deprecated
and ugly in my opinion. Can we all agree on that at least?
.hc
http://at.or.at/hans/
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There are no classes that have different names in Pd-extended AFAIK.
There are namespaces, which aren't part of the class name, but can be
part of the name of an instantiated object. In terms of the "list- abs" library, its your library, call it whatever you want. I just
took the name from CVS since almost all libs in CVS are in a folder
with the same name as the library.
No problem, it's okay the way it is. IIRC I wrote the Makefile-installation for list-abs myself. My problem only occurs if someone uses list-abs-abstractions without "loading" the library using -path or -libdir, because using an arbitrary prefix is inconsistent with the documentation, help- and example-patches and it will break right-click help on systems without libdir patch.
Classname prefixes like "list-", "gem_", "cxc_", etc. are deprecated and ugly in my opinion. Can we all agree on that at least?
Not quite yet. But as soon as your libdir-patch is in main Pd, I would agree. From an aesthetic point of view, "list/drip" is on the same level of ugliness as "list-drip", however. And in most cases omiting the prefix - be it a directory or a filename prefix - makes no sense for list-abs anyway as many intentionally mimick builtin objects like list-makefilename etc. These won't work without some kind of prefix. (Gridflow's "#" is a similar case.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 17 Jul 2006, Frank Barknecht wrote:
Classname prefixes like "list-", "gem_", "cxc_", etc. are deprecated and ugly in my opinion. Can we all agree on that at least?
Hans, I agree that it is your opinion.
Not quite yet.
More like: never.
But as soon as your libdir-patch is in main Pd, I would agree.
Why?
From an aesthetic point of view, "list/drip" is on the same level of ugliness as "list-drip",
Which may mean that neither is ugly? unless you try importing "list/drip"? when one is not importing, both namings are pretty equal, except that the former enforces the use of a directory or symlink.
If you really want something ugly, try "list/list-drip".
And in most cases omiting the prefix - be it a directory or a filename prefix - makes no sense for list-abs anyway as many intentionally mimick builtin objects like list-makefilename etc. These won't work without some kind of prefix. (Gridflow's "#" is a similar case.)
Exactly. This is using analogy as a mnemotechnic device: if one can't put both similar behaviours in one class, the next best thing is to use naming that is similar and predictable.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 17 Jul 2006, Frank Barknecht wrote:
Classname prefixes like "list-", "gem_", "cxc_", etc. are deprecated and ugly in my opinion. Can we all agree on that at least?
Hans, I agree that it is your opinion.
Not quite yet.
More like: never.
But as soon as your libdir-patch is in main Pd, I would agree.
Why?
See my other mail for my reasoning. I wouldn't deprecate class-/filename prefixes or call them more ugly than directory prefixes, but in general I don't care how prefixes are implemented or used. My problem is with abstractions not being completely prepared for directory prefixes in main Pd because of help-path issues. Basically that's why I dropped the idea to use a directory prefix for rradical two years ago, the remains are here: http://footils.org/cms/show/22
However once the help-file issue is sorted out, using directories makes installing and moving and deleting collections of externals and abstractions much easier. You don't want list-abs? Just delete the directory. You have your own "list/*" collection? Just rename mine to "list-foobar" and use "list-foobar/drip". From a maintainer's point of view directories have a lot of advantages. But they are nothing special when it comes to resolving name clashes, because as I see it they don't do much that wouldn't be possible with file- or classname prefixes as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jul 18, 2006, at 3:43 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 17 Jul 2006, Frank Barknecht wrote:
Classname prefixes like "list-", "gem_", "cxc_", etc. are
deprecated and ugly in my opinion. Can we all agree on that at least?Hans, I agree that it is your opinion.
Not quite yet.
More like: never.
But as soon as your libdir-patch is in main Pd, I would agree.
Why?
See my other mail for my reasoning. I wouldn't deprecate class-/filename prefixes or call them more ugly than directory prefixes, but in general I don't care how prefixes are implemented or used. My problem is with abstractions not being completely prepared for directory prefixes in main Pd because of help-path issues. Basically that's why I dropped the idea to use a directory prefix for rradical two years ago, the remains are here: http://footils.org/cms/show/22
With the libdir setup, there is a simple workaround for this problem:
add "extra" to the help path. It would just cause problems if there
are help files directly in "extra", which there shouldn't be.
However once the help-file issue is sorted out, using directories makes installing and moving and deleting collections of externals and abstractions much easier. You don't want list-abs? Just delete the directory. You have your own "list/*" collection? Just rename mine to "list-foobar" and use "list-foobar/drip". From a maintainer's point of view directories have a lot of advantages. But they are nothing special when it comes to resolving name clashes, because as I see it they don't do much that wouldn't be possible with file- or classname prefixes as well.
Supporting every layout possibility and naming scheme under the sun
creates a lot more work. I think we have a lot to gain by
standardizing these things, then we can spend that effort on more
interesting things. If you look at the study of usability, you'll
find that consistency is a key concept. Pd could use a lot more
consistency.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Jul 17, 2006, at 1:52 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There are no classes that have different names in Pd-extended AFAIK. There are namespaces, which aren't part of the class name, but can be part of the name of an instantiated object. In terms of the "list- abs" library, its your library, call it whatever you want. I just took the name from CVS since almost all libs in CVS are in a folder with the same name as the library.
No problem, it's okay the way it is. IIRC I wrote the Makefile-installation for list-abs myself. My problem only occurs if someone uses list-abs-abstractions without "loading" the library using -path or -libdir, because using an arbitrary prefix is inconsistent with the documentation, help- and example-patches and it will break right-click help on systems without libdir patch.
Classname prefixes like "list-", "gem_", "cxc_", etc. are deprecated and ugly in my opinion. Can we all agree on that at least?
Not quite yet. But as soon as your libdir-patch is in main Pd, I would agree. From an aesthetic point of view, "list/drip" is on the same level of ugliness as "list-drip", however. And in most cases omiting the prefix - be it a directory or a filename prefix - makes no sense for list-abs anyway as many intentionally mimick builtin objects like list-makefilename etc. These won't work without some kind of prefix. (Gridflow's "#" is a similar case.)
Actually, the libdir stuff doesn't need to be a patch. Its on my
TODO list to make it a loader using the loader module functionality
that Thomas added. I guess I should bump it up on the TODO list...
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Actually, the libdir stuff doesn't need to be a patch. Its on my
TODO list to make it a loader using the loader module functionality
that Thomas added. I guess I should bump it up on the TODO list...
My main problem is how help files are found with abstractions. Normally it is enough to put a help file next to the abstraction like
$ ls list-drip.pd list-drip-help.pd
and all is fine, on right-click the correct help file is found. However with directory namespace this layout is broken:
$ ls list/* list: drip.pd drip-help.pd
It's not possible to find a help-file for [list/drip] this way,
Instead I need to use another "help" directory with another "list" subdirctory and add that "help" dir to the help path.
So I need one "list"-directory with "drip-help.pd" in the help-path and another "list"-directory with "drip.pd" in the Pd-path with plain Pd, which is way more complicated that using filename prefixes.
If I understand correctly what the libdir patch does, it's basically allowing help-files to live next to the original patch even with directory prefixes. This is important functionality IMO.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
You need to load the libraries to use them. This is not very well
documented admittedly, and much work needs to be done to make libdir
loading work well. But if you had followed the instructions in the
ReadMe.html included in the Pd-extended installers, you would not be
having this problem. I didn't write some stuff and put it in a file
called "ReadMe" for my own entertainment. Its there to help you get
things working.
.hc
On Jul 16, 2006, at 5:54 PM, Kyle Klipowicz wrote:
This is a list of some of the error messages that I received using the most recent test build of Pd-extended, using a G4 Powerbook with OSX 10.4.6.
- iemmatrix library does not load
e.g. when trying the cylinderExample.pd file for the shapeSynth
abstraction:load_object: Symbol "mtx_-_setup" not found load_object: Symbol "setup_mtx_0x2d" not found mtx_- ... couldn't create load_object: Symbol "mtx_+_setup" not found load_object: Symbol "setup_mtx_0x2b" not found mtx_+ ... couldn't create error: inlet: expected '' but got 'matrix' ... you might be able to track this down from the Find menu. error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix' error: inlet: expected '' but got 'matrix'
- when trying the formantdynwav.pd from creb examples:
onecomp~ ... couldn't create fdn: maximum nb of delay lines 8, total buffer size 65536 samples (1.486077 seconds)
- when trying to use the tbEnvify~-help.pd patch in abstractions/tb
I could not load the assert abstraction, nor the !- abstraction.
- when trying the examples/hid/mouse-tracker.pd I get this message
in the terminal: mouse ... couldn't create grid: version 0.6, written by Yves Degoyon (ydegoyon@free.fr) error: inlet: expected '' but got 'open'
- when trying the examples/hid/polar_joystick.pd I get this message
in the terminal: joystick 3 ... couldn't create hid_invert ... couldn't create hid_cube ... couldn't create expr, expr~, fexpr~ version 0.4 under GNU General Public License hid_polar ... couldn't create hid_log ... couldn't create error: inlet: expected '' but got 'open'
- when trying the examples/hid/spiral_joystick.pd I get this message
in the terminal: hid_invert ... couldn't create hid_cube ... couldn't create hid_spiral ... couldn't create joystick 3 ... couldn't create error: inlet: expected '' but got 'open'
- trying examples/gyre/gyre.pd yields:
gyre.stereoloop~ loop1 ... couldn't create gyre.stereoloop~ loop2 ... couldn't create gyre.stereoloop~ loop3 ... couldn't create gyre.stereoloop~ loop4 ... couldn't create gyre.stereoloop~ loop5 ... couldn't create gyre.stereoloop~ loop6 ... couldn't create
- trying examples/ix/nob-demo yields:
beware! this is widget 0.1, 19th alpha build... warning (Widget): no file 'setup.wid'... using built-in defaults beware! this is tot 0.1, 19th alpha build... error: makefilename: no method for 'bg' widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details widget's error: creation failure see standard error for details
In fact, all of the ix library does not work. There are probably more, but I have limited internet access right now, so these are all I've recorded for the moment during my useage.
~Kyle
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
-
Frank Barknecht -
Hans-Christoph Steiner -
james tittle -
Kyle Klipowicz -
Mathieu Bouchard