[L2Ork-dev] cyclone merge resolution (Re: updating cyclone)

[Derek Kwan]

Alexandre Torres Porres <porres at gmail.com> writes:

>     When trying to merge cyclone, the libloader failed, cause we had
>     both a path and a library with the same name to load. As I see it,
>     the options here are:
>     1- fix the loader
>     2- get rid of the library for purr data (we can have a workaround
>     with hexloader, and this would also mean a separate branch)
>     3- make cyclone into a single library named cyclone
>     4- rename the library

Hello all,

We've actually been talking about the issues surrounding this in our own
little chat (Alex, Matt, and I).

If there has to be a renaming, I'm fine with "cyclone_ops" over
"cyclops". It's as bit more transparent as to what it is and what it
does than "cyclops" (because there's "cyclone" right out in front) and
it does potentially eat up less of the possible names available for
library development (although I'd say "cyclops" as a future library name
might not be the best idea due to its similarity to "cyclone" and the
apparently now-extinct Max object cyclops). I can also see the point of
not calling it "cyclops" because of that old object and although I don't
really see it being cloned anymore (although I'm not quite sure what it
did in the first place, admittedly I'm newer to the computer
music/creative coding game than whenever it existed) since the visual
side of things tend to get encompassed by GEM.

As far as I understand, hexloader is a utility that allows Pd to load
non-alphanumerically named binary files by their hex-encoded name
equivalents and it doesn't exist for Pd vanilla (at least in the default
distribution?). I guess we could potentially package it with Cyclone in
Deken for Pd vanilla use? But then there's the issue with hexloader
coming with every single download of Cyclone (which would be also
unnecessary if a person already had it for some other library). Or if we
don't package it with Cyclone and tell people to download it to use the
binops, that adds an extra, confusing step. Anyways, I don't think this
seems like a good solution. I'd say for a hexloader solution to be
feasible, it should be part of the Pd distribution it's trying to work with.

I think my preferred solution, in agreement with Alex, is fixing the
loader to add the greater flexibility needed for Cyclone to work as-is.
In my understanding, it basically automates the adding of paths
and loading of binaries and it breaks when we have cyclone the binary
for the binops and cyclone the directory for everything else. Doing
these things manually, at least for Pd vanilla, works and so I think, at
least ideally, that the loader should be able to do the same sorts of
things. This would allow for more flexibility in future Purr Data
library development and if perhaps separable from Purr Data and usable
as a utility for Pd vanilla, maybe it could be a good way to
"Pd-extendize" the Pd vanilla experience, which I think a lot of users
would appreciate.

I could, however, see that fixing the behiavor of the loader with this
greater flexibility could potentially be not-so-trivial (esp getting it
to work cross-platform) and take a quite a bit of work. If it's only a
problem with Cyclone and a few other libraries (or even just Cyclone),
I understand it being not such a high priority fix and not worth the effort
in the short term. Thus, changing the name of the cyclone binop binary
would be the path of least-resistance and be the most feasible, esp for
getting a new stable purr-data release out in a reasonable amount of
time.

On an additional note, we could add the "namespacing" cyclone/myobject
functionality to the binops by the way of class_addcreator and then
passing it gensym("cyclone/==~") for instance. I think I remember
reading that in the issue discussion on the repo somewhere?

Derek