> 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