<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-02-24 14:17 GMT-03:00 katja <span dir="ltr"><<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>Makes sense to me. <br></div><div><br></div><div>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.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Of course it is technically possible to add new classes which don't<br>
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.</blockquote><div><br></div><div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">here's my recommendation: make use of the new build<br>
approach, because dealing with the old kludge of build scripts in<br>
miXed won't make you happy in the long run.<br></blockquote><div><br></div><div>Agreed, thanks for the notes again.</div><div><br></div><div>Cheers </div></div></div></div>