[PD] consolidate backward- and MaxMSP compatibility in Cyclone

Miller Puckette msp at ucsd.edu
Wed Dec 30 20:10:46 CET 2015


Hmm... the more I read about this, the more I think the best thing would
be to do nothing at all.

cheers
Miller

On Wed, Dec 30, 2015 at 07:16:19PM +0100, Fred Jan Kraan wrote:
> Here my opinion on the situation. There is no license or law to guide or
> steer us, but past experiences can help decide which opinion leads to the
> best solution.
> 
> On 2015-12-25 08:28 PM, Alexandre Torres Porres wrote:
> >
> >2015-12-23 18:36 GMT-02:00 katja <katjavetter at gmail.com
> ><mailto:katjavetter at gmail.com>>:
> >
> >>   Summarizing, the discussion in this thread has so far rendered three
> >>   practical and simple solutions to improve MaxMSP compatibility in
> >>   Cyclone without breaking Pd patches (with average~ as an example):
> 
> >>   - MaxMSP compatibility through an extra inlet / outlet
> 
> > I still think that introducing an extra outlet is the least
> > complicated and least intrusive.
> 
> A signal outlet, at the right of a message outlet, is not very common for
> Pd. And it leads to an object doing two things. Because of POLA*, added
> complexity and work, it would not be my first choice. But not many objects
> are expected to have a fix like this, so just for once...
> 
> >>   - MaxMSP compatibility available through an extra operational mode
> 
> >Not sure how an "extra operational mode" would work, but seems a little complicated.
> 
> It would mean using an argument or message to switch behaviour. As average~
> already has two (optional) arguments, which become mandatory just to
> specify a third, I do not see it as a reasonable option.
> 
> >>   - MaxMSP compatibility available through an extra class
> 
> > An extra class breaks compatibility, as you need another class name -
> > seems like a drastic or last resource solution.
> 
> IMHO, this fits the situation best, as several objects have different names
> in Pd and Max/MSP. Apart from the extra object name.
> 
>       - MaxMSP compatibility available with a -legacy startup flag
> 
> The -legacy startup flag would mean you can have only one of the two
> solutions per Pd-instance. Introducing this flag (in Vanilla?) just for this
> object would be a bit of overkill.
> 
> So I will try to combine the average2~ functionality into average~.
> >
> >cheers and merry xmas
> >
> Greetings & happy 2016,
> 
> Fred Jan
> 
> 
> *) https://en.wikipedia.org/wiki/Principle_of_least_astonishment
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



More information about the Pd-list mailing list