[PD] Purpose of Cyclone (was: Cyclone features or Cyclone updates)

Alexandre Torres Porres porres at gmail.com
Sun Dec 13 22:49:34 CET 2015


> 2015-12-13 8:06 GMT-02:00 Fred Jan Kraan <fjkraan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151213/18ffe468/attachment.html>


More information about the Pd-list mailing list