please rename the library/project #27
Comments
|
Howdy, it's been too long and I never responded cause I had the plans to quickly provide some release and further discuss this issue. Well, it's been six months and although a lot of work is going on here, it is still far from an available release and I'm just sorry for the silence. There is one thing that I really wanted to answer you, when you say I did edit numerous time the readme file, but I never imposed more faithfulness on this repo part over anything else... all I ever did say is that "This repository is faithful to the original goal of cyclone in creating an external library with a collection of Max/MSP objects for Pure Data" and not that is "more" or "less" faithful than anything... About Krzysztof Czaja, it'd be good to have him around, I'd love that, but it seems he can't be easily reached to be inquired about his ground rules for letting others maintain and develop for Cyclone. Nonetheless, when asked about it by Fred Jan Kraan, Hans-Christoph Steiner, the last current maintainer at that time, did manifest his thoughts to the Pd-List, here cited: "About maintaining cyclone, I think a reorg would be great, and further So the only noted constrain about continuing to work with this project under the name of cyclone, by someone who had the torch in his hand, is that it retains its central and key goal of being a library of classes compatible to Max/MSP. And that was why I had the motivation to stress in the readme file that this central goal is being respected and preserved. I didn't mean to sound presumptuous with that statement at all... Furthermore, about "confusion", I did edit the readme file several times to add detailed information on the history of cyclone, about the version history, where they can be found, links are reffered to and I do provide more information about cyclone than anywhere else, so I think that because of this a lot of confusion is avoided, and things are even clearer. The readme also still says that this is project is configured as a proposal to an update of cyclone, and that when a proper release is due, we'd like to present the work to the Pd-Community to see if they are "ok" with it. I really don't mean to take over without consulting, but up to the moment, there is still nothing to be released yet and offered/proposed to the community for ti to check if this project is "faithful to the original goal or not". Perhaps in a couple of months a baby is out. And I wish then we could discuss it all on the Pd-List. Anyway, I wrote a lot, and this is because I never knew how to respond to this shortly, so I never did respond, and I'm sorry for the silence and delay... but for some reason I finally got to this today :) cheers |
|
given the recent talk on PdCon16 about the naming, i think that miller did have a point with the following (bear with me, I'm transcribing from memory):
|
|
yeah, his point was something about the idea that “cyclone" would be more attached to 'Pd-extended' than Max/MSP compatibility. We based a response on the quote from Hans (former cyclone and Pd-Extended maintainer): "If you want to stick to cyclone's central goal of Max/MSP compatibility, then keep working on it as cyclone. But please do not work on cyclone and break the Max/MSP compatibility". As we see it, this denotes an idea that cyclone is, before anything, a max compatibility library, a view that we agree with. I've been in touch with Hans recently by the way, he's seen our paper on the current development, so I could add he's quite aware and excited about our further developments. I can also report that the usual feedback we get is from people that relate cyclone to a max compatibility library regardless it used to be shipped with extended. Apart from this discussion, one way or another, the main issue is weather we're really breaking compatibility with older versions of Cyclone or not. Maintaining backwards compatibility was in fact one of the arguments I used in the PdCon talk in favor of keeping it as “cyclone”. Our primary goal has been to bring the existing objects up to date, this doesn’t really promote backwards compatibility breakage as that is not the intent of Cycling 74’s development to start with. |
|
So, developing on it, I can see how with all off the humongous overhaul that has been made you’d think that several changes needed to be made, but that’s not the case at all. We have a pretty detailed changelog and I can invite anyone that is concerned to check it. But I guess that maybe, if anything, somebody might find a little something and argue that particularly minor changes, even if they amount to less than 1%, will only make the library over 99% compatible. if it comes down to that, not only the changelog, but the project’s readme makes it really clear how this is a big update and how it differs from the latest versions, and also which was the version in the last Pd Extended. Please allow me to also reason and add details that the last cyclone version in extended (alpha56, out in Extended 0.43.4) did corrupt all my patches that relied on [cartopol~] to make spectral processing. So, being able to use things as in the last Pd-Extended is not necessarily a guarantee of things really working. In fact, this is mostly why, to this date, I still use Pd-extended 0.42.5, though I also found other issues in 43 that made me stick to 0.42… So, last cyclone in extended makes me speak as someone who already had to not adopt the latest cyclone (or Extended) cause it had issues with backwards compatibility. Not only that, but you can also find that 0.2beta is not 100% compatible to the latest extended, as it removed libraries and also changed library names (we do mention it on our paper, and how we are even restoring this to the original). Moreover, we now have conflicting “cyclone 02beta” releases in deken. Mac and linux have 0.2beta1, while windows has 0.2beta3 - these aren’t fully compliant to each other, which makes cyclone, as it is, not cross platform (I tried raising this issue on the list by the way). I guess what I’m trying to say is that, though we try the hardest, 100% might be too utopical for real software development reality… if our development isn’t free of any issues, it’s not anything new in the Pd and cyclone ecosystem. And about that, I don’t think older versions of cyclone should be removed or ditched, and I’m more than glad cyclone 0.2beta is around, as I think it is a great release and also that it should be kept distributed as a legacy library. And just like I still can get and use Extended 0.42, people should be able to keep using it if they want to. I think it all really comes down to usual practice in software development, and that versioning and documentation should be enough to deal with it. We in fact have documented our project very well to describe about earlier versions of cyclone and point to them. And I’m actually seconding Dan Wilcox on this, from a previous discussion in the Pd list exactly about this, when he said, and I quote: “What about versioning? If people have to have older compatibility, then why can’t they just run an older version of cyclone? Newer development can take place on the current version and you can clearly note api changes/updates in a CHANGELOG (…) This seems to work fine for all sorts of software libraries and deken should make it much more possible in pd.” so, this is not saying, "yeah, we broke a bunch of stuff but let's see it this way", but more like "we really cared about not breaking stuff, but - even if that would be the case or if minor issues end up to arise - there is this reasoning" cheers |
|
So, we clearly think there are advantages in keeping it as cyclone and disadvantages about changing the name, but we didn't really dedicated time in our talk to share more about our view point. I'm mostly replying to cases being raised against it in here, so please allow me to also better share our view point as a case being raised in our favor. I'm just gonna quote a couple of paragraphs from the paper we presented as I think it points it well. In fact, we didn't mention that in our paper talk, but Katja did point it some of it out on her own for us, sharing a similar reasoning how it makes sense to keep them with the same name. Here it goes: “Suppose we were to release our work under a different name (“Recyclone,” say), as a drop- in replacement for Cyclone. Recyclone would be identical to Cyclone in some respects, and its differences would be non-arbitrary because of the straightforward goal of Max/MSP compatibility. One obvious downside to this is that users who wanted to switch from Cyclone to Recyclone would need to change namespace settings in their existing patches. The larger point is that since the purpose of each branch differs only in that they target different versions of Max, they seem as much like predecessor and successor versions of the same software as the different versions of Max do. All of the predecessor’s functionality is included in the successor’s, with only minor changes. |
|
As a longtime user of Pd, Pd-extended, Cyclone and Max - I think it's important to keep the name Cyclone for this project. It's clear that Cyclone project is/was/always has been centered around Max compatibility. In fact that's the whole reason it exists, and is named 'Cyclone'. It is super exciting that these compatibility objects are getting thorough updates - making that compatibility better. I saw the paper presentation, and Miller's comment - and while I understand the usefulness of maintaining pd-extended compatibility because there is/was a large userbase for pd-exended, I don't believe that burden should hold back active development on Cyclone, or that the active development on Cyclone should have a new name. Cyclone is one of many libraries that shouldn't be forced to stagnate due to pd-extended compatibility concerns.. Aside from that - it doesn't sound like much breakage will come from extended users using updated Cyclone anyway. There are a lot of longtime users of Cyclone (like me) who have always used it for Max compatibility and are excited about better/updated max compatibility. Cyclone is canonically the place we've always gone for that. One of the things that makes Cyclone a great project is that it eases transition to PD for new users who are coming from Max. In my opinion it would be a shame to obfuscate this useful library by having multiple major forks simply to maintain already tenuous pd-extended compatibility. |
yeah, but let me reinforce and highlight - amongst all I said - my argument that even this doesn't really exist by now. The last cyclone in pd extended (available in deken) actually basically breaks extended patches up to 0.42-5. For that, the actual best thing would be to have perhaps alpha55 up (the one before that).Moreover, cyclone 0.2beta is not also 100% compatible, by getting rid of maxmode and other stuff (such as the 'cyclone' library, which was renamed: a change that we are reeverting back tio the original, by the way) |
|
I figured I chime in here: As for Cyclone being associated with pd-extended compatibility, at least in my case (which could be different from others), back when I used pd-extended, since namespaces weren't reinforced as in [cyclone/object] since all subfolders were in the paths or loaded at startup (can't remember exactly how it was), I didn't really know what object was coming from where. Scope~ could've been coming from maxlib or even the core library as far as I knew and I suspect this is the case for many casual users of Pd. Plus, if I remember correctly (perhaps I'm not, but refer to our paper) but Cyclone existed before Pd-extended or at least as a separate entity before being taken over by Hans, who does see it as a Max clone rather than a Pd-extended compat library. Despite this, it is clear that the notion that Cyclone is a pd-extended compat library at least present and should be acknowledged. In terms of backwards compat, there have been precedents of newer versions of the same software with the same name breaking backwards compat with previous versions, see SuperCollider 2 vs 3, Python 2 vs 3, Lua 5.2 vs 5.3 (kinda weird how it's all 2 vs 3?). Anyways, perhaps those aren't good examples because those too have drummed up all sorts of conflict and controversy within their respective userbases (like the maintainer of LuaJIT not wanting to update from 5.2 to 5.3, the eternal Python 2 vs 3 debate) but I'd argue that Cyclone v3 vs v2 is breaking less than any of those examples (if anything) at least in terms of argument and inlet format (although there are some notable changes, like average~ I just worked on changing from a control outlet to a signal outlet) and most of the changes have been functional. The issue is that most of the functionality changes were corrections to improperly implemented functionalities in the first place and were bugs (such as the average~ thing, comb~/teeth~/allpass~ using the wrong diff eqs, etc.). I suppose then the issue is that since these bugs were present for so long that it is certainly possible and perhaps probable that many of these bugs were relied upon in previous patches. Like Alex, I would argue that Cyclone v2 is still available and not going anywhere (and still being maintained by Fred). I do think that changing the name would bring about unnecessary confusion and I think that Fred and Hans (somebody correct me if I'm wrong) are okay with this update keeping the name Cyclone? The bugfixes are well documented (thanks Alex!) and perhaps a compromise is to make in the docs clearer the fact that this version is NOT 100% compatible with previous versions due to bugfixes and point out that if the user wants to keep guaranteed 100% backwards compat, they should seek out v2, which is still available for download from Fred's github, puredata.info, and deken (and even link to those sources in our docs). Thanks IOhannes for bringing up your concerns on Pd-extended compat, I do think that this project should continue on as Cyclone, but the needs of users expecting 100% backwards compat with Pd-ext should be addressed more in our version's documentation |
|
thanks @derekxkwan : you are certainly aware that all those with big version change projects you mentioned ended up with:
AND (more to my point)
but maybe your suggestion is a feasible one: use |
|
Is there a reason to change the name (even to Cyclone3) - vs just versioning it - if it doesn't contain major compatibility breaks? It sounds like there is little to no compatibility breakage here - so it sounds like we're talking about just a normal software version (with a new dev team), not a name change right? Then we can avoid the splitting the user-base issue etc. It sounds like it breaks things even less than some previous versions did... |
ok, maybe not that much, but not more, I can only think of 1 case and it was strongly documented and is less than 1%
I guess this issue was raised in a time where future was not certain, and perhaps there would be two independent developments for cyclone from two parties that were not the original gang. It was a request that made sense then when maybe considering both to not be named cyclone. But the thing is that there was no other development by the part of Fred, and his package is still named "cyclone 0.2". I personally don't have any problems with that and i like that it differs from earlier developments versioned as "0.1", and I vote that it just keeps like that. Though it might have been unclear how things would progress, the truth is that Fred Jan from the very start graciously and kindly started referring to our branch as the one in active development, and linking his repo to ours. Though I can't speak for him, there was never a real conflict on his part that would point to him being against our development, on the contrary. This was even reinforced now in the PdCon with all of us meeting in person, having beers together, and not really discussing this as an issue even when we openly asked for any thoughts he might have in our talk. So I'm not taking many risks by guessing he is fine with it.. I will take the liberty to talk more in the name of Hans, who I've been in touch with recently, and we surely have his blessing.
this is already happening, read it :) |
|
@jmej the reason i'm so persistent, is that we currently have two projects, both forked from the original i wouldn't raise the issue at all if this project were the sole successor |
|
good you mentioned that @umlaeute - like, one second before I did post something about that, rs, I agree with this reasoning, but please see my remarks - I gotta teach a Max/Pd class now, bye :) |
|
(Matt Barber here) Before we make any decisions, let's go through everything again and see what could break in a patch made in pd-extended. I suspect all of the discrepancies could be addressed by having the object post a note in the console like [pow~] did. "Both being actively maintained" equivocates a little. It reminds me of how an old OS version that hasn't yet reached "end of life" will make security updates and major bug fixes, but no active development, which is restricted to the newer version (again, not a perfect analogy). The newer version also does similar security updates and bug fixes in addition to development. Both are being actively maintained, but what that means is different in each case. I could be wrong, but I don't think Fred Jan is adding any new features. |
|
as for bad analogies: sure; but the new OS is likely to come under a new name that makes it distinguishable from it's ancestor. afaik @electrickery is indeed not adding any new features. That (not adding, maintaining) seems to be the objective of his cyclone development. Which makes it hard to argue that his version should go under a different name than (and ftr: @brbrofsvl i ❤️ that nick) |
|
@umlaeute : I like that idea! Sounds like a worthwhile compromise that can be considered amongst ourselves and the Pd community. Your solution does acknowledge that this is still Cyclone but at the same time different from Cyclone v2. I do think that in terms of end-user experience, it is better to err in the direction of obviousness and I could imagine even if Cyclone v2 and Cyclone v3 were readily available (and I do see this being the outcome regardless of the naming situation), getting e-mails from users saying "Hey, I downloaded Cyclone, how come this pd-extended patch from 2005 doesn't work?" having downloaded Cyclone v3. In the end, I suppose personally I won't be terribly upset with either outcome, whether we end up with Cyclone v3 or Cyclone3. I do tend to err on the side of breaking backwards compat when it makes sense in the name of progress and do think there's a danger to be overconcerned with backwards compat, but again I don't have much personally invested in this as I've only become a heavy Pd user as of late. @brbrofsvl : average~ changing from float to signal outlet and the funnel_bang method are the major ones that pop up, although there are possibly more. |
|
@umlaeute : I guess I don't see why they can't both be cyclone. We've lived with Wheezy and Jessie for a year and a half, but they're both still Debian. Cyclone obviously has nowhere near the userbase and visibility of Debian, Python, or even SuperCollider, so nicknaming individual releases probably doesn't make sense here. I'm not sure I like cyclone3 as a solution if only because it has nothing to do with Max 3. Let's review the major changes and see what we're up against. -- I chose brbrofsvl in 1995, and it stuck. |
|
I didn't and wouldn't argue that his version should go under a different name than cyclone, but I still don't see the argument ours, for one, should. If we're comparing to his, what is the difference? The reasoning here seems to be compatibility breakage, but where is it? Have you found a significant one or any? Why isn't versioning enough in this case? Have you also considered our point in the advantages and reasoning in keeping the same name? I did point good reasons for keeping the same name and I'm also trying to point that we do not have any significant change in that regards, at least not more than before. I did argue how changes were even made in Fred Jan's package that compromised such scrutiny on backwards compatibilty, to the point where we are reverting it back to the very case of keeping a neglected legacy backwards compatibility issue... I see the point, but I'm trying to say it is not like that. And if it is to any extent, well, the same scrutiny maybe should be applied to former maintenance, which wasn't free of that (why the special treatment, right?). Again, I'm not saying that cyclone 0.2berta shouldn't be called cyclone because it removed and changed the basic structure of the old cyclone... I say it should be versioned as cyclone 0.2, and our should be 0.3 and that this is enough for what we really have going on here. Maybe comparisons to python or whatever obfuscate what we really have here, and maybe we should look into it. |
|
@umlaeute we seem to be addressing different things sometimes, so here's a question that might make this dialogue easier to conduct without talking past each other. Have you found an actual major, disqualifying discrepancy, or are you basing your complaint on sheer principle? Here are some things that might convince me that a name change is appropriate:
Complicating all this is the fact that Ivica and Jonathan want our update in l2ork/purr as cyclone, and some of the Pd-extended users are moving to l2ork/purr as it becomes stable. I appreciate everyone's thoughts as we reason through this. It was great to finally meet all of you at PdCon. |
|
Changed appeared gradual for cyclone, and usually for a reason. The original distribution consisted of two library packages, hammer ans sickle which represented cloned objects from the two parts Max and MSP as these existed in Max/MSP 4.x and Max5. A separate cyclone object was used to load these libraries and the bin-ops (located in the source file nettles.c). All objects were also separately build. All the stuff from Krzysztof, including Cyclone was imported into Pd-extended as a separate directory, miXed, complete with its own quite elaborate build system. Somewhere in this timeframe the upper case objects were aliased as lower case. With the port to github, cyclone was lifted from miXed and the build system replaced by pd-lib-builder. Building the hammer and sickle library objects was removed as was the cyclone object. The binops were experimentally restored as nettles. Only a few were unique, most were available from other libraries. The original plan I had with cyclone was to keep it working and compatible with the pd-extended version. The Pd-community used it for more than ten years and that was more important for me than everyone coming over from Max. Cloning more objects from Max was only considered if it was useful (not all Max5 objects are IMHO), and it was not already present in another library (who needs more clones?). In the latter case the differences will be bigger than the minor incompatibilities between Max and Pd plus cyclone objects. Like GOP is quite different from bpatcher. The advent of the more Max oriented direction of cyclone is not something I wished for, and I still don't like it. But that is my personal opinion and not a very good reason to try to stop it, even if I could. If the team succeeds in making a stable release, for all main platforms and which remains compatible with Pd-extended, I even could remove out the 0.2beta releases. I don't want to add to the confusion by trying to maintain a separate version. That won't make anyone happy. Greetings, Fred Jan |
|
Hi Fred Jan, it was very nice to meet you in person and I think is great that you are joining us in this discussion, we were really interested in what you had to say. Well, since I mentioned about changes in your work, let me develop on that. First, I didn't mean it in a bad way, and in fact we agree in many of the changes. Cyclone in Extended seemed to have been messed with a little. It was the common practice in Extended to use single binaries for each object and the libraries (maxmode/sickle/hammer/cyclone) ended up not being used. But I was able to check throughly and see they were still there. Perhaps by accident or something all these libraries ended up inside the 'maxmode' folder. I have Extended 0.42-5 and I can also see that it tries to call for the cyclone library, but it doesn't find it because it it 'hidden' in this subfolder. I consider this a bug in Extended that nobody did spot. It seems like it wasn't the intention of Extended to get rid of the libraries... ans if you manually fix it and find it (say, move files or change path) it still loads the cyclone library. Here I have Extended loading the cyclone library correctly, you can load signal and control objects plus the bin-ops. We can see how maxmode and cyclist don't have a place in today's world and totally agree with that. I don't see it as a particularly bad thing to have objects loaded as single binaries instead of hammer and sickle, but the cyclone library was needed to include the binops. With the port to github, cyclone was lifted from miXed and the build system replaced by pd-lib-builder. Building the hammer and sickle library objects was removed as was the cyclone object. The binops were experimentally restored as nettles. Only a few were unique, most were available from other libraries. If you mean most were in zexy, that is not true, out of the 12 binops, only 3 were in zexy. Anyway, again, removing maxmode and cyclone object (cyclist) is what we also think was reasonable to do, but I don't see why getting rid of the libraries, and this is something I think about getting back, for the sake of being faithful to the original project. An idea is having cyclone also as a library as it used to be able to load, containing all signal/control objects and the binops. One change I did from your work was not adopting a new library name 'nettles' that never existed in cyclone, as I think this was something new that would break compatibility with the original project. So we have a cyclone library back as originally, but only containing the bin ops for now. This is me just clearing out what I said about your branch also having issues in changing legacy things, and I don't mean it as an actual criticism, as a way to point a finger, I'm just using that example to say we really care about being faithful to the original project and not breaking compatibility, and that we are not really changing it more than it was changed before... because this seems to be the biggest concern in what we are doing. cheers |
|
forgot to post my picture on loading the cyclone library in extended with the binops and everything, all i did to fix it was correct the path to cyclone/maxmode, where it can find cyclone and the other libraries |
|
I can also remember our discussion in the pd list, when you were telling us about removing these libraries, and that the 'nettles' objects would be lost, but that it probably wouldn't matter since they were available in other libraries. I did reason and argue that you should try not to get rid of 12 objects, and that they were useful and some unique. I can say that if it wasn't for my case against it, there's a chance they might be missing now in your package. Far from raising any dispute, I'm just trying to defend myself in the community. seems like the former maintenance decisions weren't being questioned as much as ours. If anything, I was the one who did question them and insisted to keep things the way they were, and I'm even reverting some of those changes back to the original. |
|
@electrickery you bring up a good philosophical and pedagogical argument Re: the usefulness of "black boxes". [Counter] is a classic example. Having led a lot of pd workshops and as a max teacher, I've found that (especially for artists and non-programmers) - it's always better to leave the actual construction of a counter for later lessons (if at all). That type of feedback logic and understanding of idiomatic hot inlet behavior is too much for a first lesson. Max is much easier to teach to non programmers for reasons like that. I do wish that things like [counter] were abstractions in max - so that the could be opened and understood when people get ready / curious, and I could actually see a super compelling argument for a fork of Cyclone made entirely out of abstractions. That of course would for sure need a different name. Ultimately - I think Cyclone with its original goal of max compatibility is an hugely important project, specifically because so many students are currently in classes all over the world learning max. The reasons they are learning max instead if pd are many, and a bit off topic, but the fact is they are taught max. Cyclone (in any form) is extremely useful in helping those students transition to pd. It is often the difference between pd being immediately discarded because new idiomatic knowledge like building a counter isn't required off the bat- and in turn this builds the Pd community. The better it gets, the more new pd users and contributors we will get. I think the name is important, and I don't think the legacy of pd-extended should erase the goals and growth potential of the Cyclone project as a max compatibility library. |
|
[list-drip] is a black box for anyone who doesn't care to go through the patch and understand it (as is, for that matter, [list prepend] for anyone who doesn't look at the code). I wrote my Master's thesis on the black-box problem in pedagogy; it basically always into a "pick your battles" kind of effort, because it's black boxes all the way down, and it can be hard to find the right frame of reference (this is especially true in something like SuperCollider in which almost everything you actually use is an object inheriting from several lower-level objects). |
|
Yep - 'pick your battles' is exactly it. Although those max black boxes really are black boxes for anyone who doesn't work at cycling74 since we can't look at the code. |
@jmej - I don't think either, but I hope my point is being taken here when I keep repeating myself that, one way or another, this is not the current case, at least not more than it has been already. This point of mine makes raising such an issue of discussion pointless. |
|
well, i've been working on a defense case that our repo is not having any relevant change in pd extended compatibility, and how any minor issue one could find is not different than what already has happened. But even if I make a good case about it, there still seems to be more stuff to reply to...
So, about the case of conflicting repos, discussion here doesn't seem to show a dispute and conflict of mentalities. Fred Jan has a personal view but, in his words, even if he could, he wouldn't oppose to our current cyclone development, or claim his distribution should be "the cyclone one". Far from trying to raise any dispute over which should go under a different name, even if at first it seems hard to argue his version should, I wanted to point that it wouldn't be free of criticism. 0.2beta comes with a new readme file that strongly differs to the original one and even states how max compatibility ins't a concern anymore. This happened even though Hans did manifest a simple ground rule for further cyclone maintenance: 'max compatibility' - which has always been cyclone's motto, although it didn't reach that goal perfectly for it was made available still in an 'early stage of development' (a quote from the original readme). Another thing I didn't mention is that 0.2beta introduced a change that broke Max Compatibility. The [coll] object has since Max 4.0.8 taken a 2nd argument. Cyclone 0.1alpha01 came out in 2002 without it for being still outdated to Max 4.0 (even though 4.1 was already out), but cyclone 0.2beta introduces a 2nd argument to [coll] that nothing has to do with max compatibility, thus breaking it. I can assume it wasn't in Fred Jan's intent as it seems he was just giving in Ivica's wish to have his [coll] version in cyclone. But this happened anyway: -A) Max compatibility wasn't focused anymore as a central goal in the readme, -B) a change in one of the objects broke max compatibility. One could argue those two things play against the basic ground rule (max compatibility) that was given by Hans as the former maintainer passing on the torch. And that if an independent cyclone project expressed a different motto in development and started breaking compatibility, maybe it should change the original name. I'm clearly not implying that to 0.2beta, and I wouldn't like cyclone 0.2 ever to disappear from the ecosystem, even if ours ends up being considered stable and fully backwards compatible. Fred Jan suggests that by saying
This is a good quote that corroborates my idea we're not in the midst of an actual dispute over which is (or would like to be) the "sole successor" of cyclone - a motivation for @umlaeute to persist on this issue. But I can add that removing cyclone 0.2 would make me really unhappy, as I love to keep track and record of software development (I did the history part on our cyclone paper by the way). If anything, I have a real strong opposition in keeping cyclone 0.1alpha56 in deken (it comes as 'v0-0extended'). It is "The last canonical extended version" but it broke spectral processing patches. I'd love to also have an ultimate extended version around, as Fred Jan's package is not 100% extended compliant, but please not alpha56 as it is. Maybe fix it's minor issue (reverting a sign in poltocar~), call it 'v0.1-0extended' and keep it there - or maybe put up Czaja's last one (alhpa55) which was free of that. Anyway, truth is that this version is no good and makes no join effort being there! But I wouldn't be honest if I didn't say I hoped some changes were restored back in cyclone 0.2 to keep it more aligned with our current work: A) Changing the original Cjaza's readme or getting rid of it - I have to confess - seemed serious. We're bringing the original readme back and referring to it, and also saying how we are faithful to this central and original goal of max compatibility, that's a big difference. B) A new library arbitrarily named as 'nettles' instead of the original one that carried those objects breaks compatibility to the original cyclone and extended. We're restoring the 'cyclone' library back. C) The introduced functionality in [coll] breaks compatibility to Max 4, and any extra desired new feature shouldn't break desired Max Compatibility. We're removing the extra functionality until it is stable in cross platforms and will bring it back not breaking Max compatibility (Ivica, who formerly desired this feature in cyclone, is happy with our decision*).
cheers |
|
@electrickery said:
That seems to point to the crux of the disagreement, yes? I'm not as much an expert on the history of the thing, but Hans seemed to think that the "Max-oriented direction of cyclone" was simply the essence of the library – it's raison d'être. Fred Jan seems to think cyclone's value lies in it being a thing-in-itself – on this reading it is a useful collection of objects that was once inspired by Max, but its strength lies partially in its individuality over against whatever direction Cycling74 took Max. Is this fair? Arguing about essences is about my least favorite thing to do, but I did get the impression when I was a n00b that cyclone seemed to have this completely different valence from e.g. zexy. In some Pd circles zexy was kind of an "insider" library, while cyclone had more of an "outsider" (and sometimes stigmatized) vibe, which I always attributed to cyclone's status as a Max library (or worse, a Max-enabling library). I agree with @porres that simple versioning gets the job done as long as deken is here to stay in more or less its current form. But perhaps there is a way to make the versions applied to the package say what they do, which would mean something more descriptive than simply 0.2 and 0.3. I'm having trouble imagining a scenario where a user would want access to both libraries in the way making separate cyclone and cyclone3 namespaces would make possible. These libraries are not different enough to justify that IMO. |
readme and specially changelog also do that job, not to mention documentation, I'm working my best in those 3 ends to get this really clear - not to mention our paper on it! |
|
@porres yes they do, but users don't see those things in deken; I'm talking about making it very clear when you search "cyclone" what the respective versions are. |
|
I wouldn't put too many hopes into overloading the people also don't read READMEs. @porres if you want to have deken include |
They seem quite clear to me @brbrofsvl , as they carry the version name already. Currently, you can even differentiate in deken that there is a cyclone0.2beta1 for mac os and a cyclone0.2beta3 for windows. This is, by the way, confusing to me. Why are there two different versions for two different systems? It makes it more of an issue when you see that these versions have conflicts that are not documented. What is not clear is what cyclone-v0-0extended is. If people do not read the readme often (what I agree), the only way to find out what that version is requires the user to know and look for a cyclone-meta.pd file, to realize it is then the 0.1alpha56 version. If we are talking about generating confusion, things seem pretty confusing to me right now: two conflicting versions of 0.2beta and a version given as ‘v0-0extended’ that doesn’t make it any clear if it is an earlier or later version. But the v0-0extended version at least makes it clear that it is related to Pd-Extended, suggesting 0.2beta isn’t as compliant to extended as the other (something I’ve been actually arguing to be true), nonetheless, order of generation remains unclear.
Now, if a new cyclone0.3 shows up in deken, we don’t really have to worry about more confusion. On the contrary, because, as opposed to how things are right now, there’d be a pretty straightforward generation mark (implying quite clearly that 0.3 comes after 0.2)!
I guess I could, but I wouldn’t want to just do that right now, as things would make it even more confusing, with 3 versions up: 0.1alpha55, ‘v0-0extended’ (which is actually 0.1alpha56 but hard to know) and then 0.2beta. Who would be able to tell the order of such versions? I do argue that 0.1alpha 56, or ’v0-0extended’, or whatever you may call it, doesn’t help being there, as it is a particularly problematic version. It broke important features and it isn’t the actual legacy version that had been in extended for the most part (cause alpha55 was the one in it for virtually all its major course, during 7-8 years). So, I’d rather have 0.1alpha55 in deken instead of ’v0-0extended’, but not just throw that in it too. There would be other options out there besides it that I’d also prefer. Basically anything that doesn’t involve keep distributing 0.1alpha56 in deken. From simply removing it, to replace it by 0.1alpha55, or even just fix it, as alpha56 also introduces nice changes (as the lower case name aliases) - I dunno, fix the simple sign reversal bug and call it 0.1alpha56.1? I’d say it’d be desirable to have a nice working 0.1alpha release in deken with both a clear 0.1alpha version name and also an ‘extended’ mark to relate it to it - but it seems to end up being clumsy and still unclear, let me try an example: cyclone-v0.1extended-1alpha56.1 - see? One way or another, seems less confusing to me to have a good representative of cyclone 0.1 era (alpha56 just isn’t a good representative and its versioning is virtually hidden). So, nowadays, as an example, if we had just two versions like: That would work great for me. Not confusing at all, and it’d be clear that 0.2 came afterwards. Cyclone 0.3 eventually and possibly joining this system would be fine and keep the logic. |
@umlaeute Agreed, or search for -meta.pd files for that matter, but they can tell a clear progress order from 1 - 2 - 3... I said I worked on those, but I'm also working on a major documentation overhaul and including such things. First, if anybody ever opened any help file for any cyclone object, it'll look pretty clear that the current version has a new look and design. Moreover, when loading the cyclone library, the version name sticks out in the Pd terminal like this:
I'm also considering putting up a compilation date on this print, like it is done with zexy. This is what the new design template looks like currently
I wanted at first to make the cyclone "logo" to also carry the version name, but Jonathan Wilkens opposed to it, convincing me there were several other ways to keep track of versioning, but this discussion is making me reconsider it and maybe go back to that original thought of mine to something like this
The project also carries a [pd All_About_Cyclone] subpatch at the bottom of each help file, and it really tells you all about it, which version it is, it points links to the github/readme, changelog, instructions on how to install it and more, here's an excerpt
This is all still in current development and the information can still be improved, but I think our work tries really hard (and much harder than before) to make it pretty clear about which version this is and what you're getting with it. |
|
A lot and too much has been said already, I'll just try to wrap up objectively the points I've been making:
|
|
hi, it's been very quiet here for 2 months now, so I'm closing the issue, but I'm still raising this once again when we release our 1st alpha version to the list, which is due anytime now |
|
hmm, i don't understand why you close the issue if you want to raise it again. |
|
yeah, I think this discussion amongst us it is resolved, and I don't wanna reopen it again. what I meant to say is that I'll still mention about this discussion in the pd list at the time we release the alpha1 soon, to see if anybody else cares to talk about it over there. |
after all the hard words on the pd-list, i would kindly suggest to change the name of this project away from "cyclone", in order to avoid confusion.
whether this repository is more
faithful to the original goal of cyclonethan electrickery/pd-miXedSon is something that only Krzysztof Czaja has the authority to state.i still think that
pd-recycloneis a great name 😄The text was updated successfully, but these errors were encountered: