[PD] some notes for cyclone devs / maintainers

Alexandre Torres Porres porres at gmail.com
Wed Feb 24 22:55:08 CET 2016


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 at gmail.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160224/fb815cfb/attachment.html>


More information about the Pd-list mailing list