[PD] some notes for cyclone devs / maintainers

[katja]

On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres
<porres at gmail.com> wrote:
> 2016-02-24 14:17 GMT-03:00 katja <katjavetter at 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