2015-12-13 8:06 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
I just managed to install the Max/MSP 4.6 help patches and counted 470 objects there. Count 100 for vanilla Pd and 150 for cyclone, there are 220 to go...
Didn't really know cyclone went back to Max 4 era, I had Max 5 all along to check the "original" features. So I have also Max 6 and Max 7, which makes me think that checking Max 4 might be too much. But I may try getting that.
Thing is that I've been comparing to Max 7, and I think it makes more sense to do that. Not that the goal is to get to a clone of Max 7 (or 8/9 for that matter), it's just a matter of the purpose of the whole thing. I was asking this on another thread and maybe we should rush to it once and for all. Do you feel like Cyclone should be a clone of Max 4.6, and stop there?
Well, Max 7 respects backwards compatibility to earlier patches, right? So I'm checking it and I assume Max's latest version must have cool new features added to some objects that we could also enjoy, respecting backwards compatibility of course.
I can map what's been added to Max and not to Pd yet. Actually, I've already started doing this. I'll just organize it and share it.
I could also say that I've went through all of Max's audio objects trying to find the most relevant ones that would be missing and didn't find so much of them. We already have a great package.
I think it's better to elect the best missing features/objects as candidates for clones, with good sense.
Quite a few objects will just not be possible under the Pd paradigm, so we may just forget about that, instead of bothering in making Pd a clone of Max. I don't think that is a main purpose.
As I said before, the main purpose of cyclone, in my opinion, should consist in being a nice collection of externals that have the same functionality as objects in Max that are missing in Pd Vanilla. This is a good point because: 1- Vanilla is a small package. 2- Max has some stuff there we could copy and clone.
The idea would not be to clone Mas then. Going through Max's objects and cloning them seems like a good starting point for a nice package of externals, that's all.
As a consequence, we gain the ability of having patches, or patching sections that are virtually the same on both systems. This is good for people who, for any reason, use both systems. Or for people who are migrating from one system to another. But I don't believe that should be the main concern, only a nice consequence. I actually like this a lot, as it allows me to teach both systems at once! Keeping in mind basic structural differences.
But anyway, I'm confused as to what is your idea behind it, or the general idea in the community of cyclone users. Let us talk about it then.
This also touches the issue with [average~], as there was a resistance to make it a proper clone of the Max object as a priority. You were making remarks such as:
Compatibility is limited to a very old version of Max/MSP.
That really confused me, as a Max 7 user...
For me this makes backward compatibility more important than with an obsolete Max/MSP version.
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.
Seemed like defining cyclone as a way to load patches from max 4 - but then agreeing you can't do that anymore and just disregarding the idea that the objects should be proper clones as a priority.
*In short, my take on cyclone's purpose: to be a set of objects cloned from max (up to the latest version), with the same features and functionalities where possible.*
cheers
Hi Alexandre,
But anyway, I'm confused as to what is your idea behind it, or the general idea in the community of cyclone users. Let us talk about it then.
This also touches the issue with [average~], as there was a resistance to make it a proper clone of the Max object as a priority. You were making remarks such as:
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...).
Forme this makes backward compatibility more important than with an obsolete Max/MSP version.
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.
Seemed like defining cyclone as a way to load patches from max 4 - but then agreeing you can't do that anymore and just disregarding the idea that the objects should be proper clones as a priority.
Indeed, for me backward compatibility more important than Max/MSP compatibility.
*_In short, my take on cyclone's purpose: to be a set of objects cloned from max (up to the latest version), with the same features and functionalities where possible._*
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...
But enough typing opinions for now, I prefer to do some improvement on cyclone objects tonight :-).
cheers
Greetings,
Fred Jan
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:
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.
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