Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This just doesn't sound workable to me. Then you can never rely on an
externals or even abstractions, since they might be an incompatible
internal that comes along and overrides them.
The alternative would have
João Pais wrote:
as I see it (if it matters), there are 2 pd distros, pd-van and pd-ext
[although my view is that pd-ext should at some point assimilate pd-van
- is there anyone out there that really sticks to pd-van, and doesn't
use any externals, for other purposes than low-level
On Mon, 23 Feb 2009 09:36:02 +0100
Frank Barknecht f...@footils.org wrote:
but it must be allowed to create them
while moving along.
Yes. Here's why this discussion is so important.
Not to solve the problem now for the current case,
but to solve it gracefully for all the future.
We need Pd
On Mon, 23 Feb 2009, Andy Farnell wrote:
We need Pd core to grow and colonise its surrounding libraries,
subsuming a few parts from time to time rather than getting hemmed in by
them, always existing in competition with them.
colonise?... but what about the assimilation policy? forbid the
Exactly Mathieu, gotta bomb some Freedom into these external savages.
For their own good.
:)
On Mon, 23 Feb 2009 08:05:16 -0500 (EST)
Mathieu Bouchard ma...@artengine.ca wrote:
On Mon, 23 Feb 2009, Andy Farnell wrote:
We need Pd core to grow and colonise its surrounding libraries,
On Mon, 2009-02-23 at 09:36 +0100, Frank Barknecht wrote:
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This just doesn't sound workable to me. Then you can never rely on an
externals or even abstractions, since they might be an incompatible
internal
On Thu, 2009-02-19 at 10:00 +0100, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
i think, that the question, why a new object [pack] is named pack is not
rhetoric at all and isn't answered yet. so lets go again: why is [pack]
from zexy called [pack]?
apart from the specifics of
i think, that the question, why a new object [pack] is named pack is
not
rhetoric at all and isn't answered yet. so lets go again: why is
[pack]
from zexy called [pack]?
apart from the specifics of [pack]:
if a language allows the overriding of built-in methods, then i do not
see
I guess it never occurred to any of you to use objects with different
names...
Or else why not just call every pd object object and then use
paths to
access them, like [pd/some/library/subdirectory/object]?
Just kidding in a frustrated sort of way.
Different names are a good idea, for
On Feb 20, 2009, at 2:08 AM, Frank Barknecht wrote:
Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:
I suggest that the first object to use the name 'owns' the name and
any
subsequently invented objects use different names.
I think, that's good for external and abstraction
On Wed, 18 Feb 2009, Matt Barber wrote:
Chicken put to use
http://isotropic.org/papers/chicken.pdf
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris
On Wed, 18 Feb 2009, Matt Barber wrote:
On Wed, Feb 18, 2009 at 1:55 PM, Mathieu Bouchard ma...@artengine.ca wrote:
On Wed, 18 Feb 2009, Martin Peach wrote:
Or else why not just call every pd object object
the chicken language:
http://plif.courageunfettered.com/archive/wc072.gif
Chicken put
Roman Haefeli wrote:
On Wed, 2009-02-18 at 15:21 +0100, IOhannes m zmoelnig wrote:
Martin Peach wrote:
Well isn't it just easier to use something with a different name? If you
have a backwards [pow] why not just call it [backwardspow] instead of
letting users guess which [pow] is the right
Roman Haefeli wrote:
the switch from 0.41 to 0.42 did indeed also break at least one of the
netpd patches. this patch is using [unpack] for an incoming message,
that misses the list selector. while this still works with pd's [unpack]
(although it is an undocumented feature, i guess), it doesn't
Roman Haefeli wrote:
sorry for causing confusion. when i speak about differences in
pd-extended and pd vanilla i usually refer to the way of how libraries
in pd-extended are built and not to any difference in the core of
pd-extended and pd vanilla (which might doesn't exist anyway). so when i
Roman Haefeli wrote:
i think, that the question, why a new object [pack] is named pack is not
rhetoric at all and isn't answered yet. so lets go again: why is [pack]
from zexy called [pack]?
apart from the specifics of [pack]:
if a language allows the overriding of built-in methods, then i do
Hans-Christoph Steiner wrote:
Well, the point of cyclone is to be compatible with Max/MSP and all
its warts. So if you are trying to run a Max patch in Pd, then
cyclone's pow~ is correct.
speaking of... how does Max handle the namespaces/overriding/etc problem?
--
damian stewart |
i think, that the question, why a new object [pack] is named pack is not
rhetoric at all and isn't answered yet. so lets go again: why is [pack]
from zexy called [pack]?
because it is meant as a fully backwards-compatible replacement of [pack],
with added features.
since i have been
Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:
Well isn't it just easier to use something with a different name? If you
have a backwards [pow] why not just call it [backwardspow] instead of
letting users guess which [pow] is the right one?
If a former external becomes a builtin in
Frank Barknecht wrote:
Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:
Well isn't it just easier to use something with a different name? If you
have a backwards [pow] why not just call it [backwardspow] instead of
letting users guess which [pow] is the right one?
If a former
On Thu, 19 Feb 2009, IOhannes m zmoelnig wrote:
yesterday when i went home i was wondering about (i guess) the same
thing: could sending [foo bar( to [unpack s s] be actually considered a
bug in the patch (for sending a non-list to [unpack]) and unpack
itself (for accepting non-lists)?
with
On Thu, 19 Feb 2009, Matt Barber wrote:
Perhaps there is a conceptual difference between overriding internal
classes for a class with the same behavior but with added methods (e.g.
the [print] and [soundfiler] examples from before), and overriding with
a different object, or one with a
On Thu, 2009-02-19 at 09:46 +0100, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
i think, that the question, why a new object [pack] is named pack is not
rhetoric at all and isn't answered yet. so lets go again: why is [pack]
from zexy called [pack]?
because it is meant as a fully
On Wed, 2009-02-18 at 12:59 -0500, Hans-Christoph Steiner wrote:
Here's how I think this all should work:
- classes of any implementation language are treated the same
(i.e. .pd_linux, .pd, .pdlua, etc).
- single library format for all implementation methods
- possibility for
On Feb 19, 2009, at 3:53 AM, Damian Stewart wrote:
Hans-Christoph Steiner wrote:
Well, the point of cyclone is to be compatible with Max/MSP and
all its warts. So if you are trying to run a Max patch in Pd,
then cyclone's pow~ is correct.
speaking of... how does Max handle the
Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:
I suggest that the first object to use the name 'owns' the name and any
subsequently invented objects use different names.
I think, that's good for external and abstraction libraries (in the
repository), but Pd builtins should be free to
Roman Haefeli wrote:
correct me, if this is wrong, but i understand, that overriding internal
classes doesn't work with single-file externals. so the feature of
overriding internal classes doesn't and won't work with pd-extended.
not necessarily;
i haven't checked, but imagine:
1.:
[import
Frank Barknecht wrote:
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
do i understand correctly: external classes could override internal
classes also in older ( 0.42) versions of pd, but i just didn't notice
it? so the new feature is 'only' that pd automatically creates aliases
for
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
2.:
using [cyclone/pow~] will force the use of the single-object external,
and while doing so it will call the class_new() method for pow~ which
will override the internal [pow~].
[pow~] will become the cyclone version.
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
they could, but it was an effort to do so.
any ordinary external would not be able to do it.
So am I understanding it correctly, that Zexy's [pack] is not doing
the fuddling Cyclone does and now suddenly became an object that
Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
they could, but it was an effort to do so.
any ordinary external would not be able to do it.
So am I understanding it correctly, that Zexy's [pack] is not doing
the fuddling Cyclone does and now
IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
they could, but it was an effort to do so.
any ordinary external would not be able to do it.
So am I understanding it correctly, that Zexy's [pack] is not doing
the
Martin Peach wrote:
I guess it never occurred to any of you to use objects with different
names...
Or else why not just call every pd object object and then use paths to
access them, like [pd/some/library/subdirectory/object]?
Just kidding in a frustrated sort of way.
i don't get you
IOhannes m zmoelnig wrote:
Martin Peach wrote:
I guess it never occurred to any of you to use objects with different
names...
Or else why not just call every pd object object and then use paths
to access them, like [pd/some/library/subdirectory/object]?
Just kidding in a frustrated sort
Martin Peach wrote:
Well isn't it just easier to use something with a different name? If you
have a backwards [pow] why not just call it [backwardspow] instead of
letting users guess which [pow] is the right one?
who would object to that?
but which [pow~] _is_ the right one, and which one
On Feb 18, 2009, at 8:38 AM, Martin Peach wrote:
IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
they could, but it was an effort to do so.
any ordinary external would not be able to do it.
So am I understanding it
On Feb 18, 2009, at 3:21 AM, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
correct me, if this is wrong, but i understand, that overriding
internal
classes doesn't work with single-file externals. so the feature of
overriding internal classes doesn't and won't work with pd-extended.
Hans-Christoph Steiner wrote:
this is both with (an imagined) Pd-extended 0.42
Would this be any different with a Pd-vanilla+libs 0.42? I don't
think there is anything particular to the Pd version in Pd-extended
that would cause this, but instead the way the libraries are built.
no
On Wed, 18 Feb 2009 12:40:10 -0500
Hans-Christoph Steiner h...@eds.org wrote:
Well, the point of cyclone is to be compatible with Max/MSP and all
its warts. So if you are trying to run a Max patch in Pd, then
cyclone's pow~ is correct.
I see, that makes sense.
a.
--
Use the source
http://uncyclopedia.wikia.com/wiki/A!
On Wed, 18 Feb 2009 13:55:42 -0500 (EST)
Mathieu Bouchard ma...@artengine.ca wrote:
On Wed, 18 Feb 2009, Martin Peach wrote:
Or else why not just call every pd object object and then use paths to
access them, like
IOhannes m zmoelnig a écrit :
..
they could, but it was an effort to do so.
any ordinary external would not be able to do it.
the only library that i am aware of that did override internal classes
is cyclone,
what about zexy [unpack]?
it is still here, and it is still breaking my patch.
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
IOhannes m zmoelnig a écrit :
..
they could, but it was an effort to do so.
any ordinary external would not be able to do it.
the only library that i am aware of that did override internal
classes is cyclone,
what about zexy [unpack]?
cyrille henry wrote:
here is a patch that work with vanilla, but not with zexy unpack.
ah, another bug to fix :-(
oops, nobody told me yet :-)
don't you use it?
no, there are lots of objects in zexy which i seldomly use...
fgmasdr
IOhannes
smime.p7s
Description: S/MIME Cryptographic
cyrille henry wrote:
so, it look like unpack is still here.
indeed. i was wrongly assuming that class_addcreator() will not override
the default classes (unlike class_new())
should be _really_ fixed now.
fg,asdr
IOhannes
smime.p7s
Description: S/MIME Cryptographic Signature
On Wed, Feb 18, 2009 at 1:55 PM, Mathieu Bouchard ma...@artengine.ca wrote:
On Wed, 18 Feb 2009, Martin Peach wrote:
Or else why not just call every pd object object and then use paths to
access them, like [pd/some/library/subdirectory/object]? Just kidding in a
frustrated sort of way.
the
On Wed, 2009-02-18 at 15:21 +0100, IOhannes m zmoelnig wrote:
Martin Peach wrote:
Well isn't it just easier to use something with a different name? If you
have a backwards [pow] why not just call it [backwardspow] instead of
letting users guess which [pow] is the right one?
who
Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
2.:
using [cyclone/pow~] will force the use of the single-object external,
and while doing so it will call the class_new() method for pow~ which
will
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote:
how can someone assume so? no, that is so not true. i didn't even know,
that zexy comes with their own version of [pack] and [unpack] until some
weeks ago. and why the hell to
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
now, that pd has its own [pow~], why not just using that? yeah, it takes
a bit more time to write the abstractions, but then they are more
vanilla friendly.
But that's exactly why I brought this topic up and asked: What to do
about
Hans-Christoph Steiner wrote:
On Feb 16, 2009, at 4:24 AM, Frank Barknecht wrote:
What do you propose? The built-in stuff is loaded first, so that will
break patches that rely on [pow~] being the cyclone object.
the implications you make do not necessarily hold true for 0.42.
(does this
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
i still think that the loading-order in 0.42 is broken by design.
Could you elaborate this a bit? Or point me to the relevant archive
post? How is the loading order in 0.42?
Ciao
--
Frank
Frank Barknecht wrote:
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote:
how can someone assume so? no, that is so not true. i didn't even know,
that zexy comes with their own version of [pack] and [unpack] until some
weeks ago.
I think, the smartest thing would be to use the builtin pow~, but
reverse the *connections* made to it. Because that's what I'd have to do
manually now after importing a Max patch with cyclone.
An alternative would be to rename the pow~ in cyclone to something like
[max_pow~] or [Pow~] and
On Feb 17, 2009, at 2:20 AM, Roman Haefeli wrote:
On Tue, 2009-02-17 at 07:30 +0100, Frank Barknecht wrote:
Hallo,
Matt Barber hat gesagt: // Matt Barber wrote:
Getting rid of cyclone's pow~ would break all of the patches that
rely
on cyclone's pow~, and would also make it harder to
On Feb 17, 2009, at 2:37 AM, Roman Haefeli wrote:
On Tue, 2009-02-17 at 00:36 -0500, Matt Barber wrote:
Getting rid of cyclone's pow~ would break all of the patches that
rely
on cyclone's pow~, and would also make it harder to import Max/MSP
patches. Removing it is not a solution.
On Feb 17, 2009, at 3:45 AM, Frank Barknecht wrote:
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
now, that pd has its own [pow~], why not just using that? yeah, it
takes
a bit more time to write the abstractions, but then they are more
vanilla friendly.
But that's exactly
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
correct me, if this is wrong, but i understand, that overriding internal
classes doesn't work with single-file externals. so the feature of
overriding internal classes doesn't and won't work with pd-extended.
I believe that's not quite
On 17/02/2009, at 10.12, Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
i still think that the loading-order in 0.42 is broken by design.
Could you elaborate this a bit? Or point me to the relevant archive
post? How is the loading order in
On 17/02/2009, at 6.36, Matt Barber wrote:
If your patch breaks with a new version, use an
older version (...)
I totally agree.
That's also why i like when things (applications written in Pd or
libraries for Pd) have a version number and refer to version numbers
of it's dependencies,
On 17/02/2009, at 21.06, Frank Barknecht wrote:
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
correct me, if this is wrong, but i understand, that overriding
internal
classes doesn't work with single-file externals. so the feature of
overriding internal classes doesn't and
Hallo,
Steffen Juul hat gesagt: // Steffen Juul wrote:
So if you load a single-file-external without the -lib flag but just
having it in the path does not override any internal (object-)classes?
No, it doesn't. I tested this with Cyclone as single externals without
-lib: pow~ is the builtin
On Tue, 2009-02-17 at 21:20 +0100, Steffen Juul wrote:
On 17/02/2009, at 21.06, Frank Barknecht wrote:
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
correct me, if this is wrong, but i understand, that overriding
internal
classes doesn't work with single-file externals.
On Feb 16, 2009, at 4:24 AM, Frank Barknecht wrote:
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Gem cyclone zexy creb cxc iemlib list-abs mapping markex maxlib
memento mjlib motex oscx pddp pdogg pixeltango pmpd rradical sigpack
smlib toxy unauthorized vbap
At least we know it was an intentional difference:
http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html
For extended would it be possible to exclude cyclone pow~ from the
library, or less drastically patch both cyclone and vanilla pow~ to
throw a warning, as was discussed last april?
Hallo,
Matt Barber hat gesagt: // Matt Barber wrote:
At least we know it was an intentional difference:
http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html
For extended would it be possible to exclude cyclone pow~ from the
library, or less drastically patch both cyclone and
On Mon, 2009-02-16 at 22:58 +0100, Frank Barknecht wrote:
Hallo,
Matt Barber hat gesagt: // Matt Barber wrote:
At least we know it was an intentional difference:
http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html
For extended would it be possible to exclude cyclone
On Feb 16, 2009, at 4:58 PM, Frank Barknecht wrote:
Hallo,
Matt Barber hat gesagt: // Matt Barber wrote:
At least we know it was an intentional difference:
http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html
For extended would it be possible to exclude cyclone pow~ from the
On Feb 16, 2009, at 5:52 PM, Roman Haefeli wrote:
On Mon, 2009-02-16 at 22:58 +0100, Frank Barknecht wrote:
Hallo,
Matt Barber hat gesagt: // Matt Barber wrote:
At least we know it was an intentional difference:
http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html
For
Getting rid of cyclone's pow~ would break all of the patches that rely
on cyclone's pow~, and would also make it harder to import Max/MSP
patches. Removing it is not a solution.
Okay. But I don't see why something that is a rather obvious breach
of style should be allowed to bully the rest
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
from what i have understood, it is not cyclone's ability to replace
built-ins, but it is a so called new feature of pd 0.42. the same
happens also with zexy's [pack] and [unpack] and many others.
why is that so cool? i personally
Hallo,
Matt Barber hat gesagt: // Matt Barber wrote:
Getting rid of cyclone's pow~ would break all of the patches that rely
on cyclone's pow~, and would also make it harder to import Max/MSP
patches. Removing it is not a solution.
Okay. But I don't see why something that is a rather
On Tue, 2009-02-17 at 00:36 -0500, Matt Barber wrote:
Getting rid of cyclone's pow~ would break all of the patches that rely
on cyclone's pow~, and would also make it harder to import Max/MSP
patches. Removing it is not a solution.
Okay. But I don't see why something that is a rather
72 matches
Mail list logo
