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/cyclo....
On Mon, Dec 21, 2015 at 6:26 PM, Alexandre Torres Porres porres@gmail.com wrote:
2015-12-15 16:22 GMT-02:00 Fred Jan Kraan fjkraan@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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/cyclo... .
On Mon, Dec 21, 2015 at 6:26 PM, Alexandre Torres Porres porres@gmail.com wrote:
2015-12-15 16:22 GMT-02:00 Fred Jan Kraan fjkraan@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@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
Hi Fred Jan,Please keep doing what you're doing. 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.
-Jonathan
2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at
:
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
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/10000 patches is different than a change that affects 5000/10000 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 <porres@gmail.com> wrote:
2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list pd-list@lists.iem.at:
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
2015-12-22 17:58 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
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
Hi All,
Sorry for all the confusion I have apparently created.
It seems that more words just means more misunderstanding.
So here I attempt another approach:
- trust me, I do not want to kill cyclone,
- cyclone backward compatibility is more important than Max/MSP
compatibility,
- it will take some time to find out the best way to have both.
Greetings,
Fred Jan
Hi Fred Jan,Sounds good to me. Keep up the good work. Best,Jonathan
On Tuesday, December 22, 2015 3:53 PM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote:
Hi All,
Sorry for all the confusion I have apparently created.
It seems that more words just means more misunderstanding.
So here I attempt another approach:
- trust me, I do not want to kill cyclone,
- cyclone backward compatibility is more important than Max/MSP
compatibility,
- it will take some time to find out the best way to have both.
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2015-12-22 12:51 GMT-02:00 katja katjavetter@gmail.com:
With the recent increased effort of testing, fixing and innovation there's an opportunity to redefine intentions and ambitions.
Totally agree, I guess we can just keep the idea that it is a library of clones in a generic approach that doesn't restrict to "4.5", I guess the mentioning of that version is because it was the current version at the time, not because it had to remain restrained to it...
So I think the subtitle description should just be
*a library of clones of Max/MSP objects*
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.
Sure. Well, that makes it more generic and open to updates.
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.
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.
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.
I'm seeing if I can find collaborators out there.
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
You can see at the description that it had many ambitions indeed. We could edit the project like saying it was "meant to eventually become part of a much larger project, aiming at unification and standardization of computer musician's tools."
I guess we can edit that and rule it out, hehe...
Project description could tell more about current development, that it started back in the days of max/msp 4.5 and that it is now open to newer developments to keep up with latest versions of Max and such details.
I also owe this list a document from my research with a "To Do List", it's not like it'd be a huge thing, and we could also describe more about the scope of and focus of the project, which is not suppose to turn Pd into clone of Max, stuff like that.
Help files could tell up to which version an object is and give details of what it has or not as a clone in comparison to the original.
I could work on that on the help files.
cheers
On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres porres@gmail.com 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
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 katjavetter@gmail.com:
On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres porres@gmail.com 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
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 katjavetter@gmail.com:
On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres porres@gmail.com 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
2015-12-22 21:46 GMT-02:00 Miller Puckette msp@ucsd.edu:
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
On Tue, Dec 22, 2015 at 11:51 PM, Alexandre Torres Porres porres@gmail.com 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
On Dec 23, 2015, at 4:01 AM, katja <katjavetter@gmail.com mailto:katjavetter@gmail.com> wrote:
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.
That’s an interesting point.
In that case, I’d make an abstraction wrapper around [count~] that filtered out the set message and printed something about it (aka “upgrade perhaps? :)". Add that to the repo for the older version, although there is no guarantee what version people would have.
Thankfully, deken should help make a transition like this easier.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 23, 2015, at 9:08 AM, Dan Wilcox danomatika@gmail.com 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 https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
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
- MaxMSP compatibility available through an extra operational mode
- MaxMSP compatibility available through an extra class
All together, not really a mind-blowing result for a thread with so many words, but at least it gives an overview of choices that people would make. There's also Ico's suggestion to use an approach similar to Pd-L2Ork's -legacy flag.
On Wed, Dec 23, 2015 at 5:46 PM, Alexandre Torres Porres porres@gmail.com wrote:
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
On Dec 23, 2015, at 1:36 PM, katja katjavetter@gmail.com wrote:
All together, not really a mind-blowing result for a thread with so many words, but at least it gives an overview of choices that people would make.
I agree, too many words and possibly assumptions, but then again that’s sometimes hard when dealing with plain text.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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 katjavetter@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
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
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@gmail.com mailto:katjavetter@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
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@gmail.com mailto:katjavetter@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 flagThe -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
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 <fjkraan@xs4all.nl> 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@gmail.com mailto:katjavetter@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 fjkraan@xs4all.nl:
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@gmail.com mailto:katjavetter@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 flagThe -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
-
Alexandre Torres Porres -
Dan Wilcox -
Fred Jan Kraan -
Ivica Bukvic -
Jonathan Wilkes -
katja -
Miller Puckette