I'm certainly not able to grasp the whole deal, maybe just get the gist of it and certainly willing to. But I'm partnered with a colleague that I believe is technically capable besides only willing. We'd need a lot of "filling us in" though.
cheers
2016-02-24 16:05 GMT-03:00 katja katjavetter@gmail.com:
On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres porres@gmail.com wrote:
2016-02-24 14:17 GMT-03:00 katja katjavetter@gmail.com:
the code was embedded in the programming structure of miXed, together
with
other libraries and the shared framework (...) Since other libraries in miXed were essentially unmaintained (...) I figured that cyclone's
chances
for future maintenance would be best if it could be compiled with a
build
system not relying on Pd-X or miXed as a set of libraries.
Makes sense to me.
Well, first, thanks for all the detailed information on how cyclone grew into a giant kludge and current issues Katjia. So, It was brought to
github
conserving as many pieces of the original puzzle as possible. But well, yeah, seems like depending on old ways and days might be
counterproductive
on the long run as you mentioned. and it kinda relates to what Miller
and
others were telling about how cyclone should maybe be left alone as it
was
attached to "old ways of doing things", a new rebuild might be a good
idea,
though quite ambitious.
Alexandre, your summary of my notes about cyclone's build systems (old and new) make a totally different story than I was telling. Cyclone didn't grow into a kludge, only the build system did. That is now solved as far as I am concerned.
For the rest: cyclone and it's underlying framework form a well-structured but never completed body of code. I don't think anyone suggested to rewrite it, if that is what you mean with 'rebuild'. Rewriting is ambitious indeed, possibly beyond your imagination. And a waste of time. Better focus on new functionality, and leave or delegate maintenance of the existing code base to people who are able and willing to understand it's structure.
Katja
Of course it is technically possible to add new classes which don't use the framework functions (...) You can have independent repositories, test / release cycles, and support (...) if the outcome of the
discussion is
that all must go in one cyclone lib, you could at least organize source
tree
and build system in such a way that dependencies between categories of classes and underlying framework remain transparent. The build system
could
be split according to categories of classes so devs can work in relative isolation in between releases.
For now, I'm revising all the documentation and painstakingly correcting
it
and testing objects looking for current issues. I've covered one third of the audio objects to this moment (26), only 8 have no remarks. This is a very time consuming task. I might take a month to recheck all current
state
of objects.
I can propose a new beta release with minor bug fixes right away just
for a
test, keeping things basically the way they already were. There's time to think about everything else when this new report of the current state is complete.
here's my recommendation: make use of the new build approach, because dealing with the old kludge of build scripts in miXed won't make you happy in the long run.
Agreed, thanks for the notes again.
Cheers