[PD] uzi redundancy and how to load kalashnikov as uzi

[Alexandre Torres Porres]

> 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 at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150307/33b6c18c/attachment.html>