any talk of open/free dev. of Max/MSP runtime?
Jan 18, 2010 at 7:12pm
any talk of open/free dev. of Max/MSP runtime?
I’ve been searching high and low for info on this subject, so please forgive me (and redirect me) if this topic has been discussed elsewhere.
I understand why Cycling is walking away from development of the Max/MSP runtime to focus on M4L (as Live itself is now the runtime for all practical purposes), but I’m curious if any outside groups have discussed taking up the challenge of continuing to develop the current runtime (or a fresh runtime) independently (ala an open/free project presumably). I understand that, to the best of my knowledge, Cycling has not publicly discussed any plans to release the source code for the current runtime. . .
Are developers who are using Max/MSP to create commercial or community-supporting plugins/apps just planning to update their plugs for M4L, and face a future where only M4L owners (and maybe, at some point, all Live owners) can use their products?. . . (lest they face the harsher reality of having to recreate their products in C++/Juce and handle continued OS/DAW update fixes and compato themselves).
If I’m mistaken about any aspect of Cycling’s future plans or what the usefulness of a continually-updated non-Ableton, non-M4L runtime would be, please correct me.
Thanks to anybody that can point me in the right direction.
Jan 18, 2010 at 8:39pm
Surely not. If this is true it’s very discouraging for me. Where was this announced? Reference please?
(or are you just misinterpreting the Pluggo situation?)
Jan 18, 2010 at 9:15pm
I would find this hard to believe – my guess is that the Runtime is simply some compile-time switches in the main Max application’s source – supporting it is probably next to zero work at this point in the lifecycle of Max.
Jan 18, 2010 at 9:32pm
I don’t understand what you are talking about. Max Runtime works
Now developing your own plugin, that is a different story. If you
Jan 19, 2010 at 8:09am
Sorry for my confusion. I mistakenly thought that both the pluggo runtime AND the Max/MSP runtime were not going to receive any further developmen. My references to “the runtime” in my initial question was based on the mistaken notion that Max/MSP runtime installer also contained/installed the Pluggo runtime. I understand now that it’s just the Pluggo runtime that’s being put out the pasture, and the Max/MSP runtime and the ability to make stand alone apps for non-Max/MSP owners will live on. Thank you Raja for taking the time for such a detailed clarification.
My initial question still stands in relation to talk of an open project for keeping the AU/VST/RTAS “exportability” that the Pluggo runtime afforded alive into the future. However, if the Max/MSP runtime is still being supported/developed, then an outside dev. effort just to sustain what the pluggo runtime alone offered seems less compelling.
. . . and from the responses thus-far, I think the answer to my “is there any talk of kickstarting a 3rd party/open pluggo runtime effort” (ala the open Nord Modular editor project, etc) is a resounding “no”.
In relation to the M4L specifics Raja brought up above, I feel like I had a pretty firm grasp of what’s going on with M4L before I posted. . . but just to make sure I do have those facts straight, the story I got from digging in the Ableton forums (before I made my initial post) was that an M4L runtime enabling non-M4L owners to use M4L plugs (in Live only of course) is not part of the Cycling/Ableton business plan right now, but at least non-M4L-owning Live users will be able to poke around in M4L creations “soon, but not yet” by installing the Max/MSP demo an running Live in demo mode.
Really appreciate the time everyone put in to helping me sort things out. I’m glad to find out that at least the Max/MSP runtime will live on.
Jan 19, 2010 at 9:20am
On further consideration, here’s my abridged version:
The less-flawed version of my initial would have been “is there any talk of an open/third-party project for keeping the AU/VST/RTAS ‘exportability’ that the Pluggo runtime afforded alive into the future?”. . . To which the answer is:
“Hell no, having an outside/third-party team attempt to develop (in an open capacity or otherwise) a runtime based off of a continually updated application that is NOT an open effort, is a deeply flawed proposal for many very basic and compelling reasons. You’d have an easier and more productive time building your own cross-platform graphical AU/VST/RTAS development environment than you would trying to keep the Pluggo runtime up to date from the outside, regardless of how much time Cycling wasted sharing code and info with your misguided team”.
Do I finally have it all straight now? ;)
Jan 19, 2010 at 5:55pm
Well, I didn’t mean to imply that a pluggo runtime itself would be a waste of time, but that from Cycling’s perspective, the amount of effort they’d have to put in to helping/supporting this outside pluggo development effort could potentially be more work than if they just resumed pluggo dev themselves. . . with no guarantee that this outside/open project would ever bear any fruit.
I don’t think development of a pluggo runtime for Max 5 could be an effort independent of changes/updates to Max5. . . so not only would you have to update the runtime to keep pace with changes in OSX, Windows 7, VST/AU/RTAS changes, and continual updates to all major DAWs that happen to foul up pluggo runtime functionality. . .but you’d have to keep pace with updates to Max/MSP as well. Given that there isn’t even a current pluggo runtime for Max5 (something I was unaware of when I first asked the question), I just don’t know if it would even be possible to develop such a runtime from “the outside” so to speak, without making Max/MSP itself an open project as well.
I’m NOT a programmer however (though I think that’s pretty clear by now). . .so perhaps I’m overestimating what would be required for this effort.
You must be logged in to reply to this topic.