Hi,
This has probably been discussed, but I still cannot search the archives with google.
Whenever I try to use a [wrap] object, I get the error:
error: New imcompatible [wrap] object. For a backwards-compatible version, use [zexy/wrap]
What does that mean? The [wrap] object does work and behaves like Vanilla's [wrap], and [zexy/wrap] does work and it is the new one.
So I don't understand the error message....
thanks m.
On 2010-08-16 21:04, Matteo Sisti Sette wrote:
Hi,
This has probably been discussed, but I still cannot search the archives with google.
Whenever I try to use a [wrap] object, I get the error:
error: New imcompatible [wrap] object. For a backwards-compatible version, use [zexy/wrap]
What does that mean? The [wrap] object does work and behaves like Vanilla's [wrap], and [zexy/wrap] does work and it is the new one.
So I don't understand the error message....
try to find out where the message comes from (e.g. what library provides the version of [wrap] you are using)
i have searched the entire externals/ directory for "imcompatible" but cannot find it.
fgmadr IOhannes
On Mon, 16 Aug 2010, IOhannes m zmoelnig wrote:
i have searched the entire externals/ directory for "imcompatible" but cannot find it.
It's an annoyance found in (the core of) Pd-extended 42, in pd/src/x_arithmetic.c.
It prompted me to create a clone of this functionality just to avoid this error.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Aug 16, 2010, at 3:23 PM, Mathieu Bouchard wrote:
On Mon, 16 Aug 2010, IOhannes m zmoelnig wrote:
i have searched the entire externals/ directory for "imcompatible"
but cannot find it.It's an annoyance found in (the core of) Pd-extended 42, in pd/src/ x_arithmetic.c.
It prompted me to create a clone of this functionality just to avoid
this error.
Personally, its much more annoying if you have used [wrap] in your
patch, then your patch mysteriously breaks. Hence the error. I could
be worded better, so I'm updating it.
.hc
¡El pueblo unido jamás será vencido!
On Mon, 16 Aug 2010, Hans-Christoph Steiner wrote:
Personally, its much more annoying if you have used [wrap] in your patch, then your patch mysteriously breaks. Hence the error. I could be worded better, so I'm updating it.
can you make it a warn() instead, so that people can use "Find Last Error" for things that are really Errors ? That's especially because "Find Last Error" can really find only the Last one.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Aug 16, 2010, at 8:30 PM, Mathieu Bouchard wrote:
On Mon, 16 Aug 2010, Hans-Christoph Steiner wrote:
Personally, its much more annoying if you have used [wrap] in your
patch, then your patch mysteriously breaks. Hence the error. I
could be worded better, so I'm updating it.can you make it a warn() instead, so that people can use "Find Last
Error" for things that are really Errors ? That's especially because
"Find Last Error" can really find only the Last one.
a broken wrap or pow~ is really an error in my opinion.
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Mon, 16 Aug 2010, Hans-Christoph Steiner wrote:
a broken wrap is really an error in my opinion.
Anyway, [gf/wrap] is only 7 short lines of code, so why bother with this discussion.
\class GFWrap : FObject { float b; \constructor (float f=1) {b=f;} \decl 1 float (float f) {b=f;} \decl 0 float (float f) {out0;} }; \end class {install("gf/wrap",2,1);}
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 17/08/10 01:38, Hans-Christoph Steiner wrote:
On Aug 16, 2010, at 8:30 PM, Mathieu Bouchard wrote:
On Mon, 16 Aug 2010, Hans-Christoph Steiner wrote:
Personally, its much more annoying if you have used [wrap] in your patch, then your patch mysteriously breaks. Hence the error. I could be worded better, so I'm updating it.
can you make it a warn() instead, so that people can use "Find Last Error" for things that are really Errors ? That's especially because "Find Last Error" can really find only the Last one.
a broken wrap or pow~ is really an error in my opinion.
The timeline is important here, because I know that I (and possibly others) have a tendency to remember things in a way that justifies my own current viewpoint:
- puredata had [wrap~] but not [wrap]
- [zexy/wrap] was implemented
- pd-extended imports -lib zexy unqualified
- some people using pd-extended use [wrap] (from zexy)
4a. puredata implemented [wrap] that isn't quite the same 4b. puredata implemented "externals can override internals" (+warnings) 4c. pd-extended removed "externals can override internals" 5. some people write patches using [wrap] (from puredata) 6. pd-extended changes [wrap] to emit warnings 7a. puredata [wrap] users get upset about the warnings from pd-extended 7b. pd-extended [wrap] users get upset about the warnings from puredata
The point here is that, the puredata users in 5 who want to make patches with [wrap] work with both puredata and pd-extended without warnings/error message, now have NO options and the suggested solution from pd-extended BREAKS puredata:
A. using plain [wrap], puredata works fine and pd-extended complains B. using -lib zexy [wrap], puredata complains and pd-extended complains C. using -lib zexy [zexy/wrap], puredata FAILS*, pd-extended works fine
So, given that C is not an option for most puredata users, pd-extended should certainly not be recommending this as the way to fix patches, at least not unconditionally (afaik in some modes -lib zexy [wrap] behaves the same as puredata [wrap], but it can do more?)
Other solutions might be: I. allow externals to override internals, like puredata II. extend pd-extended's [wrap] to behave just like -lib zexy [wrap] when zexy is loaded/imported III. extend puredata's [wrap] to behave just like -lib zexy [wrap] and then port the changes to pd-extended
--[[-- opinion
The pd-extended users in 3 who want to make patches with [wrap] work with both puredata and pd-extended should have known that they were using an extension, but sadly pd-extended's decision to load everything automatically to "make life easier for users" caused this mess in the first place, in the end making life harder for everybody.
The incompatible suggestion smacks of pd-embrace-and-extend... http://en.wikipedia.org/wiki/Embrace_and_extend
--]]-- opinion
(*) with puredata and pd-zexy from Ubuntu Lucid 'universe': $ pd -stderr -verbose -lib zexy Pd version 0.42-5 compiled 20:01:18 Jan 5 2010 [snip] tried ./zexy.l_ia64 and failed tried /usr/lib/pd/extra/zexy.l_ia64 and failed tried ./zexy.pd_linux and failed tried /usr/lib/pd/extra/zexy.pd_linux and succeeded warning: class 'wrap' overwritten; old one renamed 'wrap_aliased' warning: class 'abs~' overwritten; old one renamed 'abs~_aliased'
©©©©©©©©©©©©©©©©©©©©©©©©©©©©
© the zexy external 2.1 ©
© (l) forum::für::umläute ©
© compiled: May 30 2008 ©
© send me a 'help' message ©
©©©©©©©©©©©©©©©©©©©©©©©©©©©©
tried /home/claude/zexy/wrap.l_ia64 and failed tried /usr/lib/pd/extra/zexy/wrap.l_ia64 and failed tried /home/claude/zexy/wrap.pd_linux and failed tried /usr/lib/pd/extra/zexy/wrap.pd_linux and failed tried /home/claude/zexy/wrap/wrap.l_ia64 and failed tried /usr/lib/pd/extra/zexy/wrap/wrap.l_ia64 and failed tried /home/claude/zexy/wrap/wrap.pd_linux and failed tried /usr/lib/pd/extra/zexy/wrap/wrap.pd_linux and failed tried /home/claude/zexy/wrap.pd and failed tried /usr/lib/pd/extra/zexy/wrap.pd and failed tried /home/claude/zexy/wrap.pat and failed tried /usr/lib/pd/extra/zexy/wrap.pat and failed zexy/wrap ... couldn't create
I hope this all makes sense, and that a more appropriate solution can be reached before the final release version of Pd-extended-0.42.
Claude
On Aug 16, 2010, at 10:23 PM, Claude Heiland-Allen wrote:
On 17/08/10 01:38, Hans-Christoph Steiner wrote:
On Aug 16, 2010, at 8:30 PM, Mathieu Bouchard wrote:
On Mon, 16 Aug 2010, Hans-Christoph Steiner wrote:
Personally, its much more annoying if you have used [wrap] in your patch, then your patch mysteriously breaks. Hence the error. I
could be worded better, so I'm updating it.can you make it a warn() instead, so that people can use "Find Last Error" for things that are really Errors ? That's especially because "Find Last Error" can really find only the Last one.
a broken wrap or pow~ is really an error in my opinion.
The timeline is important here, because I know that I (and possibly
others) have a tendency to remember things in a way that justifies
my own current viewpoint:
- puredata had [wrap~] but not [wrap]
- [zexy/wrap] was implemented
- pd-extended imports -lib zexy unqualified
- some people using pd-extended use [wrap] (from zexy)
4a. puredata implemented [wrap] that isn't quite the same 4b. puredata implemented "externals can override
internals" (+warnings) 4c. pd-extended removed "externals can override internals" 5. some people write patches using [wrap] (from puredata) 6. pd-extended changes [wrap] to emit warnings 7a. puredata [wrap] users get upset about the warnings from pd- extended 7b. pd-extended [wrap] users get upset about the warnings from
puredataThe point here is that, the puredata users in 5 who want to make
patches with [wrap] work with both puredata and pd-extended without
warnings/error message, now have NO options and the suggested
solution from pd-extended BREAKS puredata:A. using plain [wrap], puredata works fine and pd-extended complains B. using -lib zexy [wrap], puredata complains and pd-extended
complains C. using -lib zexy [zexy/wrap], puredata FAILS*, pd-extended works
fineSo, given that C is not an option for most puredata users, pd- extended should certainly not be recommending this as the way to fix
patches, at least not unconditionally (afaik in some modes -lib zexy
[wrap] behaves the same as puredata [wrap], but it can do more?)Other solutions might be: I. allow externals to override internals, like puredata II. extend pd-extended's [wrap] to behave just like -lib zexy [wrap]
when zexy is loaded/imported III. extend puredata's [wrap] to behave just like -lib zexy [wrap]
and then port the changes to pd-extended--[[-- opinion
The pd-extended users in 3 who want to make patches with [wrap] work
with both puredata and pd-extended should have known that they were
using an extension, but sadly pd-extended's decision to load
everything automatically to "make life easier for users" caused this
mess in the first place, in the end making life harder for everybody.The incompatible suggestion smacks of pd-embrace-and-extend... http://en.wikipedia.org/wiki/Embrace_and_extend
--]]-- opinion
(*) with puredata and pd-zexy from Ubuntu Lucid 'universe': $ pd -stderr -verbose -lib zexy Pd version 0.42-5 compiled 20:01:18 Jan 5 2010 [snip] tried ./zexy.l_ia64 and failed tried /usr/lib/pd/extra/zexy.l_ia64 and failed tried ./zexy.pd_linux and failed tried /usr/lib/pd/extra/zexy.pd_linux and succeeded warning: class 'wrap' overwritten; old one renamed 'wrap_aliased' warning: class 'abs~' overwritten; old one renamed 'abs~_aliased'
©©©©©©©©©©©©©©©©©©©©©©©©©©©© © the zexy external 2.1 © © (l) forum::für::umläute © © compiled: May 30 2008 © © send me a 'help' message © ©©©©©©©©©©©©©©©©©©©©©©©©©©©©
tried /home/claude/zexy/wrap.l_ia64 and failed tried /usr/lib/pd/extra/zexy/wrap.l_ia64 and failed tried /home/claude/zexy/wrap.pd_linux and failed tried /usr/lib/pd/extra/zexy/wrap.pd_linux and failed tried /home/claude/zexy/wrap/wrap.l_ia64 and failed tried /usr/lib/pd/extra/zexy/wrap/wrap.l_ia64 and failed tried /home/claude/zexy/wrap/wrap.pd_linux and failed tried /usr/lib/pd/extra/zexy/wrap/wrap.pd_linux and failed tried /home/claude/zexy/wrap.pd and failed tried /usr/lib/pd/extra/zexy/wrap.pd and failed tried /home/claude/zexy/wrap.pat and failed tried /usr/lib/pd/extra/zexy/wrap.pat and failed zexy/wrap ... couldn't create
I hope this all makes sense, and that a more appropriate solution
can be reached before the final release version of Pd-extended-0.42.
Patches welcome. At this point I'm satisified with keeping an error
message for the 0.42 release, then downgrading it to a warning in 0.43
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On 2010-08-17 04:51, Hans-Christoph Steiner wrote:
Patches welcome. At this point I'm satisified with keeping an error message for the 0.42 release, then downgrading it to a warning in 0.43
i most likely don't have time. but the pd-extended built-in [wrap] should _only_ emit errors/warnings if the object is used in a way that is incompatible. creating [wrap] (pd-vanilla, or zexy; and i guess others as well), will wrap between [0,1). this is 100% compatible; issueing an error doesn't do any good.
the same goes for [wrap 1] or [wrap 0 1] (however, the vanilla object will silently ignore the arguments, even though their presence might suggest that they have a meaning; so i guess it would be ok if there was a warning whenever arguments were used)
On Tue, 17 Aug 2010, IOhannes m zmoelnig wrote:
the same goes for [wrap 1] or [wrap 0 1] (however, the vanilla object will silently ignore the arguments, even though their presence might suggest that they have a meaning; so i guess it would be ok if there was a warning whenever arguments were used)
That's actually a "feature" of pd itself : whenever you register (with class_new or class_addcreator) any new-method with a fixed number of arguments, it silently ignores extra arguments. To enforce the argument count, you have to register your new-method with A_GIMME and then code a if(argc>=n) {error("barf");return 0;} ... that's what GridFlow's C++/Pd interface doing under the hood, for every constructor declared with fixed number of args. (I can't really stand Pd's behaviour there.)
PS: actually, vanilla's [wrap] is completely undocumented, so, if no-one uses it willingly, pd-extended could completely disable the fucker until Miller provides a helpfile for it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Tue, 17 Aug 2010, Claude Heiland-Allen wrote:
The pd-extended users in 3 who want to make patches with [wrap] work with both puredata and pd-extended should have known that they were using an extension, but sadly
I don't think that people aren't aware that pd extended bundles a lot of things that aren't in pd vanilla. I think that it's made pretty clear. Those who don't know that, also have no intention of making their patches work with vanilla, if they even know the existence of vanilla.
So, suppose that they do know that pd-vanilla is pretty vanilla, then the real problem is more like : if they write [zexy/wrap] in the patch, it doesn't work with a vanilla+zexy setup, and then, if they do it as [wrap] instead, they run into the problems you listed.
Moral of the story is that the "zexy/" prefix is only available in the software in which it is available and not in the one in which it isn't.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Aug 16, 2010, at 11:02 PM, Mathieu Bouchard wrote:
On Tue, 17 Aug 2010, Claude Heiland-Allen wrote:
The pd-extended users in 3 who want to make patches with [wrap]
work with both puredata and pd-extended should have known that they
were using an extension, but sadlyI don't think that people aren't aware that pd extended bundles a
lot of things that aren't in pd vanilla. I think that it's made
pretty clear. Those who don't know that, also have no intention of
making their patches work with vanilla, if they even know the
existence of vanilla.So, suppose that they do know that pd-vanilla is pretty vanilla,
then the real problem is more like : if they write [zexy/wrap] in
the patch, it doesn't work with a vanilla+zexy setup, and then, if
they do it as [wrap] instead, they run into the problems you listed.Moral of the story is that the "zexy/" prefix is only available in
the software in which it is available and not in the one in which it
isn't.
There is no standard vanilla+zexy install, so there is no real way to
support it. That's the idea of Pd-extended: a standard install.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom
On 2010-08-17 05:09, Hans-Christoph Steiner wrote:
There is no standard vanilla+zexy install, so there is no real way to support it. That's the idea of Pd-extended: a standard install.
on Debian the standard vanilla+zexy install is called "apt-get install puredata pd-zexy"
on other systems it is more like: get pd from miller's side and install, get zexy from puredata.info and install using the provided instructions.
just because there is no one-click installer doesn't meant that there is no standard way.
fgamr IOhannes
Hi,
On Mon, Aug 16, 2010 at 11:09:20PM -0400, Hans-Christoph Steiner wrote:
That's the idea of Pd-extended: a standard install.
... which still can be immensely different from machine to machine, like by library updates or by changed start-up defaults (e.g. removal/addition of loaded libs) or by installing libraries not in pd-x (sssad, rj, ...) etc.
Pd-extended is a more powerful, but in fact less standardized platform than Pd-vanilla w/o externals. It's in its nature.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Aug 17, 2010, at 3:16 AM, Frank Barknecht wrote:
Hi,
On Mon, Aug 16, 2010 at 11:09:20PM -0400, Hans-Christoph Steiner
wrote:That's the idea of Pd-extended: a standard install.
... which still can be immensely different from machine to machine,
like by library updates or by changed start-up defaults (e.g. removal/ addition of loaded libs) or by installing libraries not in pd-x (sssad, rj, ...)
etc.Pd-extended is a more powerful, but in fact less standardized
platform than Pd-vanilla w/o externals. It's in its nature.
That's not a really useful comparison. GNU without X is really
standardized, but if you want a GUI, then you get into GNOME, KDE,
xfce, etc.
Try doing lots of list operations without list-abs on Pd-vanilla, or
try doing OpenGL without Gem on Pd-vanilla. Libraries are very useful
things.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Tue, 17 Aug 2010, Frank Barknecht wrote:
Pd-extended is a more powerful, but in fact less standardized platform than Pd-vanilla w/o externals. It's in its nature.
I hope that this isn't an argument in favour of pd-vanilla ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
I don't know what the general solution would be, to avoid all problems of this kind,
but only in the very case of [wrap], IF i understands things correctly:
- zexy's wrap includes all the functionality of [wrap] and a bit more
- any patch using puredata's [wrap] would work the same if [wrap] were
replaced with [zexy/wrap] (obviously the viceversa is _not_ rue)
- puredata's [wrap] has no advantage over zexy's wrap
So why not do the following?:
- extends puredata (vanilla) 's [wrap] so that it works like zexy's one,
i.e. can use arguments to set range
- (not necessary for the issue being discussed, but necessary for
consistency with puredata's usual conventions): extend both to have two inlets to also set the range
- suppress any warning related to [wrap]
- keep zexys/wrap, which would be _identical_ to puredata's [wrap], just
for backward compatibility with patches written with the current Pd Extended in mind (i.e. people in point 3 of Claude's synopsis)
Wouldn't that eliminate all problems with wrap? Is it undesirable for some reason? Or not possible (perhaps for the impossibility of suppress general warnings in a special case?)?
On 08/17/2010 04:23 AM, Claude Heiland-Allen wrote:
On 17/08/10 01:38, Hans-Christoph Steiner wrote:
On Aug 16, 2010, at 8:30 PM, Mathieu Bouchard wrote:
On Mon, 16 Aug 2010, Hans-Christoph Steiner wrote:
Personally, its much more annoying if you have used [wrap] in your patch, then your patch mysteriously breaks. Hence the error. I could be worded better, so I'm updating it.
can you make it a warn() instead, so that people can use "Find Last Error" for things that are really Errors ? That's especially because "Find Last Error" can really find only the Last one.
a broken wrap or pow~ is really an error in my opinion.
The timeline is important here, because I know that I (and possibly others) have a tendency to remember things in a way that justifies my own current viewpoint:
- puredata had [wrap~] but not [wrap]
- [zexy/wrap] was implemented
- pd-extended imports -lib zexy unqualified
- some people using pd-extended use [wrap] (from zexy)
4a. puredata implemented [wrap] that isn't quite the same 4b. puredata implemented "externals can override internals" (+warnings) 4c. pd-extended removed "externals can override internals" 5. some people write patches using [wrap] (from puredata) 6. pd-extended changes [wrap] to emit warnings 7a. puredata [wrap] users get upset about the warnings from pd-extended 7b. pd-extended [wrap] users get upset about the warnings from puredata
The point here is that, the puredata users in 5 who want to make patches with [wrap] work with both puredata and pd-extended without warnings/error message, now have NO options and the suggested solution from pd-extended BREAKS puredata:
A. using plain [wrap], puredata works fine and pd-extended complains B. using -lib zexy [wrap], puredata complains and pd-extended complains C. using -lib zexy [zexy/wrap], puredata FAILS*, pd-extended works fine
So, given that C is not an option for most puredata users, pd-extended should certainly not be recommending this as the way to fix patches, at least not unconditionally (afaik in some modes -lib zexy [wrap] behaves the same as puredata [wrap], but it can do more?)
Other solutions might be: I. allow externals to override internals, like puredata II. extend pd-extended's [wrap] to behave just like -lib zexy [wrap] when zexy is loaded/imported III. extend puredata's [wrap] to behave just like -lib zexy [wrap] and then port the changes to pd-extended
--[[-- opinion
The pd-extended users in 3 who want to make patches with [wrap] work with both puredata and pd-extended should have known that they were using an extension, but sadly pd-extended's decision to load everything automatically to "make life easier for users" caused this mess in the first place, in the end making life harder for everybody.
The incompatible suggestion smacks of pd-embrace-and-extend... http://en.wikipedia.org/wiki/Embrace_and_extend
--]]-- opinion
(*) with puredata and pd-zexy from Ubuntu Lucid 'universe': $ pd -stderr -verbose -lib zexy Pd version 0.42-5 compiled 20:01:18 Jan 5 2010 [snip] tried ./zexy.l_ia64 and failed tried /usr/lib/pd/extra/zexy.l_ia64 and failed tried ./zexy.pd_linux and failed tried /usr/lib/pd/extra/zexy.pd_linux and succeeded warning: class 'wrap' overwritten; old one renamed 'wrap_aliased' warning: class 'abs~' overwritten; old one renamed 'abs~_aliased'
©©©©©©©©©©©©©©©©©©©©©©©©©©©© © the zexy external 2.1 © © (l) forum::für::umläute © © compiled: May 30 2008 © © send me a 'help' message © ©©©©©©©©©©©©©©©©©©©©©©©©©©©©
tried /home/claude/zexy/wrap.l_ia64 and failed tried /usr/lib/pd/extra/zexy/wrap.l_ia64 and failed tried /home/claude/zexy/wrap.pd_linux and failed tried /usr/lib/pd/extra/zexy/wrap.pd_linux and failed tried /home/claude/zexy/wrap/wrap.l_ia64 and failed tried /usr/lib/pd/extra/zexy/wrap/wrap.l_ia64 and failed tried /home/claude/zexy/wrap/wrap.pd_linux and failed tried /usr/lib/pd/extra/zexy/wrap/wrap.pd_linux and failed tried /home/claude/zexy/wrap.pd and failed tried /usr/lib/pd/extra/zexy/wrap.pd and failed tried /home/claude/zexy/wrap.pat and failed tried /usr/lib/pd/extra/zexy/wrap.pat and failed zexy/wrap ... couldn't create
I hope this all makes sense, and that a more appropriate solution can be reached before the final release version of Pd-extended-0.42.
Claude
On 08/17/2010 02:30 AM, Mathieu Bouchard wrote:
That's especially because "Find Last Error" can really find only the Last one.
Would it be a great effort to improve the "find last error" so that you could then find the previous one, then the previous one and so on?
I dream of a world where you can click on any error message in the console and it will bring you to the source of the error...
(though before that, I dream of a world where "find last error", just as is, works also with GOP)
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Matteo Sisti Sette