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