Hi there, there seems to be some redundancies regarding the "uzi" object. I'm in Pd-Extended 0.42-5, not sure how this is now at 0.43.
There's the cyclone one, but there is also a [kalashnikov] object (from "ext13") which I like cause it's a bit more convenient to sweep arrays (cause the numbered bangs go from 0 to n-1, unlike the cyclone version). Though [kalashnikov] can also be instantiated as [uzi], I can't create it as [uzi] unless I have a [kalashnikov] created first. Seems there's a bug problem with its alias.
Weirdly enough, though I can create it as [ext13/kalashnikov], I can't do it as [ext13/uzi] even after I first created the object as "kalashnikov".
I wonder if there was any way of using it as [uzi] or [ext13/uzi] without bothering how to spell kalashnikov.
Moreover, the cyclone version has upper case U... we were discussing here if we could make a lower case alias, but it'd get in conflict with other [uzi] objects around... one way around would be to be able to load [ext13/uzi]...
And there's another [uzi] from "purepd", which is an abstraction and also a clone of max that is quite redundanct and probably was best to just delete it from the package.
cheers
Hi Alexandre, pd-list,
In cyclone it works because the Uzi.c contains both a "void Uzi_setup(void) {..." and a "void uzi_setup(void) {...". The latter only calls the first.
In ext13/void kalashnikov.c there is only a "void kalashnikov_setup(void) {...". It contains the line "class_addcreator(... gensym("uzi"), A_DEFFLOAT, 0);" which registers the uzi symbol, but only when the kalashnikov class is loaded. Adding a "void uzi_setup(void) { ..." might fix it. Then ext13/uzi could work...
Fred Jan
On 2015-03-05 09:07 PM, Alexandre Torres Porres wrote:
Hi there, there seems to be some redundancies regarding the "uzi" object. I'm in Pd-Extended 0.42-5, not sure how this is now at 0.43.
There's the cyclone one, but there is also a [kalashnikov] object (from "ext13") which I like cause it's a bit more convenient to sweep arrays (cause the numbered bangs go from 0 to n-1, unlike the cyclone version). Though [kalashnikov] can also be instantiated as [uzi], I can't create it as [uzi] unless I have a [kalashnikov] created first. Seems there's a bug problem with its alias.
Weirdly enough, though I can create it as [ext13/kalashnikov], I can't do it as [ext13/uzi] even after I first created the object as "kalashnikov".
I wonder if there was any way of using it as [uzi] or [ext13/uzi] without bothering how to spell kalashnikov.
Moreover, the cyclone version has upper case U... we were discussing here if we could make a lower case alias, but it'd get in conflict with other [uzi] objects around... one way around would be to be able to load [ext13/uzi]...
And there's another [uzi] from "purepd", which is an abstraction and also a clone of max that is quite redundanct and probably was best to just delete it from the package.
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/05/2015 09:07 PM, Alexandre Torres Porres wrote:
Hi there, there seems to be some redundancies regarding the "uzi" object. I'm in Pd-Extended 0.42-5, not sure how this is now at 0.43.
There's the cyclone one, but there is also a [kalashnikov] object (from "ext13") which I like cause it's a bit more convenient to sweep arrays (cause the numbered bangs go from 0 to n-1, unlike the cyclone version). Though [kalashnikov] can also be instantiated as [uzi], I can't create it as [uzi] unless I have a [kalashnikov] created first. Seems there's a bug problem with its alias.
well, there is no alias on the filesystem level, but only on the logical level. since with PdX you do not load the (entire) ext13 library, but rather element-by-element, logical aliases (as defined withing the object) don't work if they don't have a corresponding filesystem alias.
a filesystem alias can be as simple as a symlink from kalashnikov.pd_linux to uzi.pd_linux (but then again, it might still not work, as the kalashnikoc.pd_linux binary probably misses a setup-function for the "uzi" -name)
Weirdly enough, though I can create it as [ext13/kalashnikov], I can't do it as [ext13/uzi] even after I first created the object as "kalashnikov".
that's very expected behaviour: after all you do have a file ext13/kalashnikov.pd_linux but no ext13/uzi.pd_linux.
I wonder if there was any way of using it as [uzi] or [ext13/uzi] without bothering how to spell kalashnikov.
add "ext13/kalashnikov" to the libraries to be loaded at startup? or make an abstraction uzi.pd in ext13/, that contains a [kalashnikov] objects and the proper iolets?
Moreover, the cyclone version has upper case U... we were discussing here if we could make a lower case alias,
i have missed that discussion, but cyclone's uppercasing is a *design choice* to make sure that the max compat layer does not conflict with Pd.
i'm not entirely sure why you are pushing to make Pd a "free replacement for max/msp". both are similar and share enough concepts to make compat-layers like cyclone feasible, but they are also different
but it'd get in conflict with other [uzi] objects around... one way around would be to be able to load [ext13/uzi]...
And there's another [uzi] from "purepd", which is an abstraction and also a clone of max that is quite redundanct and probably was best to just delete it from the package.
why? i'd probably recomment to delete all *but* the abstraction implementation of [uzi], as it is the only version that is guaranteed to be 100% portable to any OS Pd will ever appear on.
gfmsdr IOhannes
On 03/05/2015 09:56 PM, IOhannes m zmölnig wrote:
Moreover, the cyclone version has upper case U... we were discussing here if we could make a lower case alias,
i have missed that discussion, but cyclone's uppercasing is a *design choice* to make sure that the max compat layer does not conflict with Pd.
oh i see that the discussion is currently going on (i was under the impression that you *were* discussing it a while ago).
in any case: afair cyclones goal is to allow to easily migrate an old max-patch to a shiny Pd-patch, rather than make Pd a shallow copy/the ugly sister of max. so my point remains.
gsamrd IOhannes
(Totally off-topic : people at the NSA are going to start monitoring us with thread titles like this ! :) )
2015-03-05 22:01 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/05/2015 09:56 PM, IOhannes m zmölnig wrote:
Moreover, the cyclone version has upper case U... we were discussing
here
if we could make a lower case alias,
i have missed that discussion, but cyclone's uppercasing is a *design choice* to make sure that the max compat layer does not conflict with Pd.
oh i see that the discussion is currently going on (i was under the impression that you *were* discussing it a while ago).
in any case: afair cyclones goal is to allow to easily migrate an old max-patch to a shiny Pd-patch, rather than make Pd a shallow copy/the ugly sister of max. so my point remains.
gsamrd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yeah, I believe that "How to load a kalashnikov" really shows up in their system :)
2015-03-06 5:29 GMT-03:00 Pierre Massat pimassat@gmail.com:
(Totally off-topic : people at the NSA are going to start monitoring us with thread titles like this ! :) )
2015-03-05 22:01 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/05/2015 09:56 PM, IOhannes m zmölnig wrote:
Moreover, the cyclone version has upper case U... we were discussing
here
if we could make a lower case alias,
i have missed that discussion, but cyclone's uppercasing is a *design choice* to make sure that the max compat layer does not conflict with
Pd.
oh i see that the discussion is currently going on (i was under the impression that you *were* discussing it a while ago).
in any case: afair cyclones goal is to allow to easily migrate an old max-patch to a shiny Pd-patch, rather than make Pd a shallow copy/the ugly sister of max. so my point remains.
gsamrd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
oh i see that the discussion is currently going on (i was under the impression that you *were* discussing it a while ago).
Yeah, and, as it turns out, from that discussion, I learned that is that last version of Extended actually loads cyclone Uzi when you type "uzi". So we do have in fact 3 objects in Pd extended with the exact same name, so my point about redundancy and messiness remains.
New issues do come about, by the way. Now, if you load [uzi], it'll get cyclone's object ("Uzi"), so if you load kalashnikov latter, in its help file it'll say it can also be loaded as [uzi], but the [uzi] in kalashnikov's help file is actually the one from cyclone, so the help from kalashnikov doesn't work, cause it's actually different than the cyclone version. And you'll never load kalashnikov as "uzi" from now on, unless you change your startup settings and load ext13/kalashnikov... then you can try [ext13/uzi] to load kalashnikov.
But if you load kalashnikov first, well, now you won't get cyclone's version when you type "uzi", but kalashnikov...
so, well, kinda confusing...
I'd vouch for trying and eliminating the redundancy and equal names somehow. I'd suggest killing the alias name of kalashnikov, it'd solve all that for Pd Extended. Why not ak47 as an alias? :)
but again, useless and pointless discussion if we're not dealing with an update of Pd Extended right now.
cheers
2015-03-05 18:01 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/05/2015 09:56 PM, IOhannes m zmölnig wrote:
Moreover, the cyclone version has upper case U... we were discussing
here
if we could make a lower case alias,
i have missed that discussion, but cyclone's uppercasing is a *design choice* to make sure that the max compat layer does not conflict with Pd.
oh i see that the discussion is currently going on (i was under the impression that you *were* discussing it a while ago).
in any case: afair cyclones goal is to allow to easily migrate an old max-patch to a shiny Pd-patch, rather than make Pd a shallow copy/the ugly sister of max. so my point remains.
gsamrd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/07/2015 11:27 PM, Alexandre Torres Porres wrote:
But if you load kalashnikov first, well, now you won't get cyclone's version when you type "uzi", but kalashnikov...
so, well, kinda confusing...
yes, very confusing. but not something unheard of, and i think humans are quite good at dealing with such things. imagine, one of the organizers of Pd~con 2007 is called "Alexandre" and one of the organizers of Pd~con 2009 is called "Alexandre". one is inclined to think that they are the same (after all, they do similar things and go by the same name), but it turns out that in fact they are totally incompatible (crashing *your* place in Montreal might make me end up sleeping on the street!)¹
I'd vouch for trying and eliminating the redundancy and equal names somehow. I'd suggest killing the alias name of kalashnikov, it'd solve all that for Pd Extended.
and get rid of cyclone's [uzi], as it already has [Uzi].
but again, useless and pointless discussion if we're not dealing with an update of Pd Extended right now.
no, i think that the discussion is important, as it shows one of the big problems with the architecture of a monolithic Pd-extended.
the question is: do "we" (the hypothetical PdX maintainers) provide a consistent system where everything is nice and easy; or do we just provide a largish collection of libraries for all kind of problems.
i think the 1st option is *totally* out of scope.
the fact is, that PdX currently *is* a largish collection of libraries, sharing a significant overlap (both in functionality and in naming).
it would require multiple fulltime jobs to sort this pile into consistent stack (and it would take a similar number of workpower to keep it in that state!). and once you have eliminated all redundancies, what you have gained is a centralized distribution of a decentralized development process that has broken any old patch by discarding backwards compatibility.
just *having* such a distribution does not mean that anybody will use it (e.g. those people that do not upgrade from PdX-0.42 to PdX-0.43 because...) nor that anybody will *develop* components (externals,...) for it (apart from those fulltime jobbers).
my point has always been that we should *embrace* the multitude in Pd, rather than eliminate it.
there is no harm in having "uzi" and "uzi" and "uzi", as long as it is clear which one is currently used (something Pd still lacks, despite hans' great work in the past).
having said all that, Pd-l2ork probably already does a decent job in providing a consistent distribution (but i haven't checked recently; and of course, l2ork/dsis also *added* a few new objects the functionality of which is already included in PdX - so not exactly minimizing the pool of objects either) - most likely because it *is* powered by institutional backing (see "fulltime jobber").
¹ actually i don't know how often you and alexandre have been confused; i know for sure that a lot of people mistake me for hans-christoph although the name is really not *that* similar, and we often shared very differing opinions. do you have any suggestions for my case :-)?
"
*there is no harm in having "uzi" and "uzi" and "uzi", as long as it isclear which one is currently used (something Pd still lacks, despite**hans' great work in the past).*"
Not sure what you mean here. I guess the worst is just being kinda unstable to know which one will actually be loaded... and how this conflicts are affecting even the help files. I'm not gonna repeat all the issues, but I see it's kinda harmful as it is.
But then, you could deal with this sort of thing is by having the name of the library before the object, like [cyclone/uzi]...
"*what you have gained is a centralized distribution of a decentralized development process that has **broken any old patch by discarding backwards compatibility.*"
backwards compatibility is not something that's being actually maintained in extended. It's been kind of a hectic development, some libraries are removed and inserted, and just making it possible to load "Uzi" as "uzi" created new issues as I've raised - like not being able to call kalashnikov as uzi anymore.
So I do have a different opinion, I believe it's not to hard to eliminate some noise that eventually shows up and avoid some conflicts, it looks to me as if it is for the best.
but then, it'd be good to see some real talk about the future of extended, or how to make it easier to add libraries from extended into vanilla before sharing opinions.
cheers
2015-03-08 17:50 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/07/2015 11:27 PM, Alexandre Torres Porres wrote:
But if you load kalashnikov first, well, now you won't get cyclone's version when you type "uzi", but kalashnikov...
so, well, kinda confusing...
yes, very confusing. but not something unheard of, and i think humans are quite good at dealing with such things. imagine, one of the organizers of Pd~con 2007 is called "Alexandre" and one of the organizers of Pd~con 2009 is called "Alexandre". one is inclined to think that they are the same (after all, they do similar things and go by the same name), but it turns out that in fact they are totally incompatible (crashing *your* place in Montreal might make me end up sleeping on the street!)¹
I'd vouch for trying and eliminating the redundancy and equal names somehow. I'd suggest killing the alias name of kalashnikov, it'd solve
all
that for Pd Extended.
and get rid of cyclone's [uzi], as it already has [Uzi].
but again, useless and pointless discussion if we're not dealing with an update of Pd Extended right now.
no, i think that the discussion is important, as it shows one of the big problems with the architecture of a monolithic Pd-extended.
the question is: do "we" (the hypothetical PdX maintainers) provide a consistent system where everything is nice and easy; or do we just provide a largish collection of libraries for all kind of problems.
i think the 1st option is *totally* out of scope.
the fact is, that PdX currently *is* a largish collection of libraries, sharing a significant overlap (both in functionality and in naming).
it would require multiple fulltime jobs to sort this pile into consistent stack (and it would take a similar number of workpower to keep it in that state!). and once you have eliminated all redundancies, what you have gained is a centralized distribution of a decentralized development process that has broken any old patch by discarding backwards compatibility.
just *having* such a distribution does not mean that anybody will use it (e.g. those people that do not upgrade from PdX-0.42 to PdX-0.43 because...) nor that anybody will *develop* components (externals,...) for it (apart from those fulltime jobbers).
my point has always been that we should *embrace* the multitude in Pd, rather than eliminate it.
there is no harm in having "uzi" and "uzi" and "uzi", as long as it is clear which one is currently used (something Pd still lacks, despite hans' great work in the past).
having said all that, Pd-l2ork probably already does a decent job in providing a consistent distribution (but i haven't checked recently; and of course, l2ork/dsis also *added* a few new objects the functionality of which is already included in PdX - so not exactly minimizing the pool of objects either) - most likely because it *is* powered by institutional backing (see "fulltime jobber").
¹ actually i don't know how often you and alexandre have been confused; i know for sure that a lot of people mistake me for hans-christoph although the name is really not *that* similar, and we often shared very differing opinions. do you have any suggestions for my case :-)?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I remember when Castonguay came here in 2008, and in the occasion there were 4 or 5 Alexandres in the same room - it was kinda confusing :O
2015-03-09 2:40 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
"
*there is no harm in having "uzi" and "uzi" and "uzi", as long as it isclear which one is currently used (something Pd still lacks, despite**hans' great work in the past).*"
Not sure what you mean here. I guess the worst is just being kinda unstable to know which one will actually be loaded... and how this conflicts are affecting even the help files. I'm not gonna repeat all the issues, but I see it's kinda harmful as it is.
But then, you could deal with this sort of thing is by having the name of the library before the object, like [cyclone/uzi]...
"*what you have gained is a centralized distribution of a decentralized development process that has **broken any old patch by discarding backwards compatibility.*"
backwards compatibility is not something that's being actually maintained in extended. It's been kind of a hectic development, some libraries are removed and inserted, and just making it possible to load "Uzi" as "uzi" created new issues as I've raised - like not being able to call kalashnikov as uzi anymore.
So I do have a different opinion, I believe it's not to hard to eliminate some noise that eventually shows up and avoid some conflicts, it looks to me as if it is for the best.
but then, it'd be good to see some real talk about the future of extended, or how to make it easier to add libraries from extended into vanilla before sharing opinions.
cheers
2015-03-08 17:50 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/07/2015 11:27 PM, Alexandre Torres Porres wrote:
But if you load kalashnikov first, well, now you won't get cyclone's version when you type "uzi", but kalashnikov...
so, well, kinda confusing...
yes, very confusing. but not something unheard of, and i think humans are quite good at dealing with such things. imagine, one of the organizers of Pd~con 2007 is called "Alexandre" and one of the organizers of Pd~con 2009 is called "Alexandre". one is inclined to think that they are the same (after all, they do similar things and go by the same name), but it turns out that in fact they are totally incompatible (crashing *your* place in Montreal might make me end up sleeping on the street!)¹
I'd vouch for trying and eliminating the redundancy and equal names somehow. I'd suggest killing the alias name of kalashnikov, it'd solve
all
that for Pd Extended.
and get rid of cyclone's [uzi], as it already has [Uzi].
but again, useless and pointless discussion if we're not dealing with an update of Pd Extended right now.
no, i think that the discussion is important, as it shows one of the big problems with the architecture of a monolithic Pd-extended.
the question is: do "we" (the hypothetical PdX maintainers) provide a consistent system where everything is nice and easy; or do we just provide a largish collection of libraries for all kind of problems.
i think the 1st option is *totally* out of scope.
the fact is, that PdX currently *is* a largish collection of libraries, sharing a significant overlap (both in functionality and in naming).
it would require multiple fulltime jobs to sort this pile into consistent stack (and it would take a similar number of workpower to keep it in that state!). and once you have eliminated all redundancies, what you have gained is a centralized distribution of a decentralized development process that has broken any old patch by discarding backwards compatibility.
just *having* such a distribution does not mean that anybody will use it (e.g. those people that do not upgrade from PdX-0.42 to PdX-0.43 because...) nor that anybody will *develop* components (externals,...) for it (apart from those fulltime jobbers).
my point has always been that we should *embrace* the multitude in Pd, rather than eliminate it.
there is no harm in having "uzi" and "uzi" and "uzi", as long as it is clear which one is currently used (something Pd still lacks, despite hans' great work in the past).
having said all that, Pd-l2ork probably already does a decent job in providing a consistent distribution (but i haven't checked recently; and of course, l2ork/dsis also *added* a few new objects the functionality of which is already included in PdX - so not exactly minimizing the pool of objects either) - most likely because it *is* powered by institutional backing (see "fulltime jobber").
¹ actually i don't know how often you and alexandre have been confused; i know for sure that a lot of people mistake me for hans-christoph although the name is really not *that* similar, and we often shared very differing opinions. do you have any suggestions for my case :-)?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
add "ext13/kalashnikov" to the libraries to be loaded at startup?
That does the trick! thanks for the explanations - though most of it is hard for me to get :/
i'm not entirely sure why you are pushing to make Pd a "free replacement for max/msp".
Can't help you there, cause I'm not doing that...
On the other hand I guess I feel like being "pushy" about making some clean up in the Pd extended as a whole, in which this is only one issue amongst many I'd like to raise and discuss. The cyclone library is one that is now being updated and I'm happy to spend some effort and collaborate, but there are many other libraries and objects that I care about as well. Kinda recently, I remember I pointed to you a bug in the help file of [noish~], for example. It's the same concern.
I teach Pd somewhat regularly in some courses, and the last thing on my mind is selling Pd as a replacement for anything. But, as I'm a heavy user and quite an advocate of Pd in my whereabouts when I teach it, I care about things being less messy and buggy as a whole.
i'd probably recomment to delete all *but* the abstraction
Good point, one way or another, what concerns me the most is the redundancy in Pd of having 3 objects with the same name, two of them being exactly equal and the third one a bit different. My point is that this is messy and confusing. I'm teaching a course right now, and I'd rather not have to spend any time to explain why there are 3 of these guys around and stuff...
And the issues just come up when you have something like this. For instance, if I call [kalashnikov] and then I load [purepd/uzi] and ask for its help file, the [uzi] that's being loaded in the [purepd/uzi]'s help is actually a [kalashnikov]... as a consequence, the help file doesn't work, as the two objects are different and have different outlets! See? Messy...
Anyway, discussing this would make more sense if we were in the midst of updating Pd Extended as a community, and this is not really happening yet.
Cheers
2015-03-05 17:56 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/05/2015 09:07 PM, Alexandre Torres Porres wrote:
Hi there, there seems to be some redundancies regarding the "uzi" object. I'm in Pd-Extended 0.42-5, not sure how this is now at 0.43.
There's the cyclone one, but there is also a [kalashnikov] object (from "ext13") which I like cause it's a bit more convenient to sweep arrays (cause the numbered bangs go from 0 to n-1, unlike the cyclone version). Though [kalashnikov] can also be instantiated as [uzi], I can't create it as [uzi] unless I have a [kalashnikov] created first. Seems there's a bug problem with its alias.
well, there is no alias on the filesystem level, but only on the logical level. since with PdX you do not load the (entire) ext13 library, but rather element-by-element, logical aliases (as defined withing the object) don't work if they don't have a corresponding filesystem alias.
a filesystem alias can be as simple as a symlink from kalashnikov.pd_linux to uzi.pd_linux (but then again, it might still not work, as the kalashnikoc.pd_linux binary probably misses a setup-function for the "uzi" -name)
Weirdly enough, though I can create it as [ext13/kalashnikov], I can't do it as [ext13/uzi] even after I first created the object as "kalashnikov".
that's very expected behaviour: after all you do have a file ext13/kalashnikov.pd_linux but no ext13/uzi.pd_linux.
I wonder if there was any way of using it as [uzi] or [ext13/uzi] without bothering how to spell kalashnikov.
add "ext13/kalashnikov" to the libraries to be loaded at startup? or make an abstraction uzi.pd in ext13/, that contains a [kalashnikov] objects and the proper iolets?
Moreover, the cyclone version has upper case U... we were discussing here if we could make a lower case alias,
i have missed that discussion, but cyclone's uppercasing is a *design choice* to make sure that the max compat layer does not conflict with Pd.
i'm not entirely sure why you are pushing to make Pd a "free replacement for max/msp". both are similar and share enough concepts to make compat-layers like cyclone feasible, but they are also different
but it'd get in conflict with other [uzi] objects around... one way around would be to be able to load [ext13/uzi]...
And there's another [uzi] from "purepd", which is an abstraction and
also a
clone of max that is quite redundanct and probably was best to just
delete
it from the package.
why? i'd probably recomment to delete all *but* the abstraction implementation of [uzi], as it is the only version that is guaranteed to be 100% portable to any OS Pd will ever appear on.
gfmsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Fred Jan Kraan -
IOhannes m zmölnig -
Pierre Massat