[PD] "new wrap incompatible object" error

Matteo Sisti Sette matteosistisette at gmail.com
Tue Aug 17 10:55:58 CEST 2010


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:
>
> 0. puredata had [wrap~] but not [wrap]
> 1. [zexy/wrap] was implemented
> 2. pd-extended imports -lib zexy unqualified
> 3. 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




More information about the Pd-list mailing list