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 <katjavet...@gmail.com>: > On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres > <por...@gmail.com> wrote: > > 2016-02-24 14:17 GMT-03:00 katja <katjavet...@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 >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list