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