[PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

Tue Dec 22 16:48:45 CET 2015

Pd is a programming language and I cannot think of any long-lived language
where things did not become deprecated and/or required older code authors
to make minor changes to ensure it works on newer versions of the same
language. I think cyclone would do well to follow this mantra and by doing
so gain greater nimbleness in terms of development. Besides, given Pd's
patches are plain text files designed to be easily parsed, most such
changes could be addressed by a simple shell script that updates/retrofits
old patches, as needed. In the latest version of pd-l2ork I've added
-legacy flag which reconciles inconsistency with the iemgui object
positioning, similar approach could be made with these, although this will
likely increase maintenance overhead and thus diminish the aforesaid
nimbleness.

On Tue, Dec 22, 2015 at 9:51 AM, katja <katjavetter at gmail.com> wrote:

> Hello Alexandre, Fred Jan, pd list,
>
> It makes me sad to see your earlier productive collaboration on
> Cyclone stagnating with this dispute about the purpose. Between 2005 -
> 2015 the purpose of Cyclone has been determined more by what it was
> than by what it should be, by lack of human resources [1]. With the
> recent increased effort of testing, fixing and innovation there's an
> opportunity to redefine intentions and ambitions. Let's try to figure
> out a generic approach where backward compatibility doesn't conflict
> with MaxMSP compatibility and innovation, so anyone can contribute to
> the project according to their skill, interest and ambition.
>
> My proposal would be to sacrifice forward compatibility of older
> versions if needed. Classes which pose the compatibility dilemma may
> be made to operate in multiple modes. Sometimes this can be achieved
> by message, and when the number or type of inlets / outlets are
> concerned (like average~) it can be achieved with creation arguments.
>
> Now you have to decide which is the default behavior. With decades
> worth of Pd patches in mind it seems logical to keep the original
> Cyclone behavior as default and offer the MaxMSP compatible mode as an
> alternative. The help patch demonstrates how to use the newly
> developed mode. A class setup message can advertise it too.
>
> There's always this caveat with introducing new message selectors and
> creation arguments: old versions of the class don't support them so
> you could still end up with broken patches. But this is less
> problematic than backward incompatibility. The class help patch must
> give clear information about the version where new functionality was
> introduced, and anyone who applies it in a distributed Pd patch can
> inform the user about version requirements. No spurious malfunctions,
> but at worst a clear hint to upgrade.
>
> You may wonder what is my own involvement with Cyclone. At the moment,
> none apart from following the discussion. Earlier this year I spent a
> few months developing Makefile.pdlibbuilder as a generic build system
> for Pd libs. Replacing the indecipherable build system of Cyclone was
> the ultimate test case for this work, and it helped speed up Fred
> Jan's work on the library. I became aware how big a project it really
> is. It could use the love and care of more people besides Alexandre
> and Fred Jan.
>
> Katja
>
> [1].
> Cyclone (part of miXed) was unfortunately abandoned by it's original
> author Krzysztof Czaja after 2005. The ambitions with this wonderful
> project were then in practice scaled down to fixing bugs in the alpha
> versions, as illustrated by the commit history of it's SVN repository
>
> http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/miXed/cyclone/
> .
>
> On Mon, Dec 21, 2015 at 6:26 PM, Alexandre Torres Porres
> <porres at gmail.com> wrote:
> >
> > 2015-12-15 16:22 GMT-02:00 Fred Jan Kraan <fjkraan at xs4all.nl>:
> >>
> >> Hi Alexandre,
> >>>>
> >>>> Compatibility is limited to a very old version of Max/MSP.
> >>>
> >>>
> >>> That really confused me, as a Max 7 user...
> >>
> >>
> >> Why? If any version of Max/MSP looks like Pd, it is 4.6 (or maybe
> earlier
> >> versions, but I don't have access to those...).
> >
> >
> > Because it is not a matter on how it "looks", and Max 7 is still the same
> > patching environment, it's not like it changed and lost compatibility,
> hence
> > I'm using both Max 7 and cyclone and I'm happy about it.
> >
> > It's not like Max 7 killed and broke backwards compatibilty with earlier
> > versions and patches. So we don't have to consider it as having to be
> tied
> > to 4.6..
> >
> > Perhaps you mean we'll never be able to come close to what Max 7 is now
> in
> > general. But I don't think that was ever possible and the purpose of
> cyclone
> > was not to make a clone of the Max/MSP Software.
> >
> > I think this is a very serious and sensitive topic, as the purpose of
> > cyclone is not being really considered in your point of view, and this
> might
> > interferes with the purpose, or even kill it...
> >
> >>>>
> >>>> For me this makes backward compatibility more important
> >>>> than with an obsolete Max/MSP version.
> >
> >
> > If I got it right, you're basically saying:
> >
> > - Cyclone should be a copy of an outdated and obsolete Max/MSP version
> and
> > we shouldn't care on keeping up with improvements in Max because it is
> > impossible and only really likely or reasonably possible within the
> > limitations of max/msp 4.6 as a software.
> >
> > - Not caring about the developments in earlier versions of Max, we're
> stuck
> > to 4.6, but since it is an obsolete version of Max, we shouldn't care
> about
> > being faithful to it either, or Max for that matter.
> >
> > Thus, we'd basically lose the idea of having a library of objects
> compatible
> > to Max/Msp objects, and we also do not care of the original purpose of
> it.
> > Well, that is not a good take on my opinion.
> >
> > I agree Cyclone is now (and has always been because of its stage of
> > development) a copy/clone of an outdated and obsolete Max/MSP version.
> That
> > is why I think it's good we'd try to keep it up to date with and care on
> > keeping up with improvements in Max/Msp objects.
> >
> >
> >>> About [average~], the thing is that was wrong to begin with, it
> couldn't
> >>> load max patches in the first place, it should have been signal all
> >>> along.
> >>
> >>
> >> I agree average~ was wrong all along. But it has been wrong wrong for
> >> about twelve years. I do not want to invalidate twelve years of patches.
> >> If you want to copy a Max patch with average~ in Pd, you could use
> another
> >> object or an abstraction. PureData is supposed to be a tool to help
> >> understand DSP technique and make creative sounds. Not to be able to
> blindly
> >> copy Max/MSP patches.
> >
> >
> > Again... that WAS the purpose of Cyclone in Pd... to be able to implement
> > MAx/Msp objects in Pd - and that seems to be completely unregarded by
> your
> > development effort in Cyclone.
> >
> > Btw, let me post what the purpose of cyclone is still described as in
> here:
> > https://puredata.info/downloads/cyclone
> >
> > I'll bring some exerpts and highlight a few key words.
> >
> > Cyclone: a library of clones of Max/MSP 4.5 objects
> >
> > "a library of PureData classes, bringing some level of compatibility
> between
> > Max/MSP and Pd environments (...) In its current form, cyclone is mainly
> for
> > people using both Max and Pd, and thus wanting to develop cross-platform
> > patches.
> > Cyclone also comes handy, somewhat, in the task of importing Max/MSP 4.x
> > patches into Pd. Do not expect miracles, though, it is usually not an
> easy
> > task."
> >
> > The project description is outdated, see that importing max patches to Pd
> > was not a main goal then, and now we could basically forget about it -
> but
> > the main point still remains, which is being, first of all; 1) a library
> of
> > clones of Max/MSP objects; 2) bringing some level of compatibility
> between
> > the platforms; 3) allowing cross platform patches.
> >
> >> Indeed, for me backward compatibility more important than Max/MSP
> >> compatibility.
> >
> >
> > well, we have seemed to open this discussion because of that problem with
> > the average~ object... it's not really about the object though, it's
> really
> > about how you are interfering with the purpose of cyclone, and the action
> > you're taking is just a reflect on it.
> >
> > This is a sensitive issue because you're just killing the purpose of
> cyclone
> > to whatever you feel like, which is not clear yet by the way, and that
> is,
> > in my opinion, a Fork - you're creating a Cyclone Fork...
> >
> > Please be careful with that, and lets discuss if you really want to do
> that,
> > and perhaps this list should raise opinions about this. As a cyclone user
> > (perhaps the only one so far sharing an opinion), I feel really badly
> about
> > this.
> >
> > But the point I wanna raise is that You do not need to change the
> purpose of
> > Cyclone. There's nothing really that should encourage you to hop onboard
> and
> > change the course like that. Or is it? We've just touched this discussion
> > because of a silly object, and I suggested something you could do to
> avoid
> > breaking the purpose of cyclone and still maintaining the backwards
> > compatibility thing if that's important (just create a new/second right
> > signal outlet that is faithful to the original object).
> >
> > If you do that, we don't need to discuss how the purpose is changing, and
> > there doesn't seem to be any reason why it should.
> >
> >>
> >> Another reason is the limited time I can spend on maintaining cyclone.
> The
> >> 4.6 functionality is a useful, but somewhat arbitrary guiding
> principle. And
> >> as you observed, most of the missing objects are not that essential...
> >
> >
> > I get the idea that the developers may not keep up with latest
> developments
> > in Max/MSP, but that is not a good reason that it Should Not. In fact, it
> > asks for other people to join in and help with the project and just map
> what
> > has been done and still could be essentially done. I've also raised and
> > reported basically all the last major bugs...
> >
> > I have actually been doing that throughly throughout this year in an
> > extensive research of my own. I'm willing to collaborate. I've mapped a
> lot
> > so far, and I ask if my help could be accepted in this project.
> >
> > It's not like I have tons of things to do to make cyclone up to the
> stage of
> > Max 7.1 - it's just a not that big list of features that have been added
> to
> > the objects that I find most relevant and important - average~ being one
> of
> > them, since no other object in the Pd world seems to do what it does (it
> > behaves as very neat and nice average filter).
> >
> >
> >> But enough typing opinions for now, I prefer to do some improvement on
> >> cyclone objects tonight :-).
> >
> >
> > Well, hope you've made some cool progress, I'm really happy you came up
> to
> > help, this is a project that needed attention, but I also think these
> > opinions are important and I even hoped we had discussed them before. I
> hope
> > others in the list could share their thoughts. I'm really concerned here
> on
> > the direction this is taking. I hope we can still maintain the main
> purpose
> > of cyclone.
> >
> > cheers
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151222/c337fc84/attachment-0001.html>