Hey,
Right now, Pd-extended is loading a lot of libraries by default. Most people never used most of those libraries, so I think it makes sense to reduce that number to move towards the goal of having the library loading embedded in the patch itself.
So the question now is, which libraries should stay in for now, to ease the transition? Here's the current list in the order they are loaded:
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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Or does it even make sense to do it in stages?
.hc
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Uhm: list-abs?
A little problem is coming up with cyclone: Its [pow~] is different from the new builtin [pow~] in 0.42 (reversed inlets). What should we do about that?
Ciao
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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Uhm: list-abs?
A little problem is coming up with cyclone: Its [pow~] is different from the new builtin [pow~] in 0.42 (reversed inlets). What should we do about that?
What do you propose? The built-in stuff is loaded first, so that will break patches that rely on [pow~] being the cyclone object.
This is a great example of why no libraries should be loaded by default, and instead the library configuration should be part of the patch itself. If we can such a system in place before Pd-extended 0.42, that will make the transition much easier. You could just load 'cyclone' before 'extra' in your own patch, and there would be no conflicts. Yes, it will be annoying in the short run, but in the long run, we'll be better off.
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
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 sentence make sense at all?)
i still think that the loading-order in 0.42 is broken by design.
fgamsr IOhannes
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
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 0.42?
I'm guessing he means that the internals are loaded first, then the libs (in any meaning Pd-wise). And not the other way around: Libs first, then the internals.
Steffen Juul wrote:
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 0.42?
I'm guessing he means that the internals are loaded first, then the libs (in any meaning Pd-wise). And not the other way around: Libs first, then the internals.
i meant that i think that i think that automatic overwriting of classes is broken design. i haven't read-on in this thread when i wrote the original email; if so, i would have felt no need to type.
fdga IOhannes
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?
Matt
On Mon, Feb 16, 2009 at 4:24 AM, Frank Barknecht fbar@footils.org 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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Uhm: list-abs?
A little problem is coming up with cyclone: Its [pow~] is different from the new builtin [pow~] in 0.42 (reversed inlets). What should we do about that?
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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 vanilla pow~ to throw a warning, as was discussed last april?
This is not related to Pd-extended which AFAIK doesn't include cyclone as a library (a "-lib" loadable one), but when loaded as a lib, Cyclone does some magic to even overwrite Pd internals. I made a little check now and actually Cyclone then is very smart and aliasses the builtins to different names.
Running "pd-0.42 -lib cyclone" gives this:
... warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' ...
and now the [pow~] behaves like in Max, while [pow~_aliased] is the new pow~ from 0.42. That's pretty cool, actually.
Unfortunatly you cannot use the other cyclone objects without rewriting [pow~] when cyclone is loaded as a library.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
This is not related to Pd-extended which AFAIK doesn't include cyclone as a library (a "-lib" loadable one), but when loaded as a lib, Cyclone does some magic to even overwrite Pd internals. I made a little check now and actually Cyclone then is very smart and aliasses the builtins to different names.
Running "pd-0.42 -lib cyclone" gives this:
... warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' ...
and now the [pow~] behaves like in Max, while [pow~_aliased] is the new pow~ from 0.42. That's pretty cool, actually.
And actually I found, that it's not Cyclone doing this, but Pd itself! The magic is in m_class.c and new in 0.42.
Ciao
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 pow~ from the library, or less drastically patch both cyclone and vanilla pow~ to throw a warning, as was discussed last april?
This is not related to Pd-extended which AFAIK doesn't include cyclone as a library (a "-lib" loadable one), but when loaded as a lib, Cyclone does some magic to even overwrite Pd internals. I made a little check now and actually Cyclone then is very smart and aliasses the builtins to different names.
Running "pd-0.42 -lib cyclone" gives this:
... warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' ...
and now the [pow~] behaves like in Max, while [pow~_aliased] is the new pow~ from 0.42. That's pretty cool, actually.
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 find it _very much_ confusing, that you cannot be sure anymore to use only pd-vanilla classes, when libraries are loaded. this new feature makes it impossible to stick with only-vanilla classes in one patch, where another one in the same instance of pd loads some libs. for me, the vanilla classes were some last 'safe' ressort, which is now polluted and messy, and i have to rely on thirdparty authors, and i need to trust them, that they write their externals compatible to the internals, so that my patches don't break. shouldn't the core library considered to be holy and untouchable, at least this one?
then again, as you say, this new features introduces _another_ difference between pd-extended and vanilla: overriding internal classes works only with libs and not with single-class-per-file collections.
why keeping backwards compabitility (which is the mentioned reason, why this new feature was introduced) on _any_ cost, even on cost of breaking patches and introducing new incompatibilities?
i am confused / confused / confused.....
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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 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?
This is not related to Pd-extended which AFAIK doesn't include cyclone as a library (a "-lib" loadable one), but when loaded as a lib, Cyclone does some magic to even overwrite Pd internals. I made a little check now and actually Cyclone then is very smart and aliasses the builtins to different names.
Running "pd-0.42 -lib cyclone" gives this:
... warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' ...
and now the [pow~] behaves like in Max, while [pow~_aliased] is the new pow~ from 0.42. That's pretty cool, actually.
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 find it _very much_ confusing, that you cannot be sure anymore to use only pd-vanilla classes, when libraries are loaded. this new feature makes it impossible to stick with only-vanilla classes in one patch, where another one in the same instance of pd loads some libs. for me, the vanilla classes were some last 'safe' ressort, which is now polluted and messy, and i have to rely on thirdparty authors, and i need to trust them, that they write their externals compatible to the internals, so that my patches don't break. shouldn't the core library considered to be holy and untouchable, at least this one?
then again, as you say, this new features introduces _another_ difference between pd-extended and vanilla: overriding internal classes works only with libs and not with single-class-per-file collections.
why keeping backwards compabitility (which is the mentioned reason, why this new feature was introduced) on _any_ cost, even on cost of breaking patches and introducing new incompatibilities?
i am confused / confused / confused.....
roman
I think Roman is illustrating the dangers of this overriding approach very well. I think that this also highlights the advantages of making the vanilla internals into a distinct library and having the library configuration as part of the patch. Then you can specify [import vanilla] and you will be sure that your [pow~] will be the vanilla pow~ regardless of the user's local setup. That means that your patch is much more likely to run on many more machines.
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
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 find it _very much_ confusing, that you cannot be sure anymore to use only pd-vanilla classes, when libraries are loaded.
IIR that's not how the feature in 0.42 works. It does not affect each external and also does not affect single-file externals. The only object classes affected are those, that override Pd builtins. If you load zexy and if zexy overrides [pack], then its sensible to assume, that you want to use zexy's [pack]. Pd 0.42 keeps its own [pack] in an alias, but allows zexy to override it with its own version.
Same with some versions of pow~, wrap, abs~, ...
If you use Cyclone in its single externals files version, the version of [pow~] that you get is the one from 0.42.
"Fixing" this would involve changing Cyclone and Zexy.
then again, as you say, this new features introduces _another_ difference between pd-extended and vanilla: overriding internal classes works only with libs and not with single-class-per-file collections.
It's a difference between Pd >= 0.42 and Pd < 0.42. I don't think, overriding builtins ever worked with single-file externals, but maybe I'm wrong. IOhannes? The overriding with lib-libraries works as before, additionally you now can use the builtins with an alias. That may not be the most pretty solution, but it doesn't break anything.
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie z...
Right! ;)
Ciao
On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote:
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 find it _very much_ confusing, that you cannot be sure anymore to use only pd-vanilla classes, when libraries are loaded.
IIR that's not how the feature in 0.42 works. It does not affect each external and also does not affect single-file externals. The only object classes affected are those, that override Pd builtins. If you load zexy and if zexy overrides [pack], then its sensible to assume, that you want to use zexy's [pack].
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 they use the same names as internals? no, by no means i don't want to be forced to use the zexy version, just because some patches i use need zexy.
i really doesn't understand: when something doesn't provide the _exact_ same feature set, why does it steal the name?
Same with some versions of pow~, wrap, abs~, ...
If you use Cyclone in its single externals files version, the version of [pow~] that you get is the one from 0.42.
"Fixing" this would involve changing Cyclone and Zexy.
then again, as you say, this new features introduces _another_ difference between pd-extended and vanilla: overriding internal classes works only with libs and not with single-class-per-file collections.
It's a difference between Pd >= 0.42 and Pd < 0.42. I don't think, overriding builtins ever worked with single-file externals,
that is what i am saying: this is introducing a _new_ incompatibility between pd-extended and pd vanilla.
but maybe I'm wrong. IOhannes? The overriding with lib-libraries works as before, additionally you now can use the builtins with an alias. That may not be the most pretty solution, but it doesn't break anything.
i neeed to use an alias when i want to use vanilla objects? this is simply insane.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 they use the same names as internals? no, by no means i don't want to be forced to use the zexy version, just because some patches i use need zexy.
You have been forced to do so for many years, you just haven't been told about it until 0.42. I just now discovered that something is overwriting my [wrap]. I don't know yet which library does that. It would be nice if Pd could report the source library file together with the warning.
It's a difference between Pd >= 0.42 and Pd < 0.42. I don't think, overriding builtins ever worked with single-file externals,
that is what i am saying: this is introducing a _new_ incompatibility between pd-extended and pd vanilla.
Huh? The only "incompatibility" is the new *feature* of alias names for overwritten objects. 0.42's [pow~] or [abs~] also are a new *feature* implemented by popular demand. Loading libraries and the overwriting itself hasn't changed at all AFAIK. If you don't use the alias names, you don't have any problems.
but maybe I'm wrong. IOhannes? The overriding with lib-libraries works as before, additionally you now can use the builtins with an alias. That may not be the most pretty solution, but it doesn't break anything.
i neeed to use an alias when i want to use vanilla objects? this is simply insane.
I agree with you that external libraries generally shouldn't overwrite builtins. When using Cyclone for Max-importing it makes sense, though.
But IMO the aliasing is less insane than not being able to use the builtins at all, as is the case if you load object-overwriting-libraries like zexy or cyclone in any Pd version before 0.42, including pd-extended.
Note that here I use libraries in the "-lib"-loading many-externals-in-one-file sense here, not in the sense where everything (libs, singles, abstractions, "libdirs") is called a library and setting a path is called "loading a library".
Ciao
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. and why the hell to they use the same names as internals? no, by no means i don't want to be forced to use the zexy version, just because some patches i use need zexy.
You have been forced to do so for many years, you just haven't been told about it until 0.42. I just now discovered that something is overwriting my [wrap]. I don't know yet which library does that. It would be nice if Pd could report the source library file together with the warning.
It's a difference between Pd >= 0.42 and Pd < 0.42. I don't think, overriding builtins ever worked with single-file externals,
that is what i am saying: this is introducing a _new_ incompatibility between pd-extended and pd vanilla.
this i don't understand; it is an incompatibility between prior and post 0.42, no matter whether you are using pd-vanilla or pd-ext. just because pd-ext is still far from 0.42, doesn't mean that it will take counter-measures when the time is ripe.
Huh? The only "incompatibility" is the new *feature* of alias names for overwritten objects. 0.42's [pow~] or [abs~] also are a new *feature* implemented by popular demand. Loading libraries and the overwriting itself hasn't changed at all AFAIK. If you don't use the alias names, you don't have any problems.
imo, the entire "alias" thing does not deserve it's name. who will ever want to have [pow~_alias] in their patches?
now what happens if we have 2 (multi-object) libraries loaded, both of them containing [pow~]. do we get [pow~_alias_alias] or will the internal just vanish from the users scope? if so, why is there an arbitrary boundary at 2?
this all brings back the original idea of implicetely adding the libraries name somehow for aliases. e.g. [pow~] in pd, lib1, and lib2 (in this order) 1. Pd's [pow~] 2. lib1 gets loaded; the original [pow~] becomes [pd/pow~]; the lib1's one is now known as [pow~] 3. lib1 get's loaded; Pd's [pd/pow~] stays untouched; lib1's one becomes [lib1/pow~]; the new one is know as [pow~]
darn, this is all the thing i have written 6 (or so) years ago. i remember there have been good reasons not to do it like this.
nevertheless, the idea is kind of re-occurant to me; and i firmly believe it is a better solution than to add an "_alias" suffix.
but maybe I'm wrong. IOhannes?
overriding with single object externals never worked, because Pd does not see a reason to even try and open a library file which could then overwrite the internal.
The overriding with lib-libraries works as before,
no it does not. Pd never (that is: prior to 0.42) provided a way to overwrite existing classes. this holds true for multi-object libraries. cyclone did some very special tricks to override existing objects.
btw, it tried to do so in a quite sensible way: if the new cyclone-object failed to create (e.g. because of wron arguments to the object), it would fall-back to the original object.
I agree with you that external libraries generally shouldn't overwrite builtins. When using Cyclone for Max-importing it makes sense, though.
actually i don't see a big problem. it would be the external's responsibility to maintain full compatibility. if it is not compatible (like zexy's [pack] right now), then this is just a bug in the external. the problem with zexy's [pack] overriding the internal was just because i was caught on the back foot, believing that i was save for now until the incompatibililties were fixed...
But IMO the aliasing is less insane than not being able to use the builtins at all, as is the case if you load object-overwriting-libraries like zexy or cyclone in any Pd version before 0.42, including pd-extended.
aliasing is not bad. what is bad is the way the aliases are generated
Note that here I use libraries in the "-lib"-loading many-externals-in-one-file sense here, not in the sense where everything (libs, singles, abstractions, "libdirs") is called a library and setting a path is called "loading a library".
yes, i agree we should not call adding a path "loading a library". "expanding the namespace" might be better.
mhadft IOhannes
On Tue, 2009-02-17 at 10:47 +0100, IOhannes m zmoelnig wrote:
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. and why the hell to they use the same names as internals? no, by no means i don't want to be forced to use the zexy version, just because some patches i use need zexy.
You have been forced to do so for many years, you just haven't been told about it until 0.42. I just now discovered that something is overwriting my [wrap]. I don't know yet which library does that. It would be nice if Pd could report the source library file together with the warning.
It's a difference between Pd >= 0.42 and Pd < 0.42. I don't think, overriding builtins ever worked with single-file externals,
that is what i am saying: this is introducing a _new_ incompatibility between pd-extended and pd vanilla.
this i don't understand; it is an incompatibility between prior and post 0.42, no matter whether you are using pd-vanilla or pd-ext. just because pd-ext is still far from 0.42, doesn't mean that it will take counter-measures when the time is ripe.
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. this is what i call the incompatibility. a patch, that loads cyclone, assumes to be using the [pow~] of cyclone, while on pd-extended it does actually use the pd [pow~]. this is _not_ related to the version of pd-extended, this will virtually always be true, wouldn't it? so in my terminology, introducing the ability for external classes to override internal classes is what i call deliberately introducing a _new_ incompatibility between pd vanilla and pd-extended.
please someone correct me, if this is wrong or based on wrong assumptions.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 correct: AFAIK overriding classes requires that a file is loaded with "-lib filename". -lib also works for single-file-externals and is still supported in Pd-extended for all I know. :)
Ciao
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 won't work with pd-extended.
I believe that's not quite correct: AFAIK overriding classes requires that a file is loaded with "-lib filename". -lib also works for single-file-externals and is still supported in Pd-extended for all I know. :)
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?
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 one.
Pd 0.42 tells you on startup every class that has been overwritten.
Ciao
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. so the feature of overriding internal classes doesn't and won't work with pd-extended.
I believe that's not quite correct: AFAIK overriding classes requires that a file is loaded with "-lib filename". -lib also works for single-file-externals and is still supported in Pd-extended for all I know. :)
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?
as far as i understand, it is not possible at all to 'load' a single-file-external without using lib, since it is shadowed by the internal class, thus pd is never looking for it, since it finds the internal class, that is already loaded. so you need to explicitly load with '-lib' option on the command line, if you want to override the internal class.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 cyclone] [pow~] will remain the vanilla version
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.
this is both with (an imagined) Pd-extended 0.42
please someone correct me, if this is wrong or based on wrong assumptions.
mfga.sdr IOhannes
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.
This is correct. I made a test whose results you can see in the attached screenshot and patch. It's weird. :)
Ciao
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 override the internal [pow~]. [pow~] will become the cyclone version.
This is correct. I made a test whose results you can see in the attached screenshot and patch. It's weird. :)
Okay, replying to myself: The attached patch IMO illustrates a severe bug with the aliasing. It is possible to have the same object in a patch behave differently depending on opaque circumstances like creation order. That's not only weird, it's nasty.
Generally from time to time Pd will get new builtins that may use names of objects, that are already in some library. These internals should not be overwritten by the old externals by default, but overwriting may be included as an optional feature. So I would suggest something like a (gloabl or canvas-local) switch that explicitly enables builtin-overwriting. That way, Cyclone could still import Max patches, but zexy-pack wouldn't break anything in the default case. Still IOhannes would be able to use his pack when developing and RjDj could overwrite [soundfiler] with a [soundfiler] external that also loads ogg-files.
Cyclone's fragile part probably could even be simplified in the code.
Ciao
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.
not necessarily; i haven't checked, but imagine: 1.: [import cyclone] [pow~] will remain the vanilla version
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.
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.
.hc
please someone correct me, if this is wrong or based on wrong assumptions.
mfga.sdr IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
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
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 of course not. my entire point was to show that it depends on the version of Pd (prior or post 0.42) rather than the flavour (vanilla or extended or whatever)
gfmar IOhannes
On Wed, 2009-02-18 at 19:28 +0100, IOhannes m zmoelnig wrote:
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 of course not. my entire point was to show that it depends on the version of Pd (prior or post 0.42) rather than the flavour (vanilla or extended or whatever)
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 mentioned an 'incompatibility between pd-extended and pd vanilla', i actually meant to say 'an incompatibility caused by different ways of how libraries are built'. i'll try to make that more clear in the future.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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 mentioned an 'incompatibility between pd-extended and pd vanilla', i actually meant to say 'an incompatibility caused by different ways of how libraries are built'. i'll try to make that more clear in the future.
but haven't i just illustrated that the way libraries are built in Pd-extended are no foolproof way to not override internals? so there is no "incompatibility caused by different ways of how libraries are built'. (it is a bit harder to trigger the problem on pdx though)
fmar IOhannes
On Tue, 2009-02-17 at 09:38 +0100, 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. and why the hell to they use the same names as internals? no, by no means i don't want to be forced to use the zexy version, just because some patches i use need zexy.
You have been forced to do so for many years, you just haven't been told about it until 0.42. I just now discovered that something is overwriting my [wrap]. I don't know yet which library does that. It would be nice if Pd could report the source library file together with the warning.
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 the overriden internals?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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 the overriden internals?
Yes. ;)
Ciao
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 the overriden internals?
Yes. ;)
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, and krzysztof did some awful work fuddling with the classtable of pd_objectmaker. i think the code is in the "fragile" (sic!) part of cyclone.
so in general the answer is "no".
fgmasdr IOhannes
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 overwrites internals by changes in Pd 0.42?
Ciao
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 suddenly became an object that overwrites internals by changes in Pd 0.42?
exactement!
because i didn't do any fudlling (well knowing that zexy's [pack] is not ready to replace Pd's [pack]; but stating the intention to become so LATER by using class_new("pack") - thinking that this was a safe thing to do), i was shocked that suddenly my pack would be used instead of the vanilla one.
fmgasdr IOhannes
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 fuddling Cyclone does and now suddenly became an object that overwrites internals by changes in Pd 0.42?
exactement!
because i didn't do any fudlling (well knowing that zexy's [pack] is not ready to replace Pd's [pack]; but stating the intention to become so LATER by using class_new("pack") - thinking that this was a safe thing to do), i was shocked that suddenly my pack would be used instead of the vanilla one.
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.
Martin
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 point.
why it might seem questionable to want to override a given function with a supposedly better one, i don't see why i should bully anyone who wants to do that...
mfgasrd IOhannes
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 of way.
i don't get you point.
why it might seem questionable to want to override a given function with a supposedly better one, i don't see why i should bully anyone who wants to do that...
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?
Martin
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 is backward?
fgmar IOhannes
On Wed, 18 Feb 2009 15:21:28 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
but which [pow~] _is_ the right one, and which one is backward?
The vanilla one is correct. It is consistent with mathematical and common syntactical properties of other asymmetrical (non commutative) operators
subtract A - B the second operand is the amount subtracted from the first operand (minuend) and the inlet order reflects this.
divide A/B the second operand (divisor) is the second inlet position, the first operand (dividend) is the first inlet.
So, for exponentiation A^B the first operand (base) is the first inlet, and the second operand (exponent) is the second inlet.
It's also that the signal domain [pow~] is consistent with the existing and long established message domain [pow]
At the risk of causing offence, Cyclone [pow~] made a mistake ordering inlets and I don't think it's good to take the broken Microsoft approach of putting historical, backwards compatability above correctness and future simplicity of code.
(FWIW I personally had to change dozens of my own patches including those already documented in a textbook - the pain is worth the gain to do things right.)
a.
On Feb 18, 2009, at 10:02 AM, Andy Farnell wrote:
On Wed, 18 Feb 2009 15:21:28 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
but which [pow~] _is_ the right one, and which one is backward?
The vanilla one is correct. It is consistent with mathematical and common syntactical properties of other asymmetrical (non commutative) operators
subtract A - B the second operand is the amount subtracted from the first operand (minuend) and the inlet order reflects this.
divide A/B the second operand (divisor) is the second inlet position, the first operand (dividend) is the first inlet.
So, for exponentiation A^B the first operand (base) is the first inlet, and the second operand (exponent) is the second inlet.
It's also that the signal domain [pow~] is consistent with the existing and long established message domain [pow]
At the risk of causing offence, Cyclone [pow~] made a mistake ordering inlets and I don't think it's good to take the broken Microsoft approach of putting historical, backwards compatability above correctness and future simplicity of code.
(FWIW I personally had to change dozens of my own patches including those already documented in a textbook - the pain is worth the gain to do things right.)
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.
It would be possible to have a somewhat usable system built around unique names. Basically, there would need to be a central registry of names, where people would check before naming their objects. Once a name exists, it could not be used again. So Pd-vanilla's pow~ would have to be called something else. I can't see any other way to do it, and this has been discussed since at least 2000.
.hc
a.
-- Use the source
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
On Wed, 18 Feb 2009 12:40:10 -0500 Hans-Christoph Steiner hans@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.
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?
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 namespaces/overriding/etc problem?
One global namespace, the internals are all built-in statically. I doubt you can override built-in names, but I don't know specifically. I'd be curious to hear about the search path for Max.
AFAIK, Max/MSP users basically operate under the assumption that if there is a name conflict, you need to chuck on of them.
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
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 would object to that?
but which [pow~] _is_ the right one, and which one is backward?
this is so much a rhethoric question, which is practically so easy to answer and was already answered. i absolutely don't see the point of this question.
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]?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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 one?
who would object to that?
but which [pow~] _is_ the right one, and which one is backward?
this is so much a rhethoric question, which is practically so easy to answer and was already answered. i absolutely don't see the point of this question
hmm, martin suggested (supposedly joking) to call one of the [pow] objects [backwardspow] (which i guess would have reversed inlets). now i guess that cyclones [pow~] is reveresed, should we just arbitrarily change it's name?
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 repeating this for several times now, i would be interested in the precise part of the above sentence that is unclear to you.
fmgasdr. IOhannes
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 repeating this for several times now, i would be interested in the precise part of the above sentence that is unclear to you.
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 different interface (the [pow~] situation).
For instance I think it would be at least a well-motivated task to write over [tabread4~] with one that inherited everything vanilla [tabread4~] could do, did those by default, but added methods for Hermite interpolation instead of Lagrange. Meanwhile, it would not be well-motivated to override it with an object which (to be silly) indexed tables in reverse, or (to be ridiculous because it's 4:00 AM here) grabbed a random joke from the web every 64 samples and posted it to the console.
What's unclear -- and to me probably the most important to solve as a result of this thread -- is what to do when vanilla adds features which potentially clash with objects in existing libraries. After all, this would be a much shorter thread if the problem were in a new [rfft~] object from some library that output bins in the order they appear in SuperCollider, thus breaking vanilla [rfft~] patches every time that library was loaded -- "in the name of gbuzz stop what you're doing and fix the library!"
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 different interface (the [pow~] situation).
Right. It has to do with the Liskov substitution principle, if you consider the new interface as a subtype of the old interface: whatever holds for the old interface, should hold for the new interface.
This principle defines what's a subtype, but doesn't say what it should be applied on. I mean, you can make statements about interfaces, and those statements talk about subtypes, but they don't necessarily talk about features, or they talk about one man's features which is another man's hole or bug. I mean, before worrying about subtypes, we have to figure out what's a feature and what's not.
I say that because there's something called pack_anything that is defined in pd, which looks pretty deliberate, and yet, it still seems to someone like a bug. So, what's a feature?
(Liskov's also has other exceptions such as "covariant types", but that's another thing)
Meanwhile, it would not be well-motivated to override it with an object which (to be silly) indexed tables in reverse, or (to be ridiculous because it's 4:00 AM here) grabbed a random joke from the web every 64 samples and posted it to the console.
Actually, if the spec of the class does not say that nothing will be posted to the console, and that there is no rule that says that nothing gets posted to the console unless specified explicitly in the spec, then it is the right of every subclass to do whatever it wants with the console, really... in theory... though it would be quickly reported as an annoyance or a bug. I suppose that... if it's really at 64 samples, then it would just flood the pd console so bad that it would freeze the programme.
"in the name of gbuzz stop what you're doing and fix the library!"
for a little while I hoped gbuzz would be the name of a Gtk port of Jeskola's BuzzTracker.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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 backwards-compatible replacement of [pack], with added features. since i have been repeating this for several times now, i would be interested in the precise part of the above sentence that is unclear to you.
i think, i understand that sentence, but still cannot see the goal of calling it the same. i mean, giving it the same name is of no use for your old (pre-zexy-[unpack]) patches, since they were not aware of the new features of zexy's [unpack], when they were created, thus they also would work with the pd's [unpack] today. on the other hand, for new patches, that potentionally profit from the added features of [unpack], it wouldn't have been any additional effort to write each time [zunpack] (or whatsoever) instead of [unpack]. so the only goal of it, that i can see is, that you deliberately want to confuse yourself, which i believe wasn't your reason to call it [unpack]. back to the orignal question....
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 not see why a social codex (which is what you are asking for, right?) should forbid it. especially, if a language introduces ways to override built-in methods after years of existance, it actually encourages the overriding of built-in methods.
i guess miller has spent countless of sleepless hours thinking and rethinking how to do this best, so we probably should adapt to it.
fgmasdr IOhannes
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 [pack]: if a language allows the overriding of built-in methods, then i do not see why a social codex (which is what you are asking for, right?) should forbid it. especially, if a language introduces ways to override built-in methods after years of existance, it actually encourages the overriding of built-in methods.
yo.. your point is perfectly valid. call me stubborn, but i still don't see the goal of: a) allowing to override internals b) actually using that feature but you are right: there is no reason, that should discourage you from using the new feature.
i guess miller has spent countless of sleepless hours thinking and rethinking how to do this best, so we probably should adapt to it.
whatever conclusion miller came to, i didn't get it.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 why a social codex (which is what you are asking for, right?) should forbid it. especially, if a language introduces ways to override built-in methods after years of existance, it actually encourages the overriding of built-in methods.
yo.. your point is perfectly valid. call me stubborn, but i still don't see the goal of: a) allowing to override internals b) actually using that feature but you are right: there is no reason, that should discourage you from using the new feature.
Hi,
if the purpose of [zexy/pack] was to override van-[pack], why not send the code to Miller and pack it with vanilla right away? why put it in another place, where it could be unadvertedly (mis)used by someone? for example, if I'm using [pack], I expect an error on the console in case I send a wrong list. if my patch starts with zexy's [pack] (I have zexy on my path, of course), I won't be in control of what's happening. you can reply "you will notice the mistake at another point", and it should be true - but only after I come to the conclusion that the wrong [pack] was being used.
the example given by pack can be taken by any other external, of course. although this is a kind of "name-usurpation" exception, other name-clashing externals aren't as much in sync as [pack] and [zexy/pack] - like Gem's counter and other counters, for example.
i guess miller has spent countless of sleepless hours thinking and rethinking how to do this best, so we probably should adapt to it.
whatever conclusion miller came to, i didn't get it.
I also don't understand what you meant, maybe we should ask him? and about pd-van's new opcodes, I would say that Miller is another developer like everyone else involved - and priorities are set by whoever gets firstly served (unless a gentleman's agreement is reached?). when he (or anyone) adds new externals, he (or anyone) should check if they're nameclashing from the pd-extended official release. I don't say to check with whatever externals or abstractions anyone has stacked somewhere in their computer, but to check with the other official bundle of pd, pd-extended. and that's not a laborious task at all, I think.
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 some future Pd version, you cannot use something with a different name, you can only rename the old external to something else. And what if the new builtin name was used by different, conflicting classes? What if Pd gets a [counter] builtin as is sometimes requested?
Ciao
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 external becomes a builtin in some future Pd version, you cannot use something with a different name, you can only rename the old external to something else. And what if the new builtin name was used by different, conflicting classes? What if Pd gets a [counter] builtin as is sometimes requested?
I suggest that the first object to use the name 'owns' the name and any subsequently invented objects use different names. That's all. If there's already a [counter] then Pd's new builtin counter would have to be called [pdcounter] or something. The name doesn't affect the function, and usually is not much use beyond being a unique identifier. You still need to look at the help patch to know what any version of [counter] actually does.
Martin
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 use any name they want (within reason) and not be forced to scan every available collection of externals or abstractions if a name is taken. That's just not practical, especially not for abstractions (of which I have thousands on my disk, most of them local to a project of course)
Ciao
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 libraries (in the repository), but Pd builtins should be free to use any name they want (within reason) and not be forced to scan every available collection of externals or abstractions if a name is taken. That's just not practical, especially not for abstractions (of which I have thousands on my disk, most of them local to a project of course)
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 idea here is to make it possible to use objectclasses that are not included in Pd without having to worry about our patches breaking.
.hc
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
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 been never to include pow~ and abs~ inside of Pd main, but give them different names. I prefer to have them available in Pd main under their "natural" names now.
There will always be backwards incompatible changes in any programming language or framework. Pd only had a very small number of these so far - I can only remember [atan2] - but it must be allowed to create them while moving along.
Ciao
On Mon, 23 Feb 2009 09:36:02 +0100 Frank Barknecht fbar@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 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.
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 externals from going to school in their own language, negate the existence of their culture, implement a mock-democracy by gerrymandering them into submission, if the parliament has any real power at all (?), and if they start to rebel, then burn down their farms, churches and towns. why not?
lots of interesting topics to think about.
(PS: what's that metaphor about? i don't get it)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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 matju@artengine.ca wrote:
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 externals from going to school in their own language, negate the existence of their culture, implement a mock-democracy by gerrymandering them into submission, if the parliament has any real power at all (?), and if they start to rebel, then burn down their farms, churches and towns. why not?
lots of interesting topics to think about.
(PS: what's that metaphor about? i don't get it)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hi,
I try to develop some code in opencv in the pix_opencv's style. To start, I tried to convert rgba to gray using opencv ( cvCvtColor(orig, gray, CV_BGRA2GRAY); )
but I can't get a gray picture of the same size at the output. If I just copy the gray image, I get just 4 small gray copy of the original on one line on the top of the image.
If I try to convert from grey to rgba before to output the data, I get a monochrome but yellow picture.
I wonder if there's a relation with the fact that I am working on a mac, is it possible ? because of a difference coding of rgba on mac and others?
do someone know how I can solve this?
here is the code of the one which give me a yellow monochromatic picture:
///////////////// processImage ///////////////////////// void pix_opencv_mytest :: processRGBAImage(imageStruct &image) { if ((this->comp_xsize!=image.xsize)||(this->comp_ysize! =image.ysize)||(!orig)) { this->comp_xsize = image.xsize; this->comp_ysize = image.ysize;
cvReleaseImage(&orig); cvReleaseImage(&gray); cvReleaseImage(&bob);
//create the orig image with new size orig = cvCreateImage(cvSize(image.xsize,image.ysize), IPL_DEPTH_8U, 4); gray = cvCreateImage(cvSize(orig->width,orig->height), IPL_DEPTH_8U, 1); } // Here we make a copy of the pixel data from image to orig-
imageData, orig is a IplImage struct
memcpy( orig->imageData, image.data, image.xsize*image.ysize*4 ); cvCvtColor(orig, gray, CV_BGRA2GRAY); // Convert to grayscale cvCvtColor(gray, orig, CV_GRAY2BGRA); //copy back the processed frame to image memcpy( image.data, orig->imageData, image.xsize*image.ysize*4 );
}
thanks, loic
Hi again,
I compiled the same code on Ubuntu Hardy 32 bits, and everything is ok , so apparently it is a problem related to os X. (with the same file and patche).
does anybody know how to avoid this ?
thanks, loic
Hi,
I try to develop some code in opencv in the pix_opencv's style. To start, I tried to convert rgba to gray using opencv ( cvCvtColor(orig, gray, CV_BGRA2GRAY); )
but I can't get a gray picture of the same size at the output. If I just copy the gray image, I get just 4 small gray copy of the original on one line on the top of the image.
If I try to convert from grey to rgba before to output the data, I get a monochrome but yellow picture.
I wonder if there's a relation with the fact that I am working on a mac, is it possible ? because of a difference coding of rgba on mac and others?
do someone know how I can solve this?
here is the code of the one which give me a yellow monochromatic picture:
///////////////// processImage ///////////////////////// void pix_opencv_mytest :: processRGBAImage(imageStruct &image) { if ((this->comp_xsize!=image.xsize)||(this->comp_ysize! =image.ysize)||(!orig)) { this->comp_xsize = image.xsize; this->comp_ysize = image.ysize;
cvReleaseImage(&orig); cvReleaseImage(&gray); cvReleaseImage(&bob);
//create the orig image with new size orig = cvCreateImage(cvSize(image.xsize,image.ysize), IPL_DEPTH_8U, 4); gray = cvCreateImage(cvSize(orig->width,orig->height), IPL_DEPTH_8U, 1); } // Here we make a copy of the pixel data from image to orig-
imageData, orig is a IplImage struct
memcpy( orig->imageData, image.data, image.xsize*image.ysize*4 ); cvCvtColor(orig, gray, CV_BGRA2GRAY); // Convert to grayscale cvCvtColor(gray, orig, CV_GRAY2BGRA); //copy back the processed frame to image memcpy( image.data, orig->imageData, image.xsize*image.ysize*4 );
}
thanks, loic
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 that comes along and overrides them.
The alternative would have been never to include pow~ and abs~ inside of Pd main, but give them different names. I prefer to have them available in Pd main under their "natural" names now.
There will always be backwards incompatible changes in any programming language or framework. Pd only had a very small number of these so far
- I can only remember [atan2] - but it must be allowed to create them
while moving along.
yo.. i agree. let's keeping backwards compatibility not get 'backwardscompatibilitis'
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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 correctly, that Zexy's [pack] is not doing the fuddling Cyclone does and now suddenly became an object that overwrites internals by changes in Pd 0.42?
exactement!
because i didn't do any fudlling (well knowing that zexy's [pack] is not ready to replace Pd's [pack]; but stating the intention to become so LATER by using class_new("pack") - thinking that this was a safe thing to do), i was shocked that suddenly my pack would be used instead of the vanilla one.
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 sure. But Pd should also not go down in flames if someone happens to create an object with a name that is already used somewhere. Its not possible to know every single object that has ever been made.
I just ran into this myself trying to create an abstraction called "beat". Apparently, there is already a [beat], so I got unexpected results.
.hc
Martin
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
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
Hans-Christoph Steiner wrote:
Different names are a good idea, for sure. But Pd should also not go down in flames if someone happens to create an object with a name that is already used somewhere. Its not possible to know every single object that has ever been made.
I just ran into this myself trying to create an abstraction called "beat". Apparently, there is already a [beat], so I got unexpected results.
Maybe a [which] object could help. Banging a [which pow~] would output the path to the pow~ that pd was using. Inputting a path would tell pd to use that one.
Martin
On Wed, 18 Feb 2009 21:40:10 +0000 "Martin Peach" martin.peach@sympatico.ca wrote:
Maybe a [which] object could help.
++ like that idea!, would be v. useful debug/helper object
On Feb 18, 2009, at 4:46 PM, Andy Farnell wrote:
On Wed, 18 Feb 2009 21:40:10 +0000 "Martin Peach" martin.peach@sympatico.ca wrote:
Maybe a [which] object could help.
++ like that idea!, would be v. useful debug/helper object
Yeah, that does sound useful. It would be good to have more querying or "reflection" things in Pd.
.hc
-- Use the source
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
On Feb 18, 2009, at 4:46 PM, Andy Farnell wrote:
On Wed, 18 Feb 2009 21:40:10 +0000 "Martin Peach" martin.peach@sympatico.ca wrote:
Maybe a [which] object could help.
++ like that idea!, would be v. useful debug/helper object
Yeah, that does sound useful. It would be good to have more querying or "reflection" things in Pd.
since iemguts has turned a lot into a reflection-library it is quite high on my todo list.
fgmar IOhannes
.hc
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 sure. But Pd should also not go down in flames if someone happens to create an object with a name that is already used somewhere. Its not possible to know every single object that has ever been made.
I just ran into this myself trying to create an abstraction called "beat". Apparently, there is already a [beat], so I got unexpected results.
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 educational ones?]. if there would be an updated documentation of pd-ext's content - and why not a "test-your-name" pdpedia page or external as well - it would be no problem to make sure these mistakes don't happen. my almost-recent (unefficient) efforts were to make an updated pd-ext object list, which could make clear what is available out there (maybe there wouldn't be the need to reinvent the wheel, or the counter), and also to avoid nameclashing. I can try to keep going at it, in order to keep people (and myself) informed of what's happening.
I guess pd won't come down in flames for nameclashing, but it has been happening for ever, and the only tactic to handle it was to ignore it, change the order some libraries were loaded or not load them at all, etc. Maybe it would be better just to stamp the foot down and try to sort out an efficient sollution for this? the problem won't go away, will just get worse, as the tendency is that more and more people will join the Pd army and write code for it (at least it's what we all expect, right?).
João Pais a écrit : ...
is there anyone out there that really sticks to pd-van, and doesn't use any externals, for other purposes than low-level educational ones?].
i do use only vanilla + Gem + my externals. well, most of the time. (by example chdh performance patch does also use canvas, moog~ and repeat (i'll remove the later when i'll have time))
i don't have anything against externals but there are different things that prevent me using lot's of them : (i use all the external i need. i just don't really need lot's of them)
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply. -for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them. -for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example) -for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently. -for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd-extended will be in version 0.42. -to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly. -for fun: most externals are useless and can be replaced by abstraction. although it's fun not to use external, it also more elegant.
this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it.
Cyrille
On Feb 22, 2009, at 7:50 PM, cyrille henry wrote:
João Pais a écrit : ...
is there anyone out there that really sticks to pd-van, and doesn't use any externals, for other purposes than low-level educational ones?].
i do use only vanilla + Gem + my externals. well, most of the time. (by example chdh performance patch does also use canvas, moog~ and repeat (i'll remove the later when i'll have time))
i don't have anything against externals but there are different things that prevent me using lot's of them : (i use all the external i need. i just don't really need lot's of them)
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply.
Yes, there is definitely some crappy code included in Pd-extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
-for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them.
I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility. Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
-for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example)
If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
-for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently.
If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true. AFAIK, this is how Miller bundles his code in PDRP.
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd- vanilla. That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
-for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd- extended will be in version 0.42.
With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
-to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly. -for fun: most externals are useless and can be replaced by abstraction. although it's fun not to use external, it also more elegant.
Unless you always include the abstraction with the project, all of the same problems occur with abstractions. If you have an abstraction that you reuse a lot, then you find a bug, you'd have to then fix it in all of your projects. So you'd want to put that abstraction into a single reusable library. Then it becomes an external. There really is no difference then in terms of distribution issues between a .pd and a .pd_linux.
this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it.
Perhaps one day, you'll join us ;-P
.hc
Cyrille
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Hans-Christoph Steiner a écrit :
On Feb 22, 2009, at 7:50 PM, cyrille henry wrote:
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply.
Yes, there is definitely some crappy code included in Pd-extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
yes, but i don't see the point of using pd-extended and removing the extended :-)
-for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them.
I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility.
i always think at one point that backward compatibility is something that prevent a software to move forward. look at max and the int / float problem. without backward compatibility Max would be much much better.
Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
yes, i don't think lot's of people use line3, but for me it's mandatory. so anyone should use there set of externals. but loading all like in current extended distribution is insane.
-for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example)
If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
well, pd-extended is very compatible with other pd-extended. but pd-extended is not the only pd distribution...
-for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently.
If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true.
of course i do include all abstractions in my project directory. a good project is a project that start : pd -noprefs myproject.pd with all declaration inside the patch. (and an even better project is when you can remove the -noprefs, so that there is no name conflict)
AFAIK, this is how Miller bundles his code in PDRP.
i'm not alone!
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd- vanilla.
you can put them anywhere, when you [declare] that path in your patch
That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
without your work, pd-extended will collapse. i can't be as sure than you are about the future of pd-extended.
-for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd- extended will be in version 0.42.
With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
i know that you have good reason. my mail is not a personal attack. but the fact is that i prefer using the 0.42 feature than the extended feature.
-to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly. -for fun: most externals are useless and can be replaced by abstraction. although it's fun not to use external, it also more elegant.
Unless you always include the abstraction with the project,
i do
all of the same problems occur with abstractions.
yes, that's why it's mandatory to do so.
If you have an abstraction that you reuse a lot, then you find a bug, you'd have to then fix it in all of your projects.
NO! it can be bad to fix something that change the behaviour of your old patch. unless of course you find a bug that could crash pd. by example, i just saw that env+ change the amplitude of the signal depending on it's argument. it's a bug and MUST be fixed. doing this will not change the behaviours of my old patch, but anyone trusting pd-extended will have to modify there patch. (well, i hope nobody noticed the difference anyway).
so, if your patch use a buggy abstraction, you better not to correct it in order to use your patch as it should work. i some specific case, you may have to modify lot's of your abstraction on the same way, but search/replace/script is your friend...
So you'd want to put that abstraction into a single reusable library. Then it becomes an external. There really is no difference then in terms of distribution issues between a .pd and a .pd_linux.
yes, i do include both in my projects.(with sources for the externals)
this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it.
Perhaps one day, you'll join us ;-P
i did not say pd-extended is bad (you know i support your work). i just say that for my main laptop i prefer not using it. but i do use it on the 100 of computers that run the patch i program...
cyrille
.hc
Cyrille
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply.
Yes, there is definitely some crappy code included in Pd-extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
here here. even if the code gets loaded into memory, as long as there are no nameclashing you shouldn't even notice it (except you're running an installation on a low-end computer and each byte counts, ...)
-for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them.
I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility. Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
and I also think that the redundancy comes also from the fact that there is no object list for pd-ext. no one has the time to search 2xxx objects, so they just program their own.
-for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example)
If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
is pd-ext not the standard version for many reasons more than it isn't maintained by MP, and because it isn't as actual as pd-van? I don't know about the compatibility issue - you say this because some systems have low resources (like rjdj), or because pd-ext isn't stable in some systems? the 1st makes sense, naturally (also if you get a 10year old computer for an installation, etc.)
-for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently.
If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true. AFAIK, this is how Miller bundles his code in PDRP.
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd-vanilla. That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
I think so as well, the builds are a solid package (if the code inside works, like it does in many of the libs). anyway, this discussion (and subsequent actions, if they happen) would be a good step to make pd-ext even more mature. I would think that a small "tester group" to test objects, or to alert developers for good testing + documentation + use of proper formats (for documentation + pdpedia or whatever) would be a good thing. I would be up to give some time for it (can't give much more than that, anyway).
-for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd- extended will be in version 0.42.
With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
are there any users that could help HC with the task of putting pd-van and pd-ext at the same level? I guess that the most mature result would be that MP's code would go directly to pd-ext after being tested/released.
-to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly.
what do you mean visually ugly? the fonts, or something that can't be adjusted?
João Pais a écrit :
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply.
Yes, there is definitely some crappy code included in Pd-extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
here here. even if the code gets loaded into memory, as long as there are no nameclashing you shouldn't even notice it (except you're running an installation on a low-end computer and each byte counts, ...)
loading a patch when you have lot's of lib loaded should be slower. but why using pd-extended if you don't need all the lib?
-for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them.
I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility. Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
and I also think that the redundancy comes also from the fact that there is no object list for pd-ext. no one has the time to search 2xxx objects, so they just program their own.
it's not very hard to look on the svn for a specific object name before writing the same object wih the same name.
-for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example)
If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
is pd-ext not the standard version for many reasons more than it isn't maintained by MP, and because it isn't as actual as pd-van?
i just mean pd-extended is not used by anyone.
I don't know about the compatibility issue - you say this because some systems have low resources (like rjdj), or because pd-ext isn't stable in some systems? the 1st makes sense, naturally (also if you get a 10year old computer for an installation, etc.)
everybody use a different set of external. so when you share a patch, you can have problem if someone does not load the lib you're using. look at how many problem send on the pd list is solve via changing pd lib loading preferences.
-for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently.
If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true. AFAIK, this is how Miller bundles his code in PDRP.
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd-vanilla. That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
I think so as well, the builds are a solid package (if the code inside works, like it does in many of the libs). anyway, this discussion (and subsequent actions, if they happen) would be a good step to make pd-ext even more mature. I would think that a small "tester group" to test objects, or to alert developers for good testing + documentation + use of proper formats (for documentation + pdpedia or whatever) would be a good thing. I would be up to give some time for it (can't give much more than that, anyway).
-for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd- extended will be in version 0.42.
With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
are there any users that could help HC with the task of putting pd-van and pd-ext at the same level? I guess that the most mature result would be that MP's code would go directly to pd-ext after being tested/released.
-to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly.
what do you mean visually ugly? the fonts, or something that can't be adjusted?
i just don't like the not transparent object.
cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I don't think that Pd-extended is for everyone, that's fine by me. I think its good to have many distros of Pd+libs. But what I think is essential is that we have a common library format so that patches made in one distro can be compatible in others. Saying that you tailor your environment to your patches is not a solution. Then your patches will only work in your custom setups.
That is why I think we need to discuss the library format and come up with a format that works for everyone. I posted the idea for a common library format somewhere in this thread. This is an idea that has been formed from the contributions of a number of people, and I think it covers all the concerns that I know of. Please take a look and comment on it, so we can start coding it and lay this argument to rest :D
.hc
On Feb 23, 2009, at 6:16 PM, cyrille henry wrote:
João Pais a écrit :
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply.
Yes, there is definitely some crappy code included in Pd- extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
here here. even if the code gets loaded into memory, as long as there are no nameclashing you shouldn't even notice it (except you're running an installation on a low-end computer and each byte counts, ...)
loading a patch when you have lot's of lib loaded should be slower. but why using pd-extended if you don't need all the lib?
-for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them.
I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility. Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
and I also think that the redundancy comes also from the fact that there is no object list for pd-ext. no one has the time to search 2xxx objects, so they just program their own.
it's not very hard to look on the svn for a specific object name before writing the same object wih the same name.
-for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example)
If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
is pd-ext not the standard version for many reasons more than it isn't maintained by MP, and because it isn't as actual as pd-van?
i just mean pd-extended is not used by anyone.
I don't know about the compatibility issue - you say this because some systems have low resources (like rjdj), or because pd-ext isn't stable in some systems? the 1st makes sense, naturally (also if you get a 10year old computer for an installation, etc.)
everybody use a different set of external. so when you share a patch, you can have problem if someone does not load the lib you're using. look at how many problem send on the pd list is solve via changing pd lib loading preferences.
-for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently.
If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true. AFAIK, this is how Miller bundles his code in PDRP.
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd- vanilla. That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
I think so as well, the builds are a solid package (if the code inside works, like it does in many of the libs). anyway, this discussion (and subsequent actions, if they happen) would be a good step to make pd-ext even more mature. I would think that a small "tester group" to test objects, or to alert developers for good testing + documentation + use of proper formats (for documentation + pdpedia or whatever) would be a good thing. I would be up to give some time for it (can't give much more than that, anyway).
-for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd- extended will be in version 0.42.
With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
are there any users that could help HC with the task of putting pd- van and pd-ext at the same level? I guess that the most mature result would be that MP's code would go directly to pd-ext after being tested/released.
-to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly.
what do you mean visually ugly? the fonts, or something that can't be adjusted?
i just don't like the not transparent object.
cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[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
Hans-Christoph Steiner a écrit :
I don't think that Pd-extended is for everyone, that's fine by me. I think its good to have many distros of Pd+libs.
we all agree here.
But what I think is essential is that we have a common library format so that patches made in one distro can be compatible in others.
yes, it is important. but having patch compatible between 2 pd distro require more than just a common lib format.
Saying that you tailor your environment to your patches is not a solution. Then your patches will only work in your custom setups.
yes. my aim is the opposite. starting pd with -noprefs is not really "tailor your environment to your patches" but trying to make your patch to work on all environment.
That is why I think we need to discuss the library format and come up with a format that works for everyone. I posted the idea for a common library format somewhere in this thread. This is an idea that has been formed from the contributions of a number of people, and I think it covers all the concerns that I know of. Please take a look and comment on it, so we can start coding it and lay this argument to rest :D
i miss this discussion.
so, having every file (.pd, .pd_linux .dll .pdlua and *-help.pd) in the same directory is ok for me.
The way you distribute a lib should also be related to the way you develop this lib on the svn. so, should the svn be ordered on the same way : every files on the same dir? except for sources and everything that need for compiling externals that could go on a src sub-folder? and also a sub-folder for the examples (that are not help files)?
about the loading order : is this mandatory to introduce incompatibility between vanilla and extended? changing the loading order in pd-extended may break some patch. this is not a major problem for me since we all can adapt old patch to work with a new software version. But to have different order between vanilla and extended is not really nice.
cyrille
.hc
On Feb 23, 2009, at 6:16 PM, cyrille henry wrote:
João Pais a écrit :
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply.
Yes, there is definitely some crappy code included in Pd- extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
here here. even if the code gets loaded into memory, as long as there are no nameclashing you shouldn't even notice it (except you're running an installation on a low-end computer and each byte counts, ...)
loading a patch when you have lot's of lib loaded should be slower. but why using pd-extended if you don't need all the lib?
-for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them.
I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility. Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
and I also think that the redundancy comes also from the fact that there is no object list for pd-ext. no one has the time to search 2xxx objects, so they just program their own.
it's not very hard to look on the svn for a specific object name before writing the same object wih the same name.
-for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example)
If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
is pd-ext not the standard version for many reasons more than it isn't maintained by MP, and because it isn't as actual as pd-van?
i just mean pd-extended is not used by anyone.
I don't know about the compatibility issue - you say this because some systems have low resources (like rjdj), or because pd-ext isn't stable in some systems? the 1st makes sense, naturally (also if you get a 10year old computer for an installation, etc.)
everybody use a different set of external. so when you share a patch, you can have problem if someone does not load the lib you're using. look at how many problem send on the pd list is solve via changing pd lib loading preferences.
-for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently.
If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true. AFAIK, this is how Miller bundles his code in PDRP.
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd- vanilla. That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
I think so as well, the builds are a solid package (if the code inside works, like it does in many of the libs). anyway, this discussion (and subsequent actions, if they happen) would be a good step to make pd-ext even more mature. I would think that a small "tester group" to test objects, or to alert developers for good testing + documentation + use of proper formats (for documentation + pdpedia or whatever) would be a good thing. I would be up to give some time for it (can't give much more than that, anyway).
-for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd- extended will be in version 0.42.
With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
are there any users that could help HC with the task of putting pd- van and pd-ext at the same level? I guess that the most mature result would be that MP's code would go directly to pd-ext after being tested/released.
-to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly.
what do you mean visually ugly? the fonts, or something that can't be adjusted?
i just don't like the not transparent object.
cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[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
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Feb 24, 2009, at 11:49 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
I don't think that Pd-extended is for everyone, that's fine by me. I think its good to have many distros of Pd+libs.
we all agree here.
But what I think is essential is that we have a common library format so that patches made in one distro can be compatible in others.
yes, it is important. but having patch compatible between 2 pd distro require more than just a common lib format.
Yes, but we have to start somewhere.
Saying that you tailor your environment to your patches is not a solution. Then your patches will only work in your custom setups.
yes. my aim is the opposite. starting pd with -noprefs is not really "tailor your environment to your patches" but trying to make your patch to work on all environment.
That is why I think we need to discuss the library format and come up with a format that works for everyone. I posted the idea for a common library format somewhere in this thread. This is an idea that has been formed from the contributions of a number of people, and I think it covers all the concerns that I know of. Please take a look and comment on it, so we can start coding it and lay this argument to rest :D
i miss this discussion.
so, having every file (.pd, .pd_linux .dll .pdlua and *-help.pd) in the same directory is ok for me.
The way you distribute a lib should also be related to the way you develop this lib on the svn. so, should the svn be ordered on the same way : every files on the same dir? except for sources and everything that need for compiling externals that could go on a src sub-folder? and also a sub-folder for the examples (that are not help files)?
here is the proposal in question:
http://lists.puredata.info/pipermail/pd-dev/2009-02/013009.html
If you are happy including any externals in the same folder, then do that, you don't need libraries. For me, I would like to be able to easily use externals that have been updated. Yes, fixing bugs can break patches, but that's hardly an argument to stop fixing bugs. Any change in code can break things, shall we just stop changing Pd at all? I think a better solution is to allow a patch to query Pd for the version, then include info about which version that patch was made with. Pd-extended has [version] for that purpose.
about the loading order : is this mandatory to introduce incompatibility between vanilla and extended? changing the loading order in pd-extended may break some patch. this is not a major problem for me since we all can adapt old patch to work with a new software version. But to have different order between vanilla and extended is not really nice.
The idea would be to change vanilla, then extended would inherit it. I also want to avoid a difference here. I think changing the loading order won't change anything in how Pd-vanilla objects are loaded, it might change which objectclass gets loaded in Pd-extended, but that can be checked with a script.
It could change how a patch behaves, but in a way that could happen switching between distros and installations too. Things are so messy now, I don't think it would be wise to keep it that way.
.hc
cyrille
.hc On Feb 23, 2009, at 6:16 PM, cyrille henry wrote:
João Pais a écrit :
-for stability : i don't wish to use code that i don't fully trust, and i don't have time to personally test everything deeply.
Yes, there is definitely some crappy code included in Pd- extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
here here. even if the code gets loaded into memory, as long as there are no nameclashing you shouldn't even notice it (except you're running an installation on a low-end computer and each byte counts, ...)
loading a patch when you have lot's of lib loaded should be slower. but why using pd-extended if you don't need all the lib?
-for simplicity : i think it's more simple to use a limited set of object, than choosing from about 2000 of them.
I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility. Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
and I also think that the redundancy comes also from the fact that there is no object list for pd-ext. no one has the time to search 2xxx objects, so they just program their own.
it's not very hard to look on the svn for a specific object name before writing the same object wih the same name.
-for compatibility : i need to have my patch running on lot's of different computer, using different version of pd, different OS. since pd-extended is not yet the standard pd distribution for anyone, i have to use the minimal set of external. i.e : almost none. (see RJDJ by example)
If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
is pd-ext not the standard version for many reasons more than it isn't maintained by MP, and because it isn't as actual as pd-van?
i just mean pd-extended is not used by anyone.
I don't know about the compatibility issue - you say this because some systems have low resources (like rjdj), or because pd-ext isn't stable in some systems? the 1st makes sense, naturally (also if you get a 10year old computer for an installation, etc.)
everybody use a different set of external. so when you share a patch, you can have problem if someone does not load the lib you're using. look at how many problem send on the pd list is solve via changing pd lib loading preferences.
-for conservation : in 50 years, it will certainly be easier to use a pd patch than a pd-extended patch. at least, it will not be harder. This was true for the last few years since pd extended was not mature until recently.
If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true. AFAIK, this is how Miller bundles his code in PDRP.
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd- vanilla. That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
I think so as well, the builds are a solid package (if the code inside works, like it does in many of the libs). anyway, this discussion (and subsequent actions, if they happen) would be a good step to make pd-ext even more mature. I would think that a small "tester group" to test objects, or to alert developers for good testing + documentation + use of proper formats (for documentation + pdpedia or whatever) would be a good thing. I would be up to give some time for it (can't give much more than that, anyway).
-for new feature : pd-extended is 1 or 2 version late, and new pd feature are usually really nice. by example i deeply use the new pd~ object for a project i'm working on. i don't really know when pd- extended will be in version 0.42.
With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
are there any users that could help HC with the task of putting pd- van and pd-ext at the same level? I guess that the most mature result would be that MP's code would go directly to pd- ext after being tested/released.
-to prevent incompatibility : pd extended does not use transparent object and this does break some of my old patch (when using a canvas and symbol to create some visual feedback). moreover, it's visually ugly.
what do you mean visually ugly? the fonts, or something that can't be adjusted?
i just don't like the not transparent object.
cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Hans-Christoph Steiner a écrit :
On Feb 24, 2009, at 11:49 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
I don't think that Pd-extended is for everyone, that's fine by me. I think its good to have many distros of Pd+libs.
we all agree here.
But what I think is essential is that we have a common library format so that patches made in one distro can be compatible in others.
yes, it is important. but having patch compatible between 2 pd distro require more than just a common lib format.
Yes, but we have to start somewhere.
Saying that you tailor your environment to your patches is not a solution. Then your patches will only work in your custom setups.
yes. my aim is the opposite. starting pd with -noprefs is not really "tailor your environment to your patches" but trying to make your patch to work on all environment.
That is why I think we need to discuss the library format and come up with a format that works for everyone. I posted the idea for a common library format somewhere in this thread. This is an idea that has been formed from the contributions of a number of people, and I think it covers all the concerns that I know of. Please take a look and comment on it, so we can start coding it and lay this argument to rest :D
i miss this discussion.
so, having every file (.pd, .pd_linux .dll .pdlua and *-help.pd) in the same directory is ok for me.
The way you distribute a lib should also be related to the way you develop this lib on the svn. so, should the svn be ordered on the same way : every files on the same dir? except for sources and everything that need for compiling externals that could go on a src sub-folder? and also a sub-folder for the examples (that are not help files)?
here is the proposal in question:
http://lists.puredata.info/pipermail/pd-dev/2009-02/013009.html
this mail is only about pd-extended file organization. i'll be happy to have a svn organization proposition. or did i misunderstand things?
If you are happy including any externals in the same folder, then do that, you don't need libraries. For me, I would like to be able to easily use externals that have been updated. Yes, fixing bugs can break patches, but that's hardly an argument to stop fixing bugs. Any change in code can break things, shall we just stop changing Pd at all? I think a better solution is to allow a patch to query Pd for the version, then include info about which version that patch was made with. Pd-extended has [version] for that purpose.
about the loading order : is this mandatory to introduce incompatibility between vanilla and extended? changing the loading order in pd-extended may break some patch. this is not a major problem for me since we all can adapt old patch to work with a new software version. But to have different order between vanilla and extended is not really nice.
The idea would be to change vanilla, then extended would inherit it.
i certainly miss some discussion here : does miller agree?
I
also want to avoid a difference here.
cool
I think changing the loading order won't change anything in how Pd-vanilla objects are loaded, it might change which objectclass gets loaded in Pd-extended, but that can be checked with a script.
It could change how a patch behaves, but in a way that could happen switching between distros and installations too. Things are so messy now, I don't think it would be wise to keep it that way.
i don't see problem to change pd behaviors from 1 version to an other. but i whish pd and pd-extended to be easily compatible. so, let's go!
Cyrille
.hc
cyrille
.hc On Feb 23, 2009, at 6:16 PM, cyrille henry wrote:
João Pais a écrit :
> -for stability : i don't wish to use code that i don't fully > trust, and i don't have time to personally test everything deeply. Yes, there is definitely some crappy code included in Pd- extended. That's why I think we should stop including anything but the most stable libraries, and instead make it very easy for people to make and install libraries. But one nice thing about using libdirs is that, if you don't use the crappy code, it is just a blob taking up disk space. It is not loaded at all, therefore it won't affect your stability.
here here. even if the code gets loaded into memory, as long as there are no nameclashing you shouldn't even notice it (except you're running an installation on a low-end computer and each byte counts, ...)
loading a patch when you have lot's of lib loaded should be slower. but why using pd-extended if you don't need all the lib?
> -for simplicity : i think it's more simple to use a limited set > of object, than choosing from about 2000 of them. I agree simplicity is good, and there is a lot of redundancy in Pd- extended. The redundancy is mostly for backwards compatibility. Then the other problem is that one person's simple set of objects don't work for someone else. For example, I don't think you ever use creb but for others, that's indispensible.
and I also think that the redundancy comes also from the fact that there is no object list for pd-ext. no one has the time to search 2xxx objects, so they just program their own.
it's not very hard to look on the svn for a specific object name before writing the same object wih the same name.
> -for compatibility : i need to have my patch running on lot's > of different computer, using different version of pd, different > OS. since pd-extended is not yet the standard pd distribution > for anyone, i have to use the minimal set of external. i.e : > almost none. (see RJDJ by example) If you don't use externals at all, then this is true. If you do, then Pd-extended is the most compatible way to use externals.
is pd-ext not the standard version for many reasons more than it isn't maintained by MP, and because it isn't as actual as pd-van?
i just mean pd-extended is not used by anyone.
I don't know about the compatibility issue - you say this because some systems have low resources (like rjdj), or because pd-ext isn't stable in some systems? the 1st makes sense, naturally (also if you get a 10year old computer for an installation, etc.)
everybody use a different set of external. so when you share a patch, you can have problem if someone does not load the lib you're using. look at how many problem send on the pd list is solve via changing pd lib loading preferences.
> -for conservation : in 50 years, it will certainly be easier to > use a pd patch than a pd-extended patch. at least, it will not > be harder. This was true for the last few years since pd > extended was not mature until recently. If you use no externals at all, or you always include every external/ abstraction you use within the project, then this could be true. AFAIK, this is how Miller bundles his code in PDRP.
If you use externals at all, then I disagree here quite strongly. There is no standard way to install or setup externals with Pd- vanilla. That means in 50 years, people will have no idea how you set up your Pd-vanilla + externals. Pd-extended will still be just a package with everything in the right place.
I think so as well, the builds are a solid package (if the code inside works, like it does in many of the libs). anyway, this discussion (and subsequent actions, if they happen) would be a good step to make pd-ext even more mature. I would think that a small "tester group" to test objects, or to alert developers for good testing + documentation + use of proper formats (for documentation + pdpedia or whatever) would be a good thing. I would be up to give some time for it (can't give much more than that, anyway).
> -for new feature : pd-extended is 1 or 2 version late, and new > pd feature are usually really nice. by example i deeply use the > new pd~ object for a project i'm working on. i don't really > know when pd- extended will be in version 0.42. With new features come new bugs, unfortunately, like the editing helper and the pow~/override issue. The latter could cause big problems. But mostly the reason why there is a delay is because there is only so much I can do.
are there any users that could help HC with the task of putting pd- van and pd-ext at the same level? I guess that the most mature result would be that MP's code would go directly to pd-ext after being tested/released.
> -to prevent incompatibility : pd extended does not use > transparent object and this does break some of my old patch > (when using a canvas and symbol to create some visual > feedback). moreover, it's visually ugly.
what do you mean visually ugly? the fonts, or something that can't be adjusted?
i just don't like the not transparent object.
cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
On Feb 25, 2009, at 5:01 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
On Feb 24, 2009, at 11:49 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
I don't think that Pd-extended is for everyone, that's fine by me. I think its good to have many distros of Pd+libs.
we all agree here.
But what I think is essential is that we have a common library format so that patches made in one distro can be compatible in others.
yes, it is important. but having patch compatible between 2 pd distro require more than just a common lib format.
Yes, but we have to start somewhere.
Saying that you tailor your environment to your patches is not a solution. Then your patches will only work in your custom setups.
yes. my aim is the opposite. starting pd with -noprefs is not really "tailor your environment to your patches" but trying to make your patch to work on all environment.
That is why I think we need to discuss the library format and come up with a format that works for everyone. I posted the idea for a common library format somewhere in this thread. This is an idea that has been formed from the contributions of a number of people, and I think it covers all the concerns that I know of. Please take a look and comment on it, so we can start coding it and lay this argument to rest :D
i miss this discussion.
so, having every file (.pd, .pd_linux .dll .pdlua and *-help.pd) in the same directory is ok for me.
The way you distribute a lib should also be related to the way you develop this lib on the svn. so, should the svn be ordered on the same way : every files on the same dir? except for sources and everything that need for compiling externals that could go on a src sub-folder? and also a sub-folder for the examples (that are not help files)?
here is the proposal in question: http://lists.puredata.info/pipermail/pd-dev/2009-02/013009.html
this mail is only about pd-extended file organization. i'll be happy to have a svn organization proposition. or did i misunderstand things?
That thread is about the design of a common library format and search path order.
.hc
If you are happy including any externals in the same folder, then do that, you don't need libraries. For me, I would like to be able to easily use externals that have been updated. Yes, fixing bugs can break patches, but that's hardly an argument to stop fixing bugs. Any change in code can break things, shall we just stop changing Pd at all? I think a better solution is to allow a patch to query Pd for the version, then include info about which version that patch was made with. Pd-extended has [version] for that purpose.
about the loading order : is this mandatory to introduce incompatibility between vanilla and extended? changing the loading order in pd-extended may break some patch. this is not a major problem for me since we all can adapt old patch to work with a new software version. But to have different order between vanilla and extended is not really nice.
The idea would be to change vanilla, then extended would inherit it.
i certainly miss some discussion here : does miller agree?
I
also want to avoid a difference here.
cool
I think changing the loading order won't change anything in how Pd- vanilla objects are loaded, it might change which objectclass gets loaded in Pd-extended, but that can be checked with a script. It could change how a patch behaves, but in a way that could happen switching between distros and installations too. Things are so messy now, I don't think it would be wise to keep it that way.
i don't see problem to change pd behaviors from 1 version to an other. but i whish pd and pd-extended to be easily compatible. so, let's go!
Cyrille
.hc
cyrille
.hc On Feb 23, 2009, at 6:16 PM, cyrille henry wrote:
João Pais a écrit :
>> -for stability : i don't wish to use code that i don't fully >> trust, and i don't have time to personally test everything >> deeply. > Yes, there is definitely some crappy code included in Pd- > extended. That's why I think we should stop including > anything but the most stable libraries, and instead make it > very easy for people to make and install libraries. But one > nice thing about using libdirs is that, if you don't use the > crappy code, it is just a blob taking up disk space. It is > not loaded at all, therefore it won't affect your stability. here here. even if the code gets loaded into memory, as long as there are no nameclashing you shouldn't even notice it (except you're running an installation on a low-end computer and each byte counts, ...)
loading a patch when you have lot's of lib loaded should be slower. but why using pd-extended if you don't need all the lib?
>> -for simplicity : i think it's more simple to use a limited >> set of object, than choosing from about 2000 of them. > I agree simplicity is good, and there is a lot of redundancy > in Pd- extended. The redundancy is mostly for backwards > compatibility. Then the other problem is that one person's > simple set of objects don't work for someone else. For > example, I don't think you ever use creb but for others, > that's indispensible. and I also think that the redundancy comes also from the fact that there is no object list for pd-ext. no one has the time to search 2xxx objects, so they just program their own.
it's not very hard to look on the svn for a specific object name before writing the same object wih the same name.
>> -for compatibility : i need to have my patch running on lot's >> of different computer, using different version of pd, >> different OS. since pd-extended is not yet the standard pd >> distribution for anyone, i have to use the minimal set of >> external. i.e : almost none. (see RJDJ by example) > If you don't use externals at all, then this is true. If you > do, then Pd-extended is the most compatible way to use > externals. is pd-ext not the standard version for many reasons more than it isn't maintained by MP, and because it isn't as actual as pd-van?
i just mean pd-extended is not used by anyone.
I don't know about the compatibility issue - you say this because some systems have low resources (like rjdj), or because pd-ext isn't stable in some systems? the 1st makes sense, naturally (also if you get a 10year old computer for an installation, etc.)
everybody use a different set of external. so when you share a patch, you can have problem if someone does not load the lib you're using. look at how many problem send on the pd list is solve via changing pd lib loading preferences.
>> -for conservation : in 50 years, it will certainly be easier >> to use a pd patch than a pd-extended patch. at least, it >> will not be harder. This was true for the last few years >> since pd extended was not mature until recently. > If you use no externals at all, or you always include every > external/ abstraction you use within the project, then this > could be true. AFAIK, this is how Miller bundles his code > in PDRP. > > If you use externals at all, then I disagree here quite > strongly. There is no standard way to install or setup > externals with Pd- vanilla. That means in 50 years, people > will have no idea how you set up your Pd-vanilla + > externals. Pd-extended will still be just a package with > everything in the right place. I think so as well, the builds are a solid package (if the code inside works, like it does in many of the libs). anyway, this discussion (and subsequent actions, if they happen) would be a good step to make pd-ext even more mature. I would think that a small "tester group" to test objects, or to alert developers for good testing + documentation + use of proper formats (for documentation + pdpedia or whatever) would be a good thing. I would be up to give some time for it (can't give much more than that, anyway). >> -for new feature : pd-extended is 1 or 2 version late, and >> new pd feature are usually really nice. by example i deeply >> use the new pd~ object for a project i'm working on. i >> don't really know when pd- extended will be in version 0.42. > With new features come new bugs, unfortunately, like the > editing helper and the pow~/override issue. The latter > could cause big problems. But mostly the reason why there > is a delay is because there is only so much I can do. are there any users that could help HC with the task of putting pd- van and pd-ext at the same level? I guess that the most mature result would be that MP's code would go directly to pd- ext after being tested/released. >> -to prevent incompatibility : pd extended does not use >> transparent object and this does break some of my old patch >> (when using a canvas and symbol to create some visual >> feedback). moreover, it's visually ugly. what do you mean visually ugly? the fonts, or something that can't be adjusted?
i just don't like the not transparent object.
cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
---------------------------------------------------------------------------- "[T ]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner a écrit : ...
That thread is about the design of a common library format and search path order.
where do you put sources on this lib format?
c
On Feb 25, 2009, at 1:23 PM, cyrille henry wrote:
Hans-Christoph Steiner a écrit : ...
That thread is about the design of a common library format and search path order.
where do you put sources on this lib format?
c
Which sources? Pd, Lua, C, etc.? Pd and Lua the source is the object, with C, it can go wherever.
.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
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it.
I have a similar position. :)
To me the problem of Pd-extended or the reason why I don't use it is because it is not only a collection of externals and abstractions, but it also bundles it with a modified, often out-of-date version of Pd into a big monolithic package.
Ciao
Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it.
I have a similar position. :)
To me the problem of Pd-extended or the reason why I don't use it is because it is not only a collection of externals and abstractions, but it also bundles it with a modified, often out-of-date version of Pd into a big monolithic package.
i guess one of the main reasons for us (the iem) to not use pd-extended is, that it is targeted at people without compilers, whereas we often develop libraries for our projects. (Pd-extended is severely limited in this respect, e.g. the 103MB disk image on OSX comes without g_canvas.h)
fmasd.r IOhannes
yep, when you need to compile some stuff, pd-extended is not really made for you. since i quite often have to use a very recent Gem version for my project, (specially when i correct some Gem bugs when working on this project), i must recompile Gem on the target machine, so using extended is not really easy. using extended is ok when installing a project i made about 1 year ago...
Cyrille
IOhannes m zmoelnig a écrit :
Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it.
I have a similar position. :)
To me the problem of Pd-extended or the reason why I don't use it is because it is not only a collection of externals and abstractions, but it also bundles it with a modified, often out-of-date version of Pd into a big monolithic package.
i guess one of the main reasons for us (the iem) to not use pd-extended is, that it is targeted at people without compilers, whereas we often develop libraries for our projects. (Pd-extended is severely limited in this respect, e.g. the 103MB disk image on OSX comes without g_canvas.h)
fmasd.r IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
that's true, after making the question I thought that mainly the most hardcore guys stick to pd-van, because it's easier for them to adapt it to their needs, and there's more tradition with self-programming (enhancing the core package). but I would dare say that for many non-developper-users, pd-ext is much more used than pd-van. pd-ext is a couple of decimals behind pd-van (and the windows version even more, as the disk for it is out of order since last summer), but HC doesn't have a grant to work on pd-ext.
yep, when you need to compile some stuff, pd-extended is not really made for you. since i quite often have to use a very recent Gem version for my project, (specially when i correct some Gem bugs when working on this project), i must recompile Gem on the target machine, so using extended is not really easy. using extended is ok when installing a project i made about 1 year ago...
On Feb 23, 2009, at 6:38 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it.
I have a similar position. :) To me the problem of Pd-extended or the reason why I don't use it is because it is not only a collection of externals and abstractions, but it also bundles it with a modified, often out-of-date version of Pd into a big monolithic package.
i guess one of the main reasons for us (the iem) to not use pd- extended is, that it is targeted at people without compilers, whereas we often develop libraries for our projects. (Pd-extended is severely limited in this respect, e.g. the 103MB disk image on OSX comes without g_canvas.h)
It would be easy enough to add the headers to the package, feel free to do so. I just assumed that people use the code from SVN since I think that's easier.
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
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 educational ones?].
we at the iem are using pd-vanilla exclusively for both artistic and research projects, on various scales.
of course we are using externals, but we definitely do not use Pd-extended. And we don't see any reason to change this in the future (so far, Pd-extended is incompatible with our workflow; which is not necessarily a fault on pdx's side; but we are happy as it is)
fgmadsrt IOhannes
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 chicken language: http://plif.courageunfettered.com/archive/wc072.gif
malkovich malkovich malkovich: http://www.youtube.com/watch?v=OIUWGQMOVJ4
schtroumpf dialects: http://damienmarcellin.canalblog.com/images/Schtroumpf_vert_1.JPG
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
http://uncyclopedia.wikia.com/wiki/AAAAAAAAA!
On Wed, 18 Feb 2009 13:55:42 -0500 (EST) Mathieu Bouchard matju@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 chicken language: http://plif.courageunfettered.com/archive/wc072.gif
malkovich malkovich malkovich: http://www.youtube.com/watch?v=OIUWGQMOVJ4
schtroumpf dialects: http://damienmarcellin.canalblog.com/images/Schtroumpf_vert_1.JPG
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Wed, Feb 18, 2009 at 1:55 PM, Mathieu Bouchard matju@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 chicken language: http://plif.courageunfettered.com/archive/wc072.gif
malkovich malkovich malkovich: http://www.youtube.com/watch?v=OIUWGQMOVJ4
schtroumpf dialects: http://damienmarcellin.canalblog.com/images/Schtroumpf_vert_1.JPG
Chicken put to use http://isotropic.org/papers/chicken.pdf
Simplify! http://www.horus.at/~charlie/tuni/simplify.pdf
Menu On our menu tonight, our special is cooked animal with sauce.
Etc.
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 nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Wed, 18 Feb 2009, Matt Barber wrote:
On Wed, Feb 18, 2009 at 1:55 PM, Mathieu Bouchard matju@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 to use http://isotropic.org/papers/chicken.pdf
Actually, I should've replied with this instead:
http://www.literaberinto.com/vueltamundo/bibliotecaborges.htm
also available in English as:
http://jubal.westnet.com/hyperdiscordia/library_of_babel.html
I dare anyone of you to find the amount of information (Shannon's theory) in that library considering 1312000 characters per book (let's say exactly) and neglecting the book titles, if the books are placed purely randomly (apparently, they aren't completely, in that story).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Wed, 18 Feb 2009, IOhannes m zmoelnig wrote:
the only library that i am aware of that did override internal classes is cyclone, and krzysztof did some awful work fuddling with the classtable of pd_objectmaker. i think the code is in the "fragile" (sic!) part of cyclone.
GridFlow also overrides [print] because of the additional atomtypes that GridFlow can't register into Pd and that makes Pd behave funny when it's trying to print them, among other funny things.
But IMHO it wouldn't be much of an issue if I fixed any undesirable divergences in GridFlow's [print]. In that case, the problem would be that it uses t_class and t_methodentry, but much of the Pd community relies on externals that uses forbidden interfaces anyway.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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.
cyrille
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]? it is still here,
oops, nobody told me yet :-) i have hopefully fixed it now...
and it is still breaking my patch.
how's that? i would be interested in a patch demonstrating this breakage.
fgamr IOhannes
here is a patch that work with vanilla, but not with zexy unpack.
thanks for removing it. i can now load zexy. fortunately, 95% of my patch does only use vanilla pd, Gem and pmpd...
cyrille
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]? it is still here,
oops, nobody told me yet :-)
don't you use it?
i have hopefully fixed it now...
and it is still breaking my patch.
how's that? i would be interested in a patch demonstrating this breakage.
fgamr IOhannes
#N canvas 0 0 450 300 10; #X obj 111 74 unpack s s; #X msg 111 47 foo bar; #X obj 111 128 print; #X connect 0 0 2 0; #X connect 0 1 2 0; #X connect 1 0 0 0;
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
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]? it is still here,
oops, nobody told me yet :-) i have hopefully fixed it now...
hum. just svn update / make clean / make and i still have this when loading zexy :
warning: class 'abs~' overwritten; old one renamed 'abs~_aliased' matchbox: OSC-pattern matching code (c) Matt Wright, CNMAT warning: class 'unpack' overwritten; old one renamed 'unpack_aliased' warning: class 'wrap' overwritten; old one renamed 'wrap_aliased'
so, it look like unpack is still here. c
and it is still breaking my patch.
how's that? i would be interested in a patch demonstrating this breakage.
fgamr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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
On Wed, 18 Feb 2009, IOhannes m zmoelnig wrote:
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.
funny, I'd have just assumed that class_new would be implemented by calling class_addcreator, but the assumption is wrong as in the end it's a copy-paste. (well, i'm looking at 0.40 now... i suppose it got changed in both places in 0.42 ?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Wed, 2009-02-18 at 20:19 +0100, IOhannes m zmoelnig wrote:
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]? it is still here,
oops, nobody told me yet :-) i have hopefully fixed it now...
and it is still breaking my patch.
how's that? i would be interested in a patch demonstrating this breakage.
IOhannes, thanks a lot for the explanation in previous mails about how fuddling was needed in previous version of pd and isn't anymore in 0.42. this explainy why suddenly [pack] and [unpack] of zexy overwrite the versions of pd. i think, this makes all sense to me now.
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 work with the zexy [unpack]: it complains: no method for 'bla'.
this again raises the question: should zexy's [unpack] mimick the the funny behaviours of pd's [unpack]? i am undecided here. personally i think, that it was a bad choice to call it [unpack] after all.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 work with the zexy [unpack]: it complains: no method for 'bla'.
this again raises the question: should zexy's [unpack] mimick the the funny behaviours of pd's [unpack]? i am undecided here.
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)?
the help-patch clearly speaks of "lists of atoms", but doesn't mention other messages at all.
mfgas.dr IOhannes
IOhannes m zmoelnig a écrit :
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 work with the zexy [unpack]: it complains: no method for 'bla'.
this again raises the question: should zexy's [unpack] mimick the the funny behaviours of pd's [unpack]? i am undecided here.
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)?
do you mean that [list foo bar( would have work as i expected?
if sending [foo bar( is considered as a bug in the patch, why should zexy's unpack be less tolerant than vanilla unpack?
if the fix is as simple as inserting a [list] object before unpack, maybe in this situation, zexy unpack should have a more verbose error, and suggest the solution (inserting a list objet).
cyrille
the help-patch clearly speaks of "lists of atoms", but doesn't mention other messages at all.
mfgas.dr IOhannes
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 a circuit-bending attitude and without a spec, features and bugs often can't be told apart.
the help-patch clearly speaks of "lists of atoms", but doesn't mention other messages at all.
So why does the pd source spend 12 lines defining pack_anything ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Feb 18, 2009, at 7:03 PM, Roman Haefeli wrote:
On Wed, 2009-02-18 at 20:19 +0100, IOhannes m zmoelnig wrote:
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]? it is still here,
oops, nobody told me yet :-) i have hopefully fixed it now...
and it is still breaking my patch.
how's that? i would be interested in a patch demonstrating this breakage.
IOhannes, thanks a lot for the explanation in previous mails about how fuddling was needed in previous version of pd and isn't anymore in 0.42. this explainy why suddenly [pack] and [unpack] of zexy overwrite the versions of pd. i think, this makes all sense to me now.
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 work with the zexy [unpack]: it complains: no method for 'bla'.
this again raises the question: should zexy's [unpack] mimick the the funny behaviours of pd's [unpack]? i am undecided here. personally i think, that it was a bad choice to call it [unpack] after all.
Zexy's unpack/pack is how the original should have worked, IMHO. They have very useful functionality, but they should have different names so that they can be used more easily in Pd. How about:
packlist/unpacklist zexypack/zexyunpack bundle/unbundle group/ungroup makelist/splitlist
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
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 library, or less drastically patch both cyclone and vanilla pow~ to throw a warning, as was discussed last april?
This is not related to Pd-extended which AFAIK doesn't include cyclone as a library (a "-lib" loadable one), but when loaded as a lib, Cyclone does some magic to even overwrite Pd internals. I made a little check now and actually Cyclone then is very smart and aliasses the builtins to different names.
Cyclone in pd-extended is just a libdir library of Max/MSP compatible objectclasses. When cyclone is built as one big library in one file, then there are some extra Max/MSP compatibility features. If someone added the cyclone.pd_linux creation to the Pd-extended build system, then this would also be included.
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.
.hc
Running "pd-0.42 -lib cyclone" gives this:
... warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' ...
and now the [pow~] behaves like in Max, while [pow~_aliased] is the new pow~ from 0.42. That's pretty cool, actually.
Unfortunatly you cannot use the other cyclone objects without rewriting [pow~] when cyclone is loaded as a library.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
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
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 of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base.
In my view -- this is an open-source program which is more or less guaranteed to evolve. If your patch breaks with a new version, use an older version, or find and fix the problems in the patch. To me it is a problem to avoid improvements to the language to maintain backward compatibility at all costs, and much better to throw warnings -- "Warning: your patch might be broken: look for all instances of pow~. Thank you." =o)
The best solution in any of these circumstances is the least worst solution. As far as I can tell the least worst solution is the one with the most patch-level control for the libraries. As a user I would rather do the research to see which externals I needed than to be forced into accepting one or the other, ESPECIALLY if vanilla classes are overwritten -- this seems the most egregious to me. Pd+libs and Pd-extended should support vanilla patching, since many users insist upon vanilla only -- worrying about cyclone and allowing vanilla to break seems to me to be putting the cart before the horse with regard to backward compatibility. Pd is not Max/MSP. Should you really have to import vanilla?
Thanks,
Matt
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 obvious breach of style should be allowed to bully the rest of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base.
Cyclone's overriding is pretty important for importing Max files. Without it I wouldn't have been able to port the RTC library that fast. Of course porting RTC involved replacing many objects with their Pd equivalents (and being a pd-vanilla fanboy, I mostly used builtins and abstractions for that). Other users may be fine with keeping Cyclone loaded and run the Max originals - freedom of choice is fine here.
Ciao
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 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 of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base.
Cyclone's overriding is pretty important for importing Max files.
but it obviously doesn't work on pd extended. so lets just skip that one.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 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 of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base.
Cyclone's overriding is pretty important for importing Max files.
but it obviously doesn't work on pd extended. so lets just skip that one.
it should now, I added the 'cyclone' and 'maxmode' objects to Pd- extended last night. I didn't really test it much though.
.hc
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
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 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 of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base.
Cyclone's overriding is pretty important for importing Max files. Without it I wouldn't have been able to port the RTC library that fast.
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.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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 pow~?
Because of the reversed inlets you cannot use the buildin pow~ when importing Max-patches without breaking the patch.
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 use that instead when importing.
I suppose the connection-mangling is not trivial to write and as only this one object is affected, it may be easier to just do it manually when needed. The feature, that Pd now reports overwritten classes is very useful for spotting such differences.
Ciao
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 use that instead when importing.
I suppose the connection-mangling is not trivial to write and as only this one object is affected, it may be easier to just do it manually when needed. The feature, that Pd now reports overwritten classes is very useful for spotting such differences.
This is now two separate but related issues:
1) Importing max/MSP into Pd + cyclone
2) Maintaining backwards compatibility for Pd patches written in Pd + cyclone
The differences are not trivial. If it were just importing max files, then the problem is now in the translator, and the obvious solutions in my opinion are the ones you just mentioned.
But that would break files that were patched in earlier versions of Pd+cyclone in the first place. In this case, I think that [pow~] should throw a warning for a while. And because Pd has a "find" feature it will not be difficult to find instances of pow~ and change the connections, or to make a little abstraction with crossed inlet~s called max_pow~ or whatever you like and then find and replace. Cyclone could even come with another utility to do this automatically -- anyway I think backward-compatibility is the lib's responsibility, not Pd's.
Matt
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 why I brought this topic up and asked: What to do about pow~?
Because of the reversed inlets you cannot use the buildin pow~ when importing Max-patches without breaking the patch.
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 use that instead when importing.
This breaks old patches that rely on cyclone's [pow~]. This is a problem that many people have addressed in languages like python, java, ruby, etc. The solutions generally look very similar, from what I have seen, so I think we should learn from their experience.
The last major piece of the puzzle is making loaded binary objectclass names be in the canvas-local namespace, just like abstractions are now. Unfortunately, that's not so easy to write. But I think its the right thing to do.
.hc
I suppose the connection-mangling is not trivial to write and as only this one object is affected, it may be easier to just do it manually when needed. The feature, that Pd now reports overwritten classes is very useful for spotting such differences.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
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
Cyclone's overriding is pretty important for importing Max files. Without it I wouldn't have been able to port the RTC library that fast. Of course porting RTC involved replacing many objects with their Pd equivalents (and being a pd-vanilla fanboy, I mostly used builtins and abstractions for that). Other users may be fine with keeping Cyclone loaded and run the Max originals - freedom of choice is fine here.
If freedom of choice is a goal, then maybe the behavior should be user-configurable with a flag, allowing one to keep builtin names and use aliases for any conflicting lib classes, OR use the lib's class names and make aliases for builtins. Either could be the default as long as it's documented.
Matt
On Feb 17, 2009, at 11:17 AM, Matt Barber wrote:
Cyclone's overriding is pretty important for importing Max files. Without it I wouldn't have been able to port the RTC library that fast. Of course porting RTC involved replacing many objects with their Pd equivalents (and being a pd-vanilla fanboy, I mostly used builtins and abstractions for that). Other users may be fine with keeping Cyclone loaded and run the Max originals - freedom of choice is fine here.
If freedom of choice is a goal, then maybe the behavior should be user-configurable with a flag, allowing one to keep builtin names and use aliases for any conflicting lib classes, OR use the lib's class names and make aliases for builtins. Either could be the default as long as it's documented.
You can already do this: just load the libraries you want in the order you want, and save your preferences. Then your patches will likely break on other people's machines.
The aliasing thing could work, you could try coding it up and testing it. That's really the next step. I am going to dig up my old proposals and clean it up for how I intend on coding an attempt at a solution to this problem. Once we have code to test, the issues and solutions become much clearer.
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 shared code for objectclasses in library - check for objectclasses in paths in same order for any implementation method - one objectclass per file - help patch in same folder as objectclass file
- search "." first, then canvas-local paths, then global paths
- search using registered loaders (i.e. implementation langauges) one dir at a time: - first search "." for .pd .pd_linux .pdlua etc. - then search first dir in canvas-local path for .pd .pd_linux .pdlua etc. - then search second dir in canvas-local path for .pd .pd_linux .pdlua etc. - ... - then search first dir in global path for .pd .pd_linux .pdlua etc. - then search second dir in global path for .pd .pd_linux .pdlua etc. - ...
- the loaded class names should follow the above rules of loading classes
- namespace prefixes stay as part of classname and do not load basename - i.e. [cyclone/pow~] does not claim the name [pow~]
.hc
Matt
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
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 shared code for objectclasses in library
- check for objectclasses in paths in same order for any
implementation method
one objectclass per file
help patch in same folder as objectclass file
search "." first, then canvas-local paths, then global paths
search using registered loaders (i.e. implementation langauges) one
dir at a time:
- first search "." for .pd .pd_linux .pdlua etc.
- then search first dir in canvas-local path for .pd .pd_linux .pdlua
etc.
- then search second dir in canvas-local path
for .pd .pd_linux .pdlua etc.
...
then search first dir in global path for .pd .pd_linux .pdlua etc.
then search second dir in global path for .pd .pd_linux .pdlua etc.
...
the loaded class names should follow the above rules of loading
classes
- namespace prefixes stay as part of classname and do not load basename
- i.e. [cyclone/pow~] does not claim the name [pow~]
i rather don't want this to drip away into the deep ocean of pd list discussions.
this sounds very reasonable to me and (please correct me) it would address most problems, that are currently in discussion. i kind of feel to be the wrong person to say that, since i haven't contributed code-wise to all those ideas, but i think it would be good to stick that on a wikipage (dev section on puredata.info?), if people agree on those 'guidelines'.
i hope to see more comments on this....
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Feb 19, 2009, at 6:26 PM, Roman Haefeli wrote:
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 shared code for objectclasses in library
- check for objectclasses in paths in same order for any
implementation method
one objectclass per file
help patch in same folder as objectclass file
search "." first, then canvas-local paths, then global paths
search using registered loaders (i.e. implementation langauges) one
dir at a time:
- first search "." for .pd .pd_linux .pdlua etc.
- then search first dir in canvas-local path
for .pd .pd_linux .pdlua etc.
- then search second dir in canvas-local path
for .pd .pd_linux .pdlua etc.
- ...
- then search first dir in global path for .pd .pd_linux .pdlua etc.
- then search second dir in global path for .pd .pd_linux .pdlua
etc.
...
the loaded class names should follow the above rules of loading
classes
- namespace prefixes stay as part of classname and do not load
basename
- i.e. [cyclone/pow~] does not claim the name [pow~]
i rather don't want this to drip away into the deep ocean of pd list discussions.
this sounds very reasonable to me and (please correct me) it would address most problems, that are currently in discussion. i kind of feel to be the wrong person to say that, since i haven't contributed code-wise to all those ideas, but i think it would be good to stick that on a wikipage (dev section on puredata.info?), if people agree on those 'guidelines'.
i hope to see more comments on this....
roman
Hey,
Thanks for the feedback, I hope there will be more discussion over it. Just to be clear, I am not claiming that I came up with all those ideas, it is a collection of ideas from many people that has been developed over time.
I was hoping to get this all implemented in Pd-extended 0.41.4, but it'll require quite a bit of code, and probably a lot more testing to make sure that new bugs aren't introduced. This might break some patches that rely on the current loading order, which is different than described. Right now it searches by file type through all the paths, which is the opposite of what is outlined above. so like this:
- search for foo.pd_linux in "." - search for foo.pd_linux in first dir of path - search for foo.pd_linux in second dir of path - ... - search for foo.pd in "." - search for foo.pd in first dir of path - search for foo.pd in second dir of path - ...
The current setup means that you can override a pd-vanilla abstraction using a binary class in ".", but you can't override a pd_vanilla binary using an abstraction in "." That seems to treat .pd objectclasses as second class classes and I don't like that ;)
.hc
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
----------------------------------------------------------------------------
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
Hans-Christoph Steiner wrote:
The current setup means that you can override a pd-vanilla abstraction using a binary class in ".", but you can't override a pd_vanilla binary using an abstraction in "." That seems to treat .pd objectclasses as second class classes and I don't like that ;)
well, additional loaders are somewhere inbetween. e.g. .pdlua in path1 will override .pd in path0 but will be overridden by .pd_linux in path2. which makes .pd a 3rd class citizen and .pdlua a 2nd class citizen.
personally i think this is something i can live with. what bothers me more is that .pd classes cannot "bypass" the loader-mechanism (by registering the class).
fmga.sdr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The current setup means that you can override a pd-vanilla abstraction using a binary class in ".", but you can't override a pd_vanilla binary using an abstraction in "." That seems to treat .pd objectclasses as second class classes and I don't like that ;)
well, additional loaders are somewhere inbetween. e.g. .pdlua in path1 will override .pd in path0 but will be overridden by .pd_linux in path2. which makes .pd a 3rd class citizen and .pdlua a 2nd class citizen.
personally i think this is something i can live with. what bothers me more is that .pd classes cannot "bypass" the loader-mechanism (by registering the class).
Maybe compare with the abstraction cache patch I wrote a while ago, that has a similar observable result as a side-effect.
http://lists.puredata.info/pipermail/pd-dev/2008-10/012334.html
Claude
Claude Heiland-Allen wrote:
Maybe compare with the abstraction cache patch I wrote a while ago, that has a similar observable result as a side-effect.
http://lists.puredata.info/pipermail/pd-dev/2008-10/012334.html
yes something like this. i would even prefer it if this was a proper "loader".
of course it could look for changes of the patch on the filesystem (before reusing the cache)
we could then add methods to the objectmaker to delete a certain class from it's "cache" (not the abstraction cache, but the class registry), or whatever.
g asdr# IOhannes
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 obvious breach of style should be allowed to bully the rest of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base.
In my view -- this is an open-source program which is more or less guaranteed to evolve. If your patch breaks with a new version, use an older version, or find and fix the problems in the patch. To me it is a problem to avoid improvements to the language to maintain backward compatibility at all costs, and much better to throw warnings -- "Warning: your patch might be broken: look for all instances of pow~. Thank you." =o)
The best solution in any of these circumstances is the least worst solution. As far as I can tell the least worst solution is the one with the most patch-level control for the libraries. As a user I would rather do the research to see which externals I needed than to be forced into accepting one or the other, ESPECIALLY if vanilla classes are overwritten -- this seems the most egregious to me. Pd+libs and Pd-extended should support vanilla patching, since many users insist upon vanilla only -- worrying about cyclone and allowing vanilla to break seems to me to be putting the cart before the horse with regard to backward compatibility. Pd is not Max/MSP. Should you really have to import vanilla?
Thanks,
yo.. i very much agree with you. isn't it the wrong approach to use so many tricks and kludges just to keep backwards compatibility? isn't that just a too expensive goal?
i mean, there have been so many discussions about how to load libraries, extend namespaces and such and then there is much not working yet, respectively there are still a lot of incompatibilies between pd-extended and pd vanilla, is it wise to introduce _now_ such a feature? for me it is clearly another step away from a more consistent pd world. and i am a bit confused to see, that this is done deliberately.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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.
Okay. But I don't see why something that is a rather obvious breach of style should be allowed to bully the rest of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base.
In my view -- this is an open-source program which is more or less guaranteed to evolve. If your patch breaks with a new version, use an older version, or find and fix the problems in the patch. To me it is a problem to avoid improvements to the language to maintain backward compatibility at all costs, and much better to throw warnings -- "Warning: your patch might be broken: look for all instances of pow~. Thank you." =o)
The best solution in any of these circumstances is the least worst solution. As far as I can tell the least worst solution is the one with the most patch-level control for the libraries. As a user I would rather do the research to see which externals I needed than to be forced into accepting one or the other, ESPECIALLY if vanilla classes are overwritten -- this seems the most egregious to me. Pd+libs and Pd-extended should support vanilla patching, since many users insist upon vanilla only -- worrying about cyclone and allowing vanilla to break seems to me to be putting the cart before the horse with regard to backward compatibility. Pd is not Max/MSP. Should you really have to import vanilla?
Thanks,
yo.. i very much agree with you. isn't it the wrong approach to use so many tricks and kludges just to keep backwards compatibility? isn't that just a too expensive goal?
i mean, there have been so many discussions about how to load libraries, extend namespaces and such and then there is much not working yet, respectively there are still a lot of incompatibilies between pd-extended and pd vanilla, is it wise to introduce _now_ such a feature? for me it is clearly another step away from a more consistent pd world. and i am a bit confused to see, that this is done deliberately.
roman
I don't know of any incompatibilities between Pd-vanilla and Pd- extended in this regard. The incompability here is between the old cyclone pow~ which has been around for a long time, and Pd-vanilla 0.42's pow~. In the bigger sense, the library incompatibilities between Pd-extended and some builds of Pd-vanilla come from the different library formats. If you build Pd-vanilla with the same library format at Pd-extended, then it'll all be compatible. There isn't a standard way to include libraries in Pd-vanilla, so there are bound to be incompatibilities between different installations.
Try it yourself:
http://autobuild.puredata.info/auto-build/latest/Pd-0.42.4-vanilla+libs-debi...
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
I totally agree with this point , I think it's one of the most important thing to care about. loic
As a user I would rather do the research to see which externals I needed than to be forced into accepting one or the other, ESPECIALLY if vanilla classes are overwritten -- this seems the most egregious to me. Pd+libs and Pd-extended should support vanilla patching, since many users insist upon vanilla only -- worrying about cyclone and allowing vanilla to break seems to me to be putting the cart before the horse with regard to backward compatibility.
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, such that the user (at any level) actually can preform the action 'use an older version'.
(end of rant - i.e. i know "freedom" will make sure that never happens)
zexy flatspace?
none?
c
Hans-Christoph Steiner a écrit :
Hey,
Right now, Pd-extended is loading a lot of libraries by default. Most people never used most of those libraries, so I think it makes sense to reduce that number to move towards the goal of having the library loading embedded in the patch itself.
So the question now is, which libraries should stay in for now, to ease the transition? Here's the current list in the order they are loaded:
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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Or does it even make sense to do it in stages?
.hc
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sun, 2009-02-15 at 23:52 -0500, Hans-Christoph Steiner wrote:
Hey,
Right now, Pd-extended is loading a lot of libraries by default. Most people never used most of those libraries, so I think it makes sense to reduce that number to move towards the goal of having the library loading embedded in the patch itself.
So the question now is, which libraries should stay in for now, to ease the transition? Here's the current list in the order they are loaded:
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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
why? any list of libraries, that are loaded on default, seems arbitrary to me. who makes that decisions? what reasons for?
what about loading no libs at all?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part? Do I understand you correctly that you want to restructure the whole library mess? maybe you should just go for one big lib called extended then, that includes everything that is not really related to special libraries like gem or pdp. I would support a public decision making process that votes nameclashing objects in or out to extended. but the most important thing is to document what's inside. then people can reference to that set of object classes and deal with exceptions.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
btw, does the number of loaded libraries/object classes influence the startup time of patches?
marius.
2009/2/16 Hans-Christoph Steiner hans@eds.org:
Hey,
Right now, Pd-extended is loading a lot of libraries by default. Most people never used most of those libraries, so I think it makes sense to reduce that number to move towards the goal of having the library loading embedded in the patch itself.
So the question now is, which libraries should stay in for now, to ease the transition? Here's the current list in the order they are loaded:
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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Or does it even make sense to do it in stages?
.hc
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part?
i think, noone wanted to strip down anything. this is only about not loading the whole bunch of libs automatically anymore. how does that make pd-extended less 'extended'?
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
can you elaborate that a bit? to me it looks perfectly normal, that i have to at least call the tools, that i am going to use.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part?
i think, noone wanted to strip down anything. this is only about not loading the whole bunch of libs automatically anymore. how does that make pd-extended less 'extended'?
first, I think there is a difference between a "user" user (who downloads a patch) and a "patching" user. I always saw pd-extended as a consensual (ok, proposed actually by only one person) agreement on a set of object classes that are available in addition to pd vanilla. It was a way to make sure that if a "patcher" programs a patch for pd-extended that every other pd-extended "user" will have the same setup and thus be able to open the patch without errors. if you leave the loading of external(librarie)s to the user user, that means, if you allow/force the user to create his/her own order of startup libs, you cannot count on this behaviour anymore.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
can you elaborate that a bit? to me it looks perfectly normal, that i have to at least call the tools, that i am going to use.
ok. this is a problem of software architecture. where to draw the border between what is "given" and what is open. to me object classes should be part of the given world, because one, it makes coding, teaching, deploying easier, if all patchers were using the same set of tools and two, if you create your own screws, then you also have to ship the screw drivers (not only declare them).
I know the pd concept is, not to insist on a predefined set of object classes, which of course makes pd more extendible, but with this huge overhead of having to hassle with declarations, namespaces, which are ok for written programming languages, but maybe not for a building block programming tool like pd.
especially if - like in the case of the pd externals - the libraries are arbitrary. (like any categorization system). they are not sorted by topics but rather by coders. just think, a new pd patcher has to learn that an object was programmed by IOhannes, and therefor it is in the zexy library. another one was programmed by someone at the IEM, therefore it is part of the iemlib. furthermore the name of the libraries can change, the same code can become part of two different libraries and some objects do not even belong to a library. if you are consequent in providing your tools, it means that you have to ship the particular pd externals together with your patch everytime you want to share a patch. because then referring to zexy is not enough either, someone else could create a concurring external library also called zexy. then what...
plus, not agreeing on the toolset (set of object names) will always cause your own abstractions to be potentially overwritten by internal/external object classes, which get loaded instead.
plus, with some objects it is necessary to load them in advance, for example all objects with abbreviations, or some objects that enable special features (like the loader for luascripts).
pd is *not* like c, c++, java, these languages create applications, but the way I would like to see pd is, that pd programmers don't create standalone pd versions, but only pd patches.
plus, don't expect (pd-x) patchers ever to declare all objectclasses that they're using.
I hate to say this, but standards and specifications can really make life easier. the habit to leave many things opens allows people to addon a lot of crazy stuff, but it is counterproductive from the viewpoint of patch sharing.
marius.
On Tue, 2009-02-17 at 23:30 +0100, marius schebella wrote:
Roman Haefeli wrote:
On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part?
i think, noone wanted to strip down anything. this is only about not loading the whole bunch of libs automatically anymore. how does that make pd-extended less 'extended'?
first, I think there is a difference between a "user" user (who downloads a patch) and a "patching" user.
i think you cannot design a language based on the distinction between several kinds of user groups. the overall goal should be consistency and i think, what is consistent is the most easy to learn, for_ anyone_. consistency makes it easy for the programmers to program patches and at the same time 'patch musicians' can rely on those patches to work smoothly. what consistency means in pd world does not seem to be so clear yet, though, but that is why all this talk is necessary.
I always saw pd-extended as a consensual (ok, proposed actually by only one person) agreement on a set of object classes that are available in addition to pd vanilla. It was a way to make sure that if a "patcher" programs a patch for pd-extended that every other pd-extended "user" will have the same setup and thus be able to open the patch without errors. if you leave the loading of external(librarie)s to the user user, that means, if you allow/force the user to create his/her own order of startup libs, you cannot count on this behaviour anymore.
right. however, in the ideal pd world (it's not there yet, but i guess it is going there) the loading order wouldn't matter, because everything would be loaded only canvas-locally.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
can you elaborate that a bit? to me it looks perfectly normal, that i have to at least call the tools, that i am going to use.
ok. this is a problem of software architecture. where to draw the border between what is "given" and what is open. to me object classes should be part of the given world, because one, it makes coding, teaching, deploying easier, if all patchers were using the same set of tools and two, if you create your own screws, then you also have to ship the screw drivers (not only declare them).
I know the pd concept is, not to insist on a predefined set of object classes, which of course makes pd more extendible, but with this huge overhead of having to hassle with declarations, namespaces, which are ok for written programming languages, but maybe not for a building block programming tool like pd.
especially if - like in the case of the pd externals - the libraries are arbitrary. (like any categorization system). they are not sorted by topics but rather by coders. just think, a new pd patcher has to learn that an object was programmed by IOhannes, and therefor it is in the zexy library. another one was programmed by someone at the IEM, therefore it is part of the iemlib. furthermore the name of the libraries can change, the same code can become part of two different libraries and some objects do not even belong to a library. if you are consequent in providing your tools, it means that you have to ship the particular pd externals together with your patch everytime you want to share a patch. because then referring to zexy is not enough either, someone else could create a concurring external library also called zexy. then what...
plus, not agreeing on the toolset (set of object names) will always cause your own abstractions to be potentially overwritten by internal/external object classes, which get loaded instead.
plus, with some objects it is necessary to load them in advance, for example all objects with abbreviations, or some objects that enable special features (like the loader for luascripts).
pd is *not* like c, c++, java, these languages create applications, but the way I would like to see pd is, that pd programmers don't create standalone pd versions, but only pd patches.
plus, don't expect (pd-x) patchers ever to declare all objectclasses that they're using.
I hate to say this, but standards and specifications can really make life easier. the habit to leave many things opens allows people to addon a lot of crazy stuff, but it is counterproductive from the viewpoint of patch sharing.
yo.. i think, you made your point very clear. and generally, i agree very much with you. honestly, i would be very fine with everyone only using pd-extended with the exact same path settings and library order. if that would be, what everyone would agree on, i could perfectly live without namespaces and without the need to declare classes. however, people on this list seem to agree, that it is by design not the best way to assume, what is best for the user, but let the users decide themselves. it seems unlikely that everyone is going to switch to pd-extended soon and quite some people only install what they think they need. so after all, declaring classes seems the only way to handle those cases and there seems to be a consensus about it. i even think, that besides all conceptional reasons, the fact, that there seems to be a consensus in the pd community is actually the strong point. i guess, it is one of the few things, that so many people agree on.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
wrt the user/patcher distinction: ok, let's not differentiate bet. these two. but differentiate between a scenario where you only share patches and abstractions vs. a scenario where you also share library binaries. the first calls for a standardized set of object classes (which does not exist - yet?). with the use of declarations you expect a standardized set of available libraries. but this is future telling, too. to have persistent sharing of pd patches, you either have to agree on a set of object classes or always ship the pd version and libraries. again. declare -lib zexy is also only based on the assumption that we are talking about the same zexy library. this assumption really is not much different than the assumption that we are talking about the same [gate] object class...
wrt pd-extended my perception is that the vast majority of pd users use extended. but you are right, there are a lot of situations, where pdx is problematic (the license, then the long startup times(?), some objects (pdj) incompatible...)
wrt to the unsolved object class/library situation if we start declaring every object class that we use, then doesn't that mean that we should also separate the pd kernel from the object classes that ship with pd (vanilla) and load -lib vanilla as a (first?) set of available objects? the next thing I would strongly propose is a restructuring of the libraries into thematical collections. and then deal with the question, if we need libraries at all, why not go with single externals and declare each of them separately.
pd is so much like the real world, unfinished:open imperfect:exciting software:hardware:people:life.
marius.
Roman Haefeli wrote:
On Tue, 2009-02-17 at 23:30 +0100, marius schebella wrote:
Roman Haefeli wrote:
On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part?
i think, noone wanted to strip down anything. this is only about not loading the whole bunch of libs automatically anymore. how does that make pd-extended less 'extended'?
first, I think there is a difference between a "user" user (who downloads a patch) and a "patching" user.
i think you cannot design a language based on the distinction between several kinds of user groups. the overall goal should be consistency and i think, what is consistent is the most easy to learn, for_ anyone_. consistency makes it easy for the programmers to program patches and at the same time 'patch musicians' can rely on those patches to work smoothly. what consistency means in pd world does not seem to be so clear yet, though, but that is why all this talk is necessary.
I always saw pd-extended as a consensual (ok, proposed actually by only one person) agreement on a set of object classes that are available in addition to pd vanilla. It was a way to make sure that if a "patcher" programs a patch for pd-extended that every other pd-extended "user" will have the same setup and thus be able to open the patch without errors. if you leave the loading of external(librarie)s to the user user, that means, if you allow/force the user to create his/her own order of startup libs, you cannot count on this behaviour anymore.
right. however, in the ideal pd world (it's not there yet, but i guess it is going there) the loading order wouldn't matter, because everything would be loaded only canvas-locally.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
can you elaborate that a bit? to me it looks perfectly normal, that i have to at least call the tools, that i am going to use.
ok. this is a problem of software architecture. where to draw the border between what is "given" and what is open. to me object classes should be part of the given world, because one, it makes coding, teaching, deploying easier, if all patchers were using the same set of tools and two, if you create your own screws, then you also have to ship the screw drivers (not only declare them).
I know the pd concept is, not to insist on a predefined set of object classes, which of course makes pd more extendible, but with this huge overhead of having to hassle with declarations, namespaces, which are ok for written programming languages, but maybe not for a building block programming tool like pd.
especially if - like in the case of the pd externals - the libraries are arbitrary. (like any categorization system). they are not sorted by topics but rather by coders. just think, a new pd patcher has to learn that an object was programmed by IOhannes, and therefor it is in the zexy library. another one was programmed by someone at the IEM, therefore it is part of the iemlib. furthermore the name of the libraries can change, the same code can become part of two different libraries and some objects do not even belong to a library. if you are consequent in providing your tools, it means that you have to ship the particular pd externals together with your patch everytime you want to share a patch. because then referring to zexy is not enough either, someone else could create a concurring external library also called zexy. then what...
plus, not agreeing on the toolset (set of object names) will always cause your own abstractions to be potentially overwritten by internal/external object classes, which get loaded instead.
plus, with some objects it is necessary to load them in advance, for example all objects with abbreviations, or some objects that enable special features (like the loader for luascripts).
pd is *not* like c, c++, java, these languages create applications, but the way I would like to see pd is, that pd programmers don't create standalone pd versions, but only pd patches.
plus, don't expect (pd-x) patchers ever to declare all objectclasses that they're using.
I hate to say this, but standards and specifications can really make life easier. the habit to leave many things opens allows people to addon a lot of crazy stuff, but it is counterproductive from the viewpoint of patch sharing.
yo.. i think, you made your point very clear. and generally, i agree very much with you. honestly, i would be very fine with everyone only using pd-extended with the exact same path settings and library order. if that would be, what everyone would agree on, i could perfectly live without namespaces and without the need to declare classes. however, people on this list seem to agree, that it is by design not the best way to assume, what is best for the user, but let the users decide themselves. it seems unlikely that everyone is going to switch to pd-extended soon and quite some people only install what they think they need. so after all, declaring classes seems the only way to handle those cases and there seems to be a consensus about it. i even think, that besides all conceptional reasons, the fact, that there seems to be a consensus in the pd community is actually the strong point. i guess, it is one of the few things, that so many people agree on.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
let me bring in one last argument against the declaration jungle. I'd like to compare the different library setups to the proprietary standards of web browsers during the 90s, which was at the expense of webdesigners and users. in that sense every pd user right now represents his own corporate world standard of libraries. marius.
marius schebella wrote:
wrt the user/patcher distinction: ok, let's not differentiate bet. these two. but differentiate between a scenario where you only share patches and abstractions vs. a scenario where you also share library binaries. the first calls for a standardized set of object classes (which does not exist - yet?). with the use of declarations you expect a standardized set of available libraries. but this is future telling, too. to have persistent sharing of pd patches, you either have to agree on a set of object classes or always ship the pd version and libraries. again. declare -lib zexy is also only based on the assumption that we are talking about the same zexy library. this assumption really is not much different than the assumption that we are talking about the same [gate] object class...
wrt pd-extended my perception is that the vast majority of pd users use extended. but you are right, there are a lot of situations, where pdx is problematic (the license, then the long startup times(?), some objects (pdj) incompatible...)
wrt to the unsolved object class/library situation if we start declaring every object class that we use, then doesn't that mean that we should also separate the pd kernel from the object classes that ship with pd (vanilla) and load -lib vanilla as a (first?) set of available objects? the next thing I would strongly propose is a restructuring of the libraries into thematical collections. and then deal with the question, if we need libraries at all, why not go with single externals and declare each of them separately.
pd is so much like the real world, unfinished:open imperfect:exciting software:hardware:people:life.
marius.
Roman Haefeli wrote:
On Tue, 2009-02-17 at 23:30 +0100, marius schebella wrote:
Roman Haefeli wrote:
On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part?
i think, noone wanted to strip down anything. this is only about not loading the whole bunch of libs automatically anymore. how does that make pd-extended less 'extended'?
first, I think there is a difference between a "user" user (who downloads a patch) and a "patching" user.
i think you cannot design a language based on the distinction between several kinds of user groups. the overall goal should be consistency and i think, what is consistent is the most easy to learn, for_ anyone_. consistency makes it easy for the programmers to program patches and at the same time 'patch musicians' can rely on those patches to work smoothly. what consistency means in pd world does not seem to be so clear yet, though, but that is why all this talk is necessary.
I always saw pd-extended as a consensual (ok, proposed actually by only one person) agreement on a set of object classes that are available in addition to pd vanilla. It was a way to make sure that if a "patcher" programs a patch for pd-extended that every other pd-extended "user" will have the same setup and thus be able to open the patch without errors. if you leave the loading of external(librarie)s to the user user, that means, if you allow/force the user to create his/her own order of startup libs, you cannot count on this behaviour anymore.
right. however, in the ideal pd world (it's not there yet, but i guess it is going there) the loading order wouldn't matter, because everything would be loaded only canvas-locally.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
can you elaborate that a bit? to me it looks perfectly normal, that i have to at least call the tools, that i am going to use.
ok. this is a problem of software architecture. where to draw the border between what is "given" and what is open. to me object classes should be part of the given world, because one, it makes coding, teaching, deploying easier, if all patchers were using the same set of tools and two, if you create your own screws, then you also have to ship the screw drivers (not only declare them).
I know the pd concept is, not to insist on a predefined set of object classes, which of course makes pd more extendible, but with this huge overhead of having to hassle with declarations, namespaces, which are ok for written programming languages, but maybe not for a building block programming tool like pd.
especially if - like in the case of the pd externals - the libraries are arbitrary. (like any categorization system). they are not sorted by topics but rather by coders. just think, a new pd patcher has to learn that an object was programmed by IOhannes, and therefor it is in the zexy library. another one was programmed by someone at the IEM, therefore it is part of the iemlib. furthermore the name of the libraries can change, the same code can become part of two different libraries and some objects do not even belong to a library. if you are consequent in providing your tools, it means that you have to ship the particular pd externals together with your patch everytime you want to share a patch. because then referring to zexy is not enough either, someone else could create a concurring external library also called zexy. then what...
plus, not agreeing on the toolset (set of object names) will always cause your own abstractions to be potentially overwritten by internal/external object classes, which get loaded instead.
plus, with some objects it is necessary to load them in advance, for example all objects with abbreviations, or some objects that enable special features (like the loader for luascripts).
pd is *not* like c, c++, java, these languages create applications, but the way I would like to see pd is, that pd programmers don't create standalone pd versions, but only pd patches.
plus, don't expect (pd-x) patchers ever to declare all objectclasses that they're using.
I hate to say this, but standards and specifications can really make life easier. the habit to leave many things opens allows people to addon a lot of crazy stuff, but it is counterproductive from the viewpoint of patch sharing.
yo.. i think, you made your point very clear. and generally, i agree very much with you. honestly, i would be very fine with everyone only using pd-extended with the exact same path settings and library order. if that would be, what everyone would agree on, i could perfectly live without namespaces and without the need to declare classes. however, people on this list seem to agree, that it is by design not the best way to assume, what is best for the user, but let the users decide themselves. it seems unlikely that everyone is going to switch to pd-extended soon and quite some people only install what they think they need. so after all, declaring classes seems the only way to handle those cases and there seems to be a consensus about it. i even think, that besides all conceptional reasons, the fact, that there seems to be a consensus in the pd community is actually the strong point. i guess, it is one of the few things, that so many people agree on. roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
marius schebella wrote:
wrt to the unsolved object class/library situation if we start declaring every object class that we use, then doesn't that mean that we should also separate the pd kernel from the object classes that ship with pd (vanilla) and load -lib vanilla as a (first?) set of available objects?
isn't this something hans has been trying to talk miller into for ages?
mfasdr IOhannes
On Feb 19, 2009, at 3:53 AM, IOhannes m zmoelnig wrote:
marius schebella wrote:
wrt to the unsolved object class/library situation if we start declaring every object class that we use, then doesn't that mean that we should also separate the pd kernel from the object classes that ship with pd (vanilla) and load -lib vanilla as a (first?) set of available objects?
isn't this something hans has been trying to talk miller into for ages?
I don't think it is just me. I just need to implement it now...
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
I definitely agree that we should have libraries organized based on a topic. There is nothing stopping anyone from doing this. There is tons of code that could be easily taking and stuck into new libraries organized around concepts.
.hc
On Feb 19, 2009, at 1:41 AM, marius schebella wrote:
wrt the user/patcher distinction: ok, let's not differentiate bet. these two. but differentiate between a scenario where you only share patches and abstractions vs. a scenario where you also share library binaries. the first calls for a standardized set of object classes (which does not exist - yet?). with the use of declarations you expect a standardized set of available libraries. but this is future telling, too. to have persistent sharing of pd patches, you either have to agree on a set of object classes or always ship the pd version and libraries. again. declare -lib zexy is also only based on the assumption that we are talking about the same zexy library. this assumption really is not much different than the assumption that we are talking about the same [gate] object class...
wrt pd-extended my perception is that the vast majority of pd users use extended. but you are right, there are a lot of situations, where pdx is problematic (the license, then the long startup times(?), some objects (pdj) incompatible...)
wrt to the unsolved object class/library situation if we start declaring every object class that we use, then doesn't that mean that we should also separate the pd kernel from the object classes that ship with pd (vanilla) and load -lib vanilla as a (first?) set of available objects? the next thing I would strongly propose is a restructuring of the libraries into thematical collections. and then deal with the question, if we need libraries at all, why not go with single externals and declare each of them separately.
pd is so much like the real world, unfinished:open imperfect:exciting software:hardware:people:life.
marius.
Roman Haefeli wrote:
On Tue, 2009-02-17 at 23:30 +0100, marius schebella wrote:
Roman Haefeli wrote:
On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part?
i think, noone wanted to strip down anything. this is only about not loading the whole bunch of libs automatically anymore. how does that make pd-extended less 'extended'?
first, I think there is a difference between a "user" user (who downloads a patch) and a "patching" user.
i think you cannot design a language based on the distinction between several kinds of user groups. the overall goal should be consistency and i think, what is consistent is the most easy to learn, for_ anyone_. consistency makes it easy for the programmers to program patches and at the same time 'patch musicians' can rely on those patches to work smoothly. what consistency means in pd world does not seem to be so clear yet, though, but that is why all this talk is necessary.
I always saw pd-extended as a consensual (ok, proposed actually by only one person) agreement on a set of object classes that are available in addition to pd vanilla. It was a way to make sure that if a "patcher" programs a patch for pd-extended that every other pd-extended "user" will have the same setup and thus be able to open the patch without errors. if you leave the loading of external(librarie)s to the user user, that means, if you allow/force the user to create his/her own order of startup libs, you cannot count on this behaviour anymore.
right. however, in the ideal pd world (it's not there yet, but i guess it is going there) the loading order wouldn't matter, because everything would be loaded only canvas-locally.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
can you elaborate that a bit? to me it looks perfectly normal, that i have to at least call the tools, that i am going to use.
ok. this is a problem of software architecture. where to draw the border between what is "given" and what is open. to me object classes should be part of the given world, because one, it makes coding, teaching, deploying easier, if all patchers were using the same set of tools and two, if you create your own screws, then you also have to ship the screw drivers (not only declare them).
I know the pd concept is, not to insist on a predefined set of object classes, which of course makes pd more extendible, but with this huge overhead of having to hassle with declarations, namespaces, which are ok for written programming languages, but maybe not for a building block programming tool like pd.
especially if - like in the case of the pd externals - the libraries are arbitrary. (like any categorization system). they are not sorted by topics but rather by coders. just think, a new pd patcher has to learn that an object was programmed by IOhannes, and therefor it is in the zexy library. another one was programmed by someone at the IEM, therefore it is part of the iemlib. furthermore the name of the libraries can change, the same code can become part of two different libraries and some objects do not even belong to a library. if you are consequent in providing your tools, it means that you have to ship the particular pd externals together with your patch everytime you want to share a patch. because then referring to zexy is not enough either, someone else could create a concurring external library also called zexy. then what...
plus, not agreeing on the toolset (set of object names) will always cause your own abstractions to be potentially overwritten by internal/external object classes, which get loaded instead.
plus, with some objects it is necessary to load them in advance, for example all objects with abbreviations, or some objects that enable special features (like the loader for luascripts).
pd is *not* like c, c++, java, these languages create applications, but the way I would like to see pd is, that pd programmers don't create standalone pd versions, but only pd patches.
plus, don't expect (pd-x) patchers ever to declare all objectclasses that they're using.
I hate to say this, but standards and specifications can really make life easier. the habit to leave many things opens allows people to addon a lot of crazy stuff, but it is counterproductive from the viewpoint of patch sharing.
yo.. i think, you made your point very clear. and generally, i agree very much with you. honestly, i would be very fine with everyone only using pd-extended with the exact same path settings and library order. if that would be, what everyone would agree on, i could perfectly live without namespaces and without the need to declare classes. however, people on this list seem to agree, that it is by design not the best way to assume, what is best for the user, but let the users decide themselves. it seems unlikely that everyone is going to switch to pd-extended soon and quite some people only install what they think they need. so after all, declaring classes seems the only way to handle those cases and there seems to be a consensus about it. i even think, that besides all conceptional reasons, the fact, that there seems to be a consensus in the pd community is actually the strong point. i guess, it is one of the few things, that so many people agree on. roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
----------------------------------------------------------------------------
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
I definitely agree that we should have libraries organized based on a topic. There is nothing stopping anyone from doing this. There is tons of code that could be easily taking and stuck into new libraries organized around concepts.
hmm, that matches with what I was proposing (still on a private level) for the new categories of documentating pd-ext objects. although some people might not like not having their objects in their personal folder, it would really make information more easily to come by - fyi, I think in the latest object list I've made, there are ~1200 externals (objects + abstractions).
I would go to the extra step and and follow yves' suggestions try to ask some developpers to change the names of some objects to avoid name clashes - if that's possible anyway, after all these years of programming.
I can't contribute with code because I can't code, but I can write mails and give (sometimes good) ideas. To remind how big the task is, I attach here the list of pd-ext objects I've done some months ago (as a first step to try to get an updated documentation for pd-ext).
On Tue, 17 Feb 2009, marius schebella wrote:
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
So, why is it that it is a hack in the context of a visual dataflow programming language and, I presume that you mean that non-visual and/or non-dataflow programming languages are somehow different?
I'd say that declarations are annoying in any language, and fully-qualified names are annoying in any language, but with some languages and editors it's easier to handle it than in some others, and in some it annoys more than in others.
Do you mean namespace declarations in particular, or namespaces in general including full-qualified names, or do you just mean the latter, or just long names in general?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Tue, 17 Feb 2009, marius schebella wrote:
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
So, why is it that it is a hack in the context of a visual dataflow programming language
because I think the concept of a visual dataflow programming language should be to provide a developer environment to people who don't necessarily have a programming background. think of html code, imagine you have to declare every h1, a, bold, ul... tag, before you can use it. as a pd user I really don't want to go into that level of complexity.
and, I presume that you mean that non-visual and/or non-dataflow programming languages are somehow different?
most text based libraries either come with a fixed set of libraries or ship the library with the code, or ship a binary. as a pd programmer I only want to ship patches and abstractions. (and content like pics etc....).
I'd say that declarations are annoying in any language, and fully-qualified names are annoying in any language, but with some languages and editors it's easier to handle it than in some others, and in some it annoys more than in others.
I am sure this would be less of a problem, if the current setup (pd version, library version, startup settings) would just automatically be added to every patch. although... nah, maybe this is not a good solution.
Do you mean namespace declarations in particular, or namespaces in general including full-qualified names, or do you just mean the latter, or just long names in general?
namespaces in particular with pd. not in general.
cheers, marius.
On Feb 17, 2009, at 5:54 PM, marius schebella wrote:
Mathieu Bouchard wrote:
On Tue, 17 Feb 2009, marius schebella wrote:
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
So, why is it that it is a hack in the context of a visual dataflow programming language
because I think the concept of a visual dataflow programming language should be to provide a developer environment to people who don't necessarily have a programming background. think of html code, imagine you have to declare every h1, a, bold, ul... tag, before you can use it. as a pd user I really don't want to go into that level of complexity.
I have found in my teaching that [trigger] is a fair more complex thing to understand than import. [trigger] has to be explained at length, often repeatly. On the other hand, when students have tried to use objects from libraries and found those object didn't work, two sentences is usually enough: "that's because that object is in a library that isn't loaded. To load it, create an object called [import libname]".
The hard part is the implementation, IMHO. Ideally the implementation will make it really that easy. It's half way there, but there are still some hard bits to sort out.
For a related reason, I also like [import] over [declare]. [declare] has those four flags which even I can never remember which does what, plus it is new syntax, there are few objects that have -args in them. [import] loads a library in the way that it should be the vast majority of the time: into the canvas-local namespace.
.hc
and, I presume that you mean that non-visual and/or non-dataflow programming languages are somehow different?
most text based libraries either come with a fixed set of libraries or ship the library with the code, or ship a binary. as a pd programmer I only want to ship patches and abstractions. (and content like pics etc....).
I'd say that declarations are annoying in any language, and fully- qualified names are annoying in any language, but with some languages and editors it's easier to handle it than in some others, and in some it annoys more than in others.
I am sure this would be less of a problem, if the current setup (pd version, library version, startup settings) would just automatically be added to every patch. although... nah, maybe this is not a good solution.
Do you mean namespace declarations in particular, or namespaces in general including full-qualified names, or do you just mean the latter, or just long names in general?
namespaces in particular with pd. not in general.
cheers, marius.
----------------------------------------------------------------------------
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
On Wed, 18 Feb 2009, Hans-Christoph Steiner wrote:
I have found in my teaching that [trigger] is a fair more complex thing to understand than import. [trigger] has to be explained at length, often repeatly.
How much of it is because of the inherent complexity of [trigger], vs how much is because of how it ties in with execution order, the hot/cold inlets and the standard outlet order (right-to-left) ?
And then how much of the rest of trigger can be explained in terms of other things that may be already known? For example, [t b] is like a [t a] with a [bang].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Tue, 17 Feb 2009, marius schebella wrote:
because I think the concept of a visual dataflow programming language should be to provide a developer environment to people who don't necessarily have a programming background.
Do you know that this has been said several times about various new languages? Assembly language was believed to introduce computer programming to non-specialists. Fortran was believed to introduce computer programming to non-specialists. Cobol was believed to introduce... no, BASIC is apparently more BASIC because otherwise why would it be called like that? and then LOGO was apparently made for kids to learn. And so on. What about Smalltalk and Squeak? same thing.
So, what is so special about visual dataflow, that makes it deserve to be burdened by such ideals?
That said, I'm not very fond of declarations, but I don't think that it's an issue of programmers vs non-programmers, it's a matter of people who like to declare vs people who don't, and that's a quite different split. There are quite a lot of serious programming languages that avoid declarations as much as possible.
I am sure this would be less of a problem, if the current setup (pd version, library version, startup settings) would just automatically be added to every patch. although... nah, maybe this is not a good solution.
Well, it would add a lot of useless lines to every patch and would eventually become a meaningless trace of how every programme was made, much like unused variable declarations can distract, confuse, waste time and take space in the mind.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Feb 18, 2009, at 2:57 PM, Mathieu Bouchard wrote:
On Tue, 17 Feb 2009, marius schebella wrote:
because I think the concept of a visual dataflow programming language should be to provide a developer environment to people who don't necessarily have a programming background.
Do you know that this has been said several times about various new languages? Assembly language was believed to introduce computer programming to non-specialists. Fortran was believed to introduce computer programming to non-specialists. Cobol was believed to introduce... no, BASIC is apparently more BASIC because otherwise why would it be called like that? and then LOGO was apparently made for kids to learn. And so on. What about Smalltalk and Squeak? same thing.
So, what is so special about visual dataflow, that makes it deserve to be burdened by such ideals?
That said, I'm not very fond of declarations, but I don't think that it's an issue of programmers vs non-programmers, it's a matter of people who like to declare vs people who don't, and that's a quite different split. There are quite a lot of serious programming languages that avoid declarations as much as possible.
Can you give some examples of how other langauges handle this kind of thing without delcarations?
.hc
I am sure this would be less of a problem, if the current setup (pd version, library version, startup settings) would just automatically be added to every patch. although... nah, maybe this is not a good solution.
Well, it would add a lot of useless lines to every patch and would eventually become a meaningless trace of how every programme was made, much like unused variable declarations can distract, confuse, waste time and take space in the mind.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
----------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Fri, 20 Feb 2009, Hans-Christoph Steiner wrote:
On Feb 18, 2009, at 2:57 PM, Mathieu Bouchard wrote:
That said, I'm not very fond of declarations, but I don't think that it's an issue of programmers vs non-programmers, it's a matter of people who like to declare vs people who don't, and that's a quite different split. There are quite a lot of serious programming languages that avoid declarations as much as possible.
Can you give some examples of how other langauges handle this kind of thing without delcarations?
Not really...
In Smalltalk you don't have declarations like this, because there are no namespaces, and because there are no files to load.
In Ruby you load files, but they don't have to be tied with any classnames in particular. Loading a file can be considered a declaration if you wish, but it's an action. There are namespaces, but you import them by performing the action of adding a superclass to the class that you are in (even though all ruby docs deny that this constitutes multiple-inheritance... go figure!)
In Tcl, there are namespaces, though many libraries don't use them. You have file-loading just like Ruby's, and you have packages implemented in terms of file-loading. Declarations are really actions in this language too. Namespaces exist, but were added after many years of existence of the language. (Not counting the other kind of namespace called "ensemble" and that has nothing to do with the newer feature called "namespace"). The import feature is probably similar to Python's, I don't know; it works as an action as well, of course.
A big difficulty with namespaces in Pd is that the user doesn't control the loading order of objects, and objects aren't "run" in the way a program is, so [import] has to be very special. If Pd were more like one of the above systems, you'd be able to [loadbang] an [import] before the rest of the patch loads; but this is only one way of thinking about the correspondence between languages... depending on how we decide to map concepts across languages, we would get to different possible equivalences of features.
Tcl and Ruby don't have a two-in-one load-and-import "declaration", whereas Python and Perl do. Some other languages may look like they have a load-and-import declaration, but instead have only an import declaration, and do all the loading automagically: for example, in Java, you can say java.util.Vector and it gets loaded, no need to import.
About declarations in general and languages that avoid them, it's something that doesn't apply so well to namespaces as it does to other language features that don't apply to Pd.
Something you could take from Java is that creating the objectbox [zexy/foo] would cause the loading of zexy.pd_linux if it is found. Maybe.
My main advice would still be to avoid having to use any declarations for things that ought to be internal classes in Pd but aren't. That's very subjective. For example, much of zexy and iemguts could go in that category, imho, and much of many other libraries as well.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Feb 22, 2009, at 9:09 PM, Mathieu Bouchard wrote:
On Fri, 20 Feb 2009, Hans-Christoph Steiner wrote:
On Feb 18, 2009, at 2:57 PM, Mathieu Bouchard wrote:
That said, I'm not very fond of declarations, but I don't think that it's an issue of programmers vs non-programmers, it's a matter of people who like to declare vs people who don't, and that's a quite different split. There are quite a lot of serious programming languages that avoid declarations as much as possible.
Can you give some examples of how other langauges handle this kind of thing without delcarations?
Not really...
In Smalltalk you don't have declarations like this, because there are no namespaces, and because there are no files to load.
In Ruby you load files, but they don't have to be tied with any classnames in particular. Loading a file can be considered a declaration if you wish, but it's an action. There are namespaces, but you import them by performing the action of adding a superclass to the class that you are in (even though all ruby docs deny that this constitutes multiple-inheritance... go figure!)
In Tcl, there are namespaces, though many libraries don't use them. You have file-loading just like Ruby's, and you have packages implemented in terms of file-loading. Declarations are really actions in this language too. Namespaces exist, but were added after many years of existence of the language. (Not counting the other kind of namespace called "ensemble" and that has nothing to do with the newer feature called "namespace"). The import feature is probably similar to Python's, I don't know; it works as an action as well, of course.
A big difficulty with namespaces in Pd is that the user doesn't control the loading order of objects, and objects aren't "run" in the way a program is, so [import] has to be very special. If Pd were more like one of the above systems, you'd be able to [loadbang] an [import] before the rest of the patch loads; but this is only one way of thinking about the correspondence between languages... depending on how we decide to map concepts across languages, we would get to different possible equivalences of features.
Tcl and Ruby don't have a two-in-one load-and-import "declaration", whereas Python and Perl do. Some other languages may look like they have a load-and-import declaration, but instead have only an import declaration, and do all the loading automagically: for example, in Java, you can say java.util.Vector and it gets loaded, no need to import.
About declarations in general and languages that avoid them, it's something that doesn't apply so well to namespaces as it does to other language features that don't apply to Pd.
Something you could take from Java is that creating the objectbox [zexy/foo] would cause the loading of zexy.pd_linux if it is found. Maybe.
My main advice would still be to avoid having to use any declarations for things that ought to be internal classes in Pd but aren't. That's very subjective. For example, much of zexy and iemguts could go in that category, imho, and much of many other libraries as well.
Yes, import/declare ends up being a bit weird. Mostly, I think the main issue is when someone adds an import midway thru a patch. Then next time it loads, it could end up having different files loaded for the stated objectclass names.
Perhaps then changing [import] should force the whole patch to reload. That would be annoying since the patch would lose its state, but I suppose the state could even be saved somehow.
Or perhaps there is an even better solution out there for something like namespaces in a visual programming language. Any ideas?
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Tue, Feb 17, 2009 at 2:24 AM, marius schebella marius.schebella@gmail.com wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part? Do I understand you correctly that you want to restructure the whole library mess? maybe you should just go for one big lib called extended then, that includes everything that is not really related to special libraries like gem or pdp. I would support a public decision making process that votes nameclashing objects in or out to extended. but the most important thing is to document what's inside. then people can reference to that set of object classes and deal with exceptions.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
btw, does the number of loaded libraries/object classes influence the startup time of patches?
Yo - So, I hear everything you're saying about simplicity and ease of sharing. But, I did test this, and if I remember correctly, measured a very, very significant difference in the speed of loading large patches after removing the 40+ search paths included by default with Pd-Extended. I'm sorry I don't have those results recorded - I thought it was a known issue and thus did not record things meticulously (but I think I might have jotted down the stats in a previous message in the archives). To the best of my memory, it was on the order of 2 minutes (which still sucks) versus over 10 minutes (which is just intolerable).
So, for that reason alone, I think it's extremely worthwhile creating a working namespacing system for Pd.
Two points: I don't think anyone discovers new objects by typing random words into object boxes (which would be an argument for making sure that as many of those random words turn magically into boxes as possible). I think most discover them by browsing the help system or reading others' patches. In both of those cases the declare/import system would be a very small cognitive load (since, in browsing the help, you're clicking on the names of the libraries to see the objects, and if everyone was using the namespaces, you'd see the [declare]/[import] in the patch right next to the object you're discovering).
There's the other issue of a lack of organization in the Pd-Extended collection - everyone has their own corner and it's a very rare library like [list-abs] that actually aims to collect objects around a common task. But, if we imagine a future where we do manage to get things organized by function rather than author (like Pd-MTL has begun to do), I think namespaces will become valuable - and we might as well get the functionality right now so we can begin to realize that future.
Finally, I think this: sure, Pd is an amazing language for beginners. It was the language that brought me personally from begin a dabbler in coding into a full-time constructor. But, there are unique things about Pd that have kept me (and, as I've seen, many extremely intelligent, capable and talented polyglot programmers like say, IOhannes, Mathieu, Thomas Grill, or Miller himself) using it. Such as: its realtime nature, the seamless melding of GUI and code, and the beauty of seeing your code as an image rather than piles of text. And most of all, its community, which leads me to yet another point in this speech : )
Perhaps I'd find certain things easier in other languages, building the size of applications that I'm building: maybe they'd be more stable, and use less memory, and start faster. But I am a composer, and these applications would be for the exploration of sound. And I'd find no inspiration for these explorations in any of those "serious" languages. I'd rarely find people doing cutting edge sound processing or generative composition, nor would I get to play with nearly as many audiovisual art pieces that often send me off implementing a new module in my system. Pd is a unique place where the cutting edges of programming and sound and composition are cutting each other.
*** INTERMISSION ***
Judging by the fact that I /have/ built my applications in Pd, and that they work 90% of the time, I'm convinced that Pd is extremely close to being an excellent language for the entire gamut of ambition. I think rather than making excuses for it, we should finish the job.
Finally, as a funny way of expressing my love: I don't think anyone is downloading Pd-extended right now and speeding off into sound dream land... anyone savvy enough to dig through the beautifully disheveled treasure trove of Pd-extended can probably handle the concept of declaring which libraries they'd like to use in their patch.
But anyway, that can always be resolved by offering a "Pd-EZ" that loads everything, alongside the newly rigorous Pd-extended. I just think that arguing against the whole initiative of namespaces within Pd is being unnecessarily pessimistic about its future and potential sophistication.
So, sorry about the length and in-eloquence of my homily (it's late and I'd need much more time to boil that all down : ) ), but I think most of my thoughts are there.
Best Luke
marius.
2009/2/16 Hans-Christoph Steiner hans@eds.org:
Hey,
Right now, Pd-extended is loading a lot of libraries by default. Most people never used most of those libraries, so I think it makes sense to reduce that number to move towards the goal of having the library loading embedded in the patch itself.
So the question now is, which libraries should stay in for now, to ease the transition? Here's the current list in the order they are loaded:
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 pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Or does it even make sense to do it in stages?
.hc
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Andy Farnell -
Claude Heiland-Allen -
cyrille henry -
Damian Stewart -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
João Pais -
Loic Kessous -
Luke Iannini -
marius schebella -
Martin Peach -
Mathieu Bouchard -
Matt Barber -
Roman Haefeli -
Steffen Juul