[PD] Cyclone future

Alexandre Torres Porres porres at gmail.com
Mon Feb 22 06:14:00 CET 2016


Howdy, looking ahead, here's the repository I'm starting to work with
Flavio <https://github.com/porres/pd-cyclone>. As maintainers for
cyclone, we're to provide builds for various platforms from this repo.
Collaborators
could fork it to make changes and then make pull requests for merging into
ours, when we'd test and evaluate if they're ok by the following criteria:
*-* Change was a successful bug fix.
*-* Change was: a) new feature additions to existing objects or b) new
objects; where Max/MSP compatibility is respected.

We have plans to try to upload a new testing version to see how it goes in
a week or so. It is to include some new objects that are being finished
with the help of others (*hopefully 11 of them ([trunc~] / [atodb] /
[dbtoa] / [atodb~] / [dbtoa~] / [pong] /  [round~] / [round] / [scale] /
[scale~] / [loadmess]*) and also correct some minor bugs, like the one with
triangle~ that I already fixed today, and also existing issues with [pong~]
plus an update to current Max version.

The repo is a fork from the last update in previous maintenance (cyclone
version 0.2beta1), which was on its own a fork from cyclone's repo for
version 0.1-Alpha56 (available in Pd Extended). I completely changed
the README.md from the previous fork. I reintroduced the
original project description from Krzysztof Czaja that had been discarded
and included notes on "Previous & Current state / Goals & Further
Development", sharing information/credit about past developments and
further development proposals.

cheers



2016-02-21 19:51 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> 2016-02-21 18:18 GMT-03:00 IOhannes m zmölnig <zmoelnig at iem.at>:
>>
>> this is about the worst possible outcome of the entire discussion.
>
>
> Agreed
>
> There's nothing stating that all those objects need to be in the
>> one-and-only library named "cyclone".
>
>
> Yep, but there's some sense it'd be a good spot and nothing says they
> shouldn't be in it too...
>
>
>> having two libraries with similar tasks and similar (but distinguishable)
>> names could be a win for everybody.
>
>
> Maybe more like virtually the *same* tasks. the new could include the old
> with updates (instead of just some separated objects) to keep related
> objects together (here's pong, but if you want pong~ from max 4.6 get that
> other library). Or... here's pong~ updated to Max 7, but there's and old
> library with pong~ max 4.6. The more you look at it, it's just weird.
>
> I hoped for a joint venture on the same project. I honestly think a fork
> like that seemed like a last resource deal, a very drastic measure. "Hey,
> this is a different name, but it's the same as that other one with a little
> extra updates". I also agree with the reasoning of Ivica, who said.
>
> 2016-02-20 14:04 GMT-02:00 Ivica Ico Bukvic <ico at vt.edu>:
>
>> The confusion one will have to deal with by creating cyclone/prepend vs.
>> <some-other-lib>/pong is pointless at best.
>
>
> Well, one way or another, this seems to be the outcome and I'm also deeply
> sorry for it too.
>
> But hey, there are others willing to help on this project, we could talk
> about the future instead of what could've been.
>
> cheers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160222/c860b656/attachment-0001.html>


More information about the Pd-list mailing list