Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone

[Alexandre Torres Porres]

Hi, I'm coming back from summer vacations and I wish a great 2016 for
everyone. By the way, as I believe, this year marks the 20th anniversary of
Pd, when and where's the party?


> A signal outlet, at the right of a message outlet, is not very common for
> Pd.
>

true, I can think only of sampstoms~ and mstosamps~


> it would not be my first choice. But not many objects are expected to have
> a fix like this, so just for once...
>

Exactly, that's how I feel, this is hopefully an one and only exception
case. I've been extensively checking all objects and this is the only one I
found an issue with backwards compatibility.

I still owe to the Pd list what I've listed as relevant regarding future
developments in cyclone (making it more up to date with newer Max
versions). It's not that much as I've said. I'll start a new thread soon
about it.

I was recruiting help in the development of cyclone as well and some people
showed interest, lets see how that goes.

thanks and a happy new year.
Alex

2015-12-30 16:16 GMT-02:00 Fred Jan Kraan :

> 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 > >:
>>
>>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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone

[Fred Jan Kraan]

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 >:


   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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone

[Jonathan Wilkes via Pd-list]

For backwards-compatibility, I think the gold standard from usability 
standpoint is the way the 0.37 GOP interface is handled.
If you didn't even know there is an old style GOP that displays properly by 
default, then congratulations!  Welcome to the gold standard of backwards 
compatibility.
-Jonathan 
 

On Wednesday, December 30, 2015 1:16 PM, 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  >:
>
>>    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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone

[Miller Puckette]

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  >>:
> >
> >>   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@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

I guess I'm responsible for too much works on this matter. I was mostly
concerned on how this issue was being faced in the maintenance, where
max/msp compatibility seemed disregarded. But it's cool there's an idea it
must be considered.

Now, when it comes down to it, it's not like this seems to be an issue
that'll raise up so much.

“*Max 7 now uses a larger buffer on this object” and making the buffer
larger doesn’t actually change how the expected out of the object works,
why not update it?*"

That, for instance, is what we'll basically deal with... and only reason
not to update is "don't have time" or lack in collaboration. I've found
some people who'd be willing to help. lets see.

"*What has max changed object-wise between 4.6 & 7 that actually breaks
things? I'd say very little*"

I haven't seen any breakage yet and I assume they care for not breaking, so
I doubt we'll have to deal with this, so maybe we don't need to spend this
many words on it.

What we basically have, so far, is one object, which has been considered
"wrong all along", so it's more of a matter on how to fix it and keep the
older behaviour for the sake of not breaking patches.

I don't believe we'll have to deal with more errors like that or breakage,
hopefully this is the only one to arise. So we may as well treat this as an
unfortunate and special case, and think what's best for it... same with
another one *if* it comes up.

2015-12-23 18:36 GMT-02:00 katja :

> 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
>

The case with [average~] is that it wouldn't require an extra inlet, only
an extra outlet in fact, so it's simpler.


> - MaxMSP compatibility available through an extra operational mode
> - 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. Not sure how an "extra
operational mode" would work, but seems a little complicated.

I still think that introducing an extra outlet is the least complicated and
least intrusive. I've made a test help patch to illustrate it's a simple
fix.

cheers and merry xmas


new-help.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[katja]

On Wed, Dec 23, 2015 at 4:44 AM, Dan Wilcox  wrote:
> 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. Say tag cyclone right now as version 1.0.0
> and all further development is version 2.0.*

Versioning is important but it can't solve all issues that arise when
diverging. While it is easy for a user to update to a specified
version of a library with deken, Pd patches already out there 'in the
wild' (to quote Jonathan) don't specify which version they need.

Katja

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Dan Wilcox]

Oh I know. It just seems a shame to say: "Well, somebody might have a patch 
somewhere from 10 years ago that relies on a 10 year old version of a library 
that mimics a 10 year old version  of Max running on a 10+ year old computer/os 
and we can't break that, ever."

For vanilla objects yeah, I get it, but for externals isn't it also reasonable 
able to say: "It's been 10 years maybe I might need to update that patch that 
uses that 10 year old external lib."

I'm not saying break things arbitrarily but, in the case of Max, they don't 
want to break people's patches either (and I bet there are more patches out in 
the wild than Pd patches). What has max changed object-wise between 4.6 & 7 
that actually breaks things? I'd say very little and, if so, the whole argument 
is kind of moot so why not just introduce those non breaking changes made by 
Max?

If only we had someone who could extensively test, compare versions, and make 
notes about these differences. That would make not easy to see what might be a 
problem an what's easy to add. Oh wait, hasn't Alexandre been spending alot of 
time doing just that?

IE if an object historically had one output and and update adds another, how 
does that break old patches that only use 1 output?

enohp ym morf tnes
--
Dan Wilcox
danomatika.com
robotcowboy.com

On Dec 23, 2015, at 4:29 AM, katja  wrote:

> On Wed, Dec 23, 2015 at 4:44 AM, Dan Wilcox  wrote:
>> 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. Say tag cyclone right now as version 1.0.0
>> and all further development is version 2.0.*
> 
> Versioning is important but it can't solve all issues that arise when
> diverging. While it is easy for a user to update to a specified
> version of a library with deken, Pd patches already out there 'in the
> wild' (to quote Jonathan) don't specify which version they need.
> 
> Katja

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Dan Wilcox]

> On Dec 23, 2015, at 9:08 AM, Dan Wilcox  wrote:
> 
> I’d make an abstraction wrapper around [count~] that filtered out the set 
> message

Hah. never mind. I forgot PD chooses compiled objects over abstractions so you 
can’t do what I suggested anyway. Teach me to type before following my own 
advice and “test it”.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

>
> Hah. never mind. I forgot PD chooses compiled objects over abstractions so
> you can’t do what I suggested anyway. Teach me to type before following my
> own advice and “test it”.
>

you can still give warnings, if that's the case; but this seems like a
digression. Not sure if I get what katja raised btw, that we should be
careful before adding stuff like the set message in [count~]? Sure, agreed.
cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[katja]

On Tue, Dec 22, 2015 at 11:51 PM, Alexandre Torres Porres
 wrote:
> Well, newer patches with newer functionalities not working in older versions
> is how things go anyway, right? Vanilla 0-46 patches don't run in 0.45 and
> so on... there's no way around that I guess.

Right, in this context it is worth noting that any improvement in a
library has the potential of causing problems for people who use an
old version, yet it doesn't prevent us from fixing bugs.

Recall cyclone/count~ which used to make Pd crash when receiving the
'set' message. Everyone learned to not send it that message. Now that
the bug is fixed people may start using the set message, causing
spurious crashes for those who use the patch with an old cyclone
version. Oddly, the crasher bug fix may lead to a temporary increase
of crash incidents. The remedy is simple for everyone; upgrade to the
latest cyclone.

Extrapolating this to other improvements (an extra feature in a class
or a new class in a library): as long as you improve and add, it's
safe for everyone to simply use 'latest'. In contrast, if you take
away, things become amazingly complicated. Oddly again, this may be a
reason to not introduce an improvement or addition too quickly. You
want to be pretty sure you don't need to take it away later.

Katja

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jonathan Wilkes via Pd-list]

I find Fred Jan's maintenance reasonable because sticking with current behavior 
means 0% of patches in 
the wild will be negatively affected.  There's the possibility that his 
maintenance hinders Max compatibility for future 
patches, but this isn't something we can quantify.
We can _estimate_ the impact of changing Cyclone behavior by taking a large 
sample of patches and mining them to see what percentage would be impacting by 
such a change.  (We can also look specifically at how 
the behavior changes, how easy it is to undo, etc.)  But obviously a change 
affects 1/1 patches is different than 
a change that affects 5000/1 patches.
But doing that would take a lot of time and energy.  I'm not willing to do it, 
and I'm not about to tell Fred Jan to 
do that after he's taken on the task of maintaining an abandoned library.  I'm 
also not willing to do it because I 
don't think it will result in any significant improvement for porting patches 
between Pd and Max.  But again, that's 
just a hunch about future development.
If you have the opposite hunch then do some data mining so that we can have a 
more meaningful discussion.  
Otherwise we're just draining Fred Jan's maintenance energies-- overestimating 
the potential damage of him 
leaving some code untouched, and understimating all the other improvements he's 
doing.
-Jonathan
 

On Tuesday, December 22, 2015 12:56 PM, Alexandre Torres Porres 
 wrote:
 

 
2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list :

Hi anyone encouraging backward breakage,
Please make a collection of as many patches as possible, from as many public 
sources as possible.
Then mine this data to get a sense of what percentage of patches would be 
affected 
by changing a Cyclone class' behavior.

Then let's continue with conversation.
If no one is willing to do this, it's a tacit acknowledgement that Fred Jan is 
taking 
the only sensible approach to maintaining Cyclone.

I don't think I get this, or agree. Are you saying that people who wish to 
break backwards compatibility should check if there's any patch out there which 
could be affected, and then if no patch is affected we could change it? That 
might be logical but not very reasonable. 
But anyway, I don't think we should narrow the discussion to this! 
I guess I might be "one" encouraging backward breakage, although I made 
suggestions to not break it and said that the issue in discussion (the average~ 
object) did not really pose this dilema - let me stress and emphasize that I 
don't believe this is a "A" or "B" choice, and I hope we do not really have to 
discuss this like that.
Katja made other suggestions on how to "meet in the middle", it is perfectly 
possible to change the behaviour with an argument or a message, I agree. No one 
here is just up for backwards compatibility breakage so let's not, please, make 
this such a discussion...
What really concerns me is anyone encouraging the breakage of the purpose of 
cyclone (compatibility to MaxMSP). I don't think this is sensible at all, it is 
a major change of course in the project.
Again, we're not really facing a dilema between backwards compatibility versus 
Max/MSP compatibility, but considering Max/MSP compatibility not a priority 
(even acknowledging there's a mistake that shouldn't be there in the first 
place) kills the main purpose of cyclone and that'ss serious. I'd say it even 
points to a fork in the project. If such a detour in purpose emerges from the 
maintenance, maybe we shouldn't call it "cyclone" anymore.
On te other hand, if one is encouraging Max/Msp compatibility breakage, maybe 
this person could check first if any user will be affected by that change. 
There's me right here, by the way :)
cheers

  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[katja]

On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres
 wrote:

> If we're discussing [average~], how about my idea of having a second right
> signal outlet as default? I think it's an easy and simple solution. Help
> file would explain how the left control outlet is for backwards
> compatibility. Done.

Yes that would be an easy way to incorporate Fred Jan's signal average
output into the existing class. But note that both solutions, dual
mode and dual outlet, have a similar forward incompatibility effect. A
patch that uses the right signal outlet of a new version won't run
with an old average~ binary. So the pros and cons of both solutions
are comparable, with the small difference that the dual outlet layout
with message left and signal right is rather unusual.

Katja

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

2015-12-22 17:58 GMT-02:00 Jonathan Wilkes :

> I find Fred Jan's maintenance reasonable because sticking with current
> behavior means 0% of patches in
> the wild will be negatively affected.  There's the possibility that his
> maintenance hinders Max compatibility for future
> patches, but this isn't something we can quantify.
>

There's a pretty straightforward and concrete example in discussion, so
it's quantifiable and not a matter of possibility. It's not a hunch about
future development, there's already a present issue regarding the
improvement for porting patches between Pd and Max. More than that,
opinions from maintenance have been stated that Max/Msp compatibility is
not supposed to be a concern anymore...

If you have the opposite hunch then do some data mining so that we can have
> a more meaningful discussion.
>

You're basically just trying to share your opinion (over mine, by the way)
that this should be the way to go... I think this is a meaningless
discussion as it is. I have a perfectly good reason to appreciate and hope
for the compatibility to Max/MSP in cyclone (being that its original
purpose) - but in order to make a case against your opinion, you've
provided an insane and unreasonable task...

And this is after me and others have suggested that this not about a
dilema, that we could meet halfway, more than once... this is in fact the
point of this thread, so this seems also like a pointless discussion to be
raised in here.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Miller Puckette]

If I may make a suggestion - when I find that an object isn't terribly
well designed (for example my own qlist :) I make another one, with another
name, that does the job better (text).

cheers
Miller

On Tue, Dec 22, 2015 at 08:51:03PM -0200, Alexandre Torres Porres wrote:
> Well, newer patches with newer functionalities not working in older
> versions is how things go anyway, right? Vanilla 0-46 patches don't run in
> 0.45 and so on... there's no way around that I guess.
> 
> > the dual outlet layout with message left and
> > signal right is rather unusual.
> 
> But I think it's also simpler and more straightforward than introducing
> flags, arguments and all. It might be unusual, but there are already some
> objects with similar design, I actually thought of that because of
> [sampstoms~] and [mstosamps~] - it'd be basically the same design.
> 
> cheers
> 
> 2015-12-22 19:48 GMT-02:00 katja :
> 
> > On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres
> >  wrote:
> >
> > > If we're discussing [average~], how about my idea of having a second
> > right
> > > signal outlet as default? I think it's an easy and simple solution. Help
> > > file would explain how the left control outlet is for backwards
> > > compatibility. Done.
> >
> > Yes that would be an easy way to incorporate Fred Jan's signal average
> > output into the existing class. But note that both solutions, dual
> > mode and dual outlet, have a similar forward incompatibility effect. A
> > patch that uses the right signal outlet of a new version won't run
> > with an old average~ binary. So the pros and cons of both solutions
> > are comparable, with the small difference that the dual outlet layout
> > with message left and signal right is rather unusual.
> >
> > Katja
> >

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list :

> Hi anyone encouraging backward breakage,
> Please make a collection of as many patches as possible, from as many
> public
> sources as possible.
>
> Then mine this data to get a sense of what percentage of patches would be
> affected
> by changing a Cyclone class' behavior.
>
> Then let's continue with conversation.
>
> If no one is willing to do this, it's a tacit acknowledgement that Fred
> Jan is taking
> the only sensible approach to maintaining Cyclone.
>

I don't think I get this, or agree. Are you saying that people who wish to
break backwards compatibility should check if there's any patch out there
which could be affected, and then if no patch is affected we could change
it? That might be logical but not very reasonable.

But anyway, I don't think we should narrow the discussion to this!

I guess I might be "one" encouraging backward breakage, although I made
suggestions to not break it and said that the issue in discussion (the
average~ object) did not really pose this dilema - let me stress and
emphasize that I don't believe this is a "A" or "B" choice, and I hope we
do not really have to discuss this like that.

Katja made other suggestions on how to "meet in the middle", it is
perfectly possible to change the behaviour with an argument or a message, I
agree. No one here is just up for backwards compatibility breakage so let's
not, please, make this such a discussion...

What really concerns me is anyone encouraging the breakage of the purpose
of cyclone (compatibility to MaxMSP). I don't think this is sensible at
all, it is a major change of course in the project.

Again, we're not really facing a dilema between backwards compatibility
versus Max/MSP compatibility, but considering Max/MSP compatibility not a
priority (even acknowledging there's a mistake that shouldn't be there in
the first place) kills the main purpose of cyclone and that'ss serious. I'd
say it even points to a fork in the project. If such a detour in purpose
emerges from the maintenance, maybe we shouldn't call it "cyclone" anymore.

On te other hand, if one is encouraging Max/Msp compatibility breakage,
maybe this person could check first if any user will be affected by that
change. There's me right here, by the way :)

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

Well, newer patches with newer functionalities not working in older
versions is how things go anyway, right? Vanilla 0-46 patches don't run in
0.45 and so on... there's no way around that I guess.

> the dual outlet layout with message left and
> signal right is rather unusual.

But I think it's also simpler and more straightforward than introducing
flags, arguments and all. It might be unusual, but there are already some
objects with similar design, I actually thought of that because of
[sampstoms~] and [mstosamps~] - it'd be basically the same design.

cheers

2015-12-22 19:48 GMT-02:00 katja :

> On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres
>  wrote:
>
> > If we're discussing [average~], how about my idea of having a second
> right
> > signal outlet as default? I think it's an easy and simple solution. Help
> > file would explain how the left control outlet is for backwards
> > compatibility. Done.
>
> Yes that would be an easy way to incorporate Fred Jan's signal average
> output into the existing class. But note that both solutions, dual
> mode and dual outlet, have a similar forward incompatibility effect. A
> patch that uses the right signal outlet of a new version won't run
> with an old average~ binary. So the pros and cons of both solutions
> are comparable, with the small difference that the dual outlet layout
> with message left and signal right is rather unusual.
>
> Katja
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Dan Wilcox]

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. Say tag cyclone right now as version 1.0.0 and all further 
development is version 2.0.*

This seems to work fine for all sorts of software libraries and deken should 
make it much more possible in pd.


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Dec 22, 2015, at 7:06 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Miller Puckette <m...@ucsd.edu <mailto:m...@ucsd.edu>>
> Subject: Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone 
> (was: Purpose of Cyclone)
> Date: December 22, 2015 at 4:46:29 PM MST
> To: Alexandre Torres Porres <por...@gmail.com <mailto:por...@gmail.com>>
> Cc: "pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" 
> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>
> 
> 
> If I may make a suggestion - when I find that an object isn't terribly
> well designed (for example my own qlist :) I make another one, with another
> name, that does the job better (text).
> 
> cheers
> Miller
> 
> On Tue, Dec 22, 2015 at 08:51:03PM -0200, Alexandre Torres Porres wrote:
>> Well, newer patches with newer functionalities not working in older
>> versions is how things go anyway, right? Vanilla 0-46 patches don't run in
>> 0.45 and so on... there's no way around that I guess.
>> 
>>> the dual outlet layout with message left and
>>> signal right is rather unusual.
>> 
>> But I think it's also simpler and more straightforward than introducing
>> flags, arguments and all. It might be unusual, but there are already some
>> objects with similar design, I actually thought of that because of
>> [sampstoms~] and [mstosamps~] - it'd be basically the same design.
>> 
>> cheers

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone

[Alexandre Torres Porres]

seems the thread has forked, hadn't seen this.

2015-12-22 18:52 GMT-02:00 Fred Jan Kraan :

> Sorry for all the confusion I have apparently created.
>

I feel quite responsible, so apologies as well


> It seems that more words just means more misunderstanding. So here I
> attempt another approach:
>

sounds like a nice approach.


> - trust me, I do not want to kill cyclone
>

I trust you


> - cyclone backward compatibility is more important than Max/MSP
> compatibility,
> - it will take some time to find out the best way to have both.
>

 As long as we can think of a way to have both, I don't really have a
problem. So everything sounds cool and my reply should end here.

But it didn't :) sorry, hope adding more words won't degrade the thread.

I don't agree backwards compatibility is more important than Max/MSP
compatibility in cyclone, and feel that the mere such idea hurts the main
purpose of the project. Now, that's just my opinion. I wonder if what you
shared is just an opinion as well, it wasn't clear. If it's just an
opinion, do you value different ones? I respect different opinions, but I'd
have a problem with it if it'd be imposed as truth over other ones. Anyway,
I believe you're just sharing an opinion, and that you're cool with other
opinions, but I'm just being "that guy", who wants things to be cristal
clear as also an approach to avoid misunderstandings.

Now we can start thinking about best way to have both ;)

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Dan Wilcox]

Actually one of the problems with extended was that it loaded *everything* by 
default, so people aren’t used to specifying required libs. Imagine if 
[declare] or [import] could also specify lib versions ...


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Dec 22, 2015, at 10:05 PM, Alexandre Torres Porres  
> wrote:
> 
>  Now people who used extended will have to install libraries on their own 
> with deken and need to know what's going on. 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

2015-12-23 1:44 GMT-02:00 Dan Wilcox :

> What about versioning? If people *have* to have older compatibility, then
> why can’t they just run an older version of cyclone?
>

We're not really even at a real discussion where people would *have* and
*need* to stay with an older version of cyclone by the way. I'll get to
that...


Newer development can take place on the current version and you can clearly
> note api changes/updates in a CHANGELOG. Say tag cyclone right now as
> version 1.0.0 and all further development is version 2.0.*
>
> This seems to work fine for all sorts of software libraries and deken
> should make it much more possible in pd.
>

Dan, if I fully get you, I agree and had thought about it. I'm just also
open to those who think differently and care a lot about the compatibility
deal, so I'm also suggesting simple solutions for "everyone to be happy".
But if it was up to me...

Some of the discussion here is based on the worries of breaking patches as
if Pd as if Pd users don't have to be savvy on managing versions and
external libraries, as if they'd be tied up whenever a change was made.
It's almost like as if one would have to search all the patches in the
world, and if one that would be affected was found, the case should be
rested, and nothing could be done...

But let's be reasonable, worls is crazy, life is crazy and also a bitch,
crazy stuff happens all of the time in the Pd world (and in the software
world) and we have to manage that. Now people who used extended will have
to install libraries on their own with deken and need to know what's going
on.

I'm thinking about whenever I create [wrap] in Pd-Extended 0.42-5, it shows
the error: *A new incompatible [wrap] object was introduced in Pd 0.42.*
*... you might be able to track this down from the Find menu.*
* For a backwards-compatible version, use [zexy/wrap]*

That's it, a simple warning, and deal with it... change your patches if you
have to. Change your version, read the changelog, read the help file. Just
point the issue and solutions if they actually show up.

The crazy thing is that, objectively, we're not really even at a real issue
where people would *have* and *need* to stay with an older version of
cyclone. The only thing that came up (a change in behaviour in [average~])
is easily fixable and manageable... it's not like the patch would break
beyond reparability, and even if no message is added to the Pd window
(regarding the new functionality of the object nor anything in the help
file), error messages in the console would still point to the problem
(signal outlet connected to control inlet)... there you go, find te error
and just use a snapshot~ to convert to data then.

But, hey, well, cutting to the chase, I back you up on this one...

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Ivica Bukvic]

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  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
>  wrote:
> >
> > 2015-12-15 16:22 GMT-02:00 Fred Jan Kraan :
> >>
> >> 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 

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

[Alexandre Torres Porres]

2015-12-22 21:46 GMT-02:00 Miller Puckette :

> when I find that an object isn't terribly well designed (...) I make
> another one, with another name, that does the job better.
>

Sounds great, too bad the darn thing about cyclone is that we need to stick
to deal with cloning the original objects with their names and
stuff. Although I'm being a major advocate of cyclone and its maintenance,
I actually dislike this fact/restriction. For me it's more the fact that it
is a nice, big and handy collection of objects that adds several
functionalities to Pd. The need to be faithful to max is kind of a bummer,
but that's what cloning is...

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list