Hi List,
Finally a set of changes made it to a workable state:
and retain backward cyclone compatibility in average~.
accurate resize.
The intention is to test this on multiple platforms and create deken compliant binary distributions as version 0.2 beta1. The current state of the code can be found at: https://github.com/electrickery/pd-cyclone. Note the coll and average2~ code are currently in topic specific branches.
Fred Jan
Great & Awesome, Thanks!
But please allow me to make a suggestion and start a discussion.
If backwards compability is really considered that important, perhaps we could just create a second signal outlet, it'd keep the current functionality and add the original signal design.
I suggest that because I consider a priority the focus on a faithful object relationship between max and pd. I consider this to be the one great purpose of it. so I think it's weird to have an object with a different name, that doesn't exist in max, to behave as such, whilst the object that was supposed to have that same functionality doesn't.
If keeping two objects, why not give the old one a new name? But one way or another, two objects sounds bad to me. I'd go further as to discuss if this functionality is necessary, we can achieve it with other objects in Pd, such as another object from cyclone, which is [cyclone/avg~], and also env~ and [zexy/avg~] or [zexy/tavg~]...
Moreover, instead of just using other objects, you could just use [cyclone/snapshot~] to convert the audio output to control if needed. It's a simple fix. I don't believe there are that many patches out there that depend on this, and if they exist, again, it's a simple fix, and it seems healthier to fix them than to maintain it just because we had it wrong to begin with...
I'm fine in having some flexibility and not having the exact same functionality as in max, we could have other functionalities/features, so having two outlets could be meeting halfway - I just tend to criticize this need to maintain features and behaviours that emerged from mistakes and then adding other stuff around it and making it more complicating than just fixing it.
Anyway, those are my thoughts on it, anybody else?
cheers
2015-12-06 19:27 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi List,
Finally a set of changes made it to a workable state:
- average~: Created an average2~ to support a signal outlet for Max compatibility
and retain backward cyclone compatibility in average~.
- frameaccum~: Added a wrap option.
- coll: Added threaded load/save option from L2ork by Ivica Ico Bukvic.
- Scope~: Improved resize behaviour. Added a resize message to support pixel
accurate resize.
- all signal objects: Prevent crash Pd with [dsp( message.
The intention is to test this on multiple platforms and create deken compliant binary distributions as version 0.2 beta1. The current state of the code can be found at: https://github.com/electrickery/pd-cyclone. Note the coll and average2~ code are currently in topic specific branches.
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/07/2015 09:14 PM, Alexandre Torres Porres wrote:
Anyway, those are my thoughts on it, anybody else?
i was going to write something similar, thanks alex for doing it instead.
for me (as a non-user of cyclone), the main purpose of this library is to provide a max->pd compat layer. if this is still the case¹, then the compatibility with the max-objects should be the primary target and not the consistency of the library per se².
gmrds IOhannes
¹ and it might well not be - it's the authors decision; but it ought to be clearly communicated
² if someone relies on the old ("wrong") behaviour, they can always use an older version of cyclone.
On Mon, Dec 7, 2015 at 9:14 PM, Alexandre Torres Porres porres@gmail.com wrote:
Great & Awesome, Thanks!
But please allow me to make a suggestion and start a discussion.
[snip]
I'm fine in having some flexibility and not having the exact same functionality as in max, we could have other functionalities/features, so having two outlets could be meeting halfway - I just tend to criticize this need to maintain features and behaviours that emerged from mistakes and then adding other stuff around it and making it more complicating than just fixing it.
Anyway, those are my thoughts on it, anybody else?
In my view backward compatibility should be taken very serious in the case of any Pd class. I find it really annoying when classes change their behavior for anything other than a very compelling reason. Here's why: among the people who use Pd patches that we distribute, not everyone is so much aware of details discussed on Pd list, and then they don't know why a patch breaks.
You wouldn't believe how long a broken patch stays around. I've found the broken version of my patch SliceJockey on many people's computers, even months or years after I had uploaded a fixed version.
Hence my opinion: don't break backward compatibility unless you really must, like when a class produces incorrect mathematical results.
Katja
Hi All,
Thanks for all the comments.
The original goal of cyclone was to create a collection of Max/MSP objects for PureData. This was in the 2000s area, Max/MSP version 4.6. Since then MAX evolved its architecture and file format to something that is incompatible with PureData. Compatibility is limited to a very old version of Max/MSP.
The cyclone objects exist for twelve years, and any patches created then can still be loaded into a modern Pd. There may not be very much patches, but they are more likely than Max/MSP 4.6 patches nowadays. For me this makes backward compatibility more important than with an obsolete Max/MSP version.
The cross section of both goals means no functional objects can be changed in a way that makes them backward-incompatible. New objects can be added and bugs can be fixed. Backward-incompatible objects should go into another library. It is for more or less this purpose I started the pd-playground¹. So there the average2~ object will go.
Greetings,
Fred Jan
The original goal of cyclone was to create a collection of Max/MSP objects for PureData.
yep
Compatibility is limited to a very old version of Max/MSP.
Well, I started using and teaching Max this year, and this is the reason why I've been carefully and thoroughly studying its objects and comparing to Pd's cyclone, and thus reported many bugs and issues, including this one about the [average~] object.
And I say it because I don't understand what you mean. I've been using Max 7 and Pd at the same time, making totally compatible patches between both platforms. if you're just saying that you can't open the same files on both platforms, ok, alright. But that means only that the main idea is to have a library of objects with the same functionality as Max objects.
For me this makes backward compatibility more important than with an obsolete Max/MSP version.
I don't think anyone here is making a case that we should maintain compability with an obsolete MAX. And well, like I said, I'm using Max 7...
And as I see it, the average~ object was wrong to begin with, it couldn't load max patches in the first place, it should have been signal all along.
Sorry, but this is not making much sense to me, I'm not quite sure what you mean. I don't think is reasonable to define cyclone as a way to load patches from max 4 and then say that since you can't do that anymore, well, forget about it and lets just completely disregard the idea that the objects should be related between both systems as a priority.
Again, I'm perfectly happy using Max 7 and being able to design patches that are quite similar to both platforms. I'm really happy that I can implement lots of patches that are possible with a fairly nice set of objects presented in Max that are lacking in Pd Vanilla. That's what cyclone is and always was to me.
Perhaps we should discuss more about the concept behind cyclone here on the list with its users, like me. I'm not sure what your view is by the way.
I just think that if we are to maintain and update cyclone, we should try and make and update objects to make them compatible and with the same functionalities and number of pertinent object as the current max version. That's my idea on it.
Now, regarding the average~ object, I was expecting different views like this, where backwards compatibility could be an issue, even though it breaks the compatibility as I'm pointing. But whatever, we had 4 takes on it, 2 up for a backwards compatibility and 2 saying we should "fix" the thing.
We can keep discussing it forever, but I also suggesting a compromise here. What about an object that has a second signal outlet? You'd keep the first left outlet and not break any compatibility that may lay around. And also, any newcomer that's studying both Max and Pd like me can also enjoy the fact that the systems are compatible. That'd be meeting halfway and making everybody happy, huh? What do you say?
cheers
2015-12-08 17:20 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi All,
Thanks for all the comments.
The original goal of cyclone was to create a collection of Max/MSP objects for PureData. This was in the 2000s area, Max/MSP version 4.6. Since then MAX evolved its architecture and file format to something that is incompatible with PureData. Compatibility is limited to a very old version of Max/MSP.
The cyclone objects exist for twelve years, and any patches created then can still be loaded into a modern Pd. There may not be very much patches, but they are more likely than Max/MSP 4.6 patches nowadays. For me this makes backward compatibility more important than with an obsolete Max/MSP version.
The cross section of both goals means no functional objects can be changed in a way that makes them backward-incompatible. New objects can be added and bugs can be fixed. Backward-incompatible objects should go into another library. It is for more or less this purpose I started the pd-playground¹. So there the average2~ object will go.
Greetings,
Fred Jan
¹https://github.com/electrickery/pd-playground
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There may not be very much patches, but they are more likely than Max/MSP 4.6 patches nowadays.
still trying to get this, I ask, well, don't old max patches still open in newer versions of Max? cheers
2015-12-08 17:20 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi All,
Thanks for all the comments.
The original goal of cyclone was to create a collection of Max/MSP objects for PureData. This was in the 2000s area, Max/MSP version 4.6. Since then MAX evolved its architecture and file format to something that is incompatible with PureData. Compatibility is limited to a very old version of Max/MSP.
The cyclone objects exist for twelve years, and any patches created then can still be loaded into a modern Pd. There may not be very much patches, but they are more likely than Max/MSP 4.6 patches nowadays. For me this makes backward compatibility more important than with an obsolete Max/MSP version.
The cross section of both goals means no functional objects can be changed in a way that makes them backward-incompatible. New objects can be added and bugs can be fixed. Backward-incompatible objects should go into another library. It is for more or less this purpose I started the pd-playground¹. So there the average2~ object will go.
Greetings,
Fred Jan
¹https://github.com/electrickery/pd-playground
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list