Re: [PD] jMax Phoenix
On Fri, 8 Oct 2010, Jonathan Wilkes wrote: Would it be difficult to transplant these keyboard patching features? You can't transplant them : it's a completely different API. DesireData is designed so that you can write this in Tcl ; PureData is designed so that you have to write much of that in C. Part of the rationale was that Tcl is easier to learn than C. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Fri, 10/8/10, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: "IOhannes m zmoelnig" , pd-list@iem.at > Date: Friday, October 8, 2010, 4:46 PM > On Tue, 5 Oct 2010, Jonathan Wilkes > wrote: > > > Well Ctrl-6 doesn't currently do anything _while_ you > are editing the contents of an object box, right? I > just once I am done typing the name of the object I want a > shortcut to be able to then immediately hit Ctrl-6 to mean > the same as currently hitting Enter, then Ctrl-6. One > less key. > > Yeah, that's one possibility, but given that the rest of > the software is full of showstoppers (left mostly as-is > since 2007), and that we're not really trying to transplant > that feature to a working branch of pd, it's not so much > worth thinking about it. Would it be difficult to transplant these keyboard patching features? > > I was also thinking about replacing Ctrl-6 by something > else, such as Ctrl-Shift-1 (but this can't be done because > it doesn't work on AZERTY). With your idea, I'd consider > Shift-Enter because it's an extension of what Enter does and > it's not Ctrl-Enter. > > > ___ > | Mathieu Bouchard -- Villeray, > Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Thu, 23 Sep 2010, Bernardo Barros wrote:
if (0.5.coin) {"Hey".postln} {"Ho!"};
OR
if (0.5.coin, {"Hey".postln}, {"Ho!"});
But since SC is object-oriented and "if" is a method of "boolean",
this also works and would be considered more consistent with the
language design:
(0.5.coin).if({"Hey".postln}, {"Ho!"})
To complete what we were saying, even though there's a lot in common
between SC and Ruby, conditionals are completely different over there, and
there are nine syntaxes for conditionals, NOT including a method of
boolean (because Ruby doesn't have this feature).
I forgot to say last time (and that's probably what IOhannes was referring
to) that in Perl and Ruby, the operators && || "and" "or" have been
recycled into conditionals in Perl and Ruby. Then there are also the
reverse conditionals "if" and "unless". those statements are all
equivalent in Ruby :
if debug then post("problem") end
unless not debug then post("problem") end
post("problem") if debug
post("problem") unless not debug
debug and post("problem")
debug && post("problem")
not debug or post("problem")
!debug || post("problem")
debug ? post("problem") : nil
which is almost the same deal as in Perl except Ruby's regular "if"
statement is actually an expression.
"and"/"or" and "&&"/"||" aren't just aliases, because they also have
different priorities.
___
| Mathieu Bouchard -- Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Tue, 5 Oct 2010, Jonathan Wilkes wrote: Well Ctrl-6 doesn't currently do anything _while_ you are editing the contents of an object box, right? I just once I am done typing the name of the object I want a shortcut to be able to then immediately hit Ctrl-6 to mean the same as currently hitting Enter, then Ctrl-6. One less key. Yeah, that's one possibility, but given that the rest of the software is full of showstoppers (left mostly as-is since 2007), and that we're not really trying to transplant that feature to a working branch of pd, it's not so much worth thinking about it. I was also thinking about replacing Ctrl-6 by something else, such as Ctrl-Shift-1 (but this can't be done because it doesn't work on AZERTY). With your idea, I'd consider Shift-Enter because it's an extension of what Enter does and it's not Ctrl-Enter. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Tue, 10/5/10, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: "IOhannes m zmoelnig" , pd-list@iem.at > Date: Tuesday, October 5, 2010, 5:38 PM > On Mon, 4 Oct 2010, Jonathan Wilkes > wrote: > > > I do remember that in Desiredata you have to actually > create the object with before you are > able to autoconnect another one, which is an unnecessary > step. > > Ctrl-Enter doesn't do what you say it does. It introduces a > newline in the text you are writing. Somehow it used to be > doing it correctly, but stopped doing it correctly when the > history feature was added to objectbox edition (there were > just too many features in DesireData : that one overrode the > normal use of the up and down arrows. I don't recall why we > did it like that.) > > a plain Enter terminates the objectbox, Yes, I got this confused with from Pd ext. > which is a lot more > convenient than taking the mouse and find a spot where > there's a piece of nothingness you can click on so that your > objectbox gets made without triggering any other change by > accident. > > then in DesireData, a box you finished with Enter is also > automatically selected, and this selection is used in > determining the origin of the auto-connection done when > making an objectbox with Ctrl-6 (six). Well Ctrl-6 doesn't currently do anything _while_ you are editing the contents of an object box, right? I just once I am done typing the name of the object I want a shortcut to be able to then immediately hit Ctrl-6 to mean the same as currently hitting Enter, then Ctrl-6. One less key. -Jonathan > > > ___ > | Mathieu Bouchard -- Villeray, > Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Mon, 4 Oct 2010, Jonathan Wilkes wrote: I do remember that in Desiredata you have to actually create the object with before you are able to autoconnect another one, which is an unnecessary step. Ctrl-Enter doesn't do what you say it does. It introduces a newline in the text you are writing. Somehow it used to be doing it correctly, but stopped doing it correctly when the history feature was added to objectbox edition (there were just too many features in DesireData : that one overrode the normal use of the up and down arrows. I don't recall why we did it like that.) a plain Enter terminates the objectbox, which is a lot more convenient than taking the mouse and find a spot where there's a piece of nothingness you can click on so that your objectbox gets made without triggering any other change by accident. then in DesireData, a box you finished with Enter is also automatically selected, and this selection is used in determining the origin of the auto-connection done when making an objectbox with Ctrl-6 (six). ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Mon, 10/4/10, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: "IOhannes m zmoelnig" , pd-list@iem.at > Date: Monday, October 4, 2010, 8:40 PM > On Thu, 23 Sep 2010, Jonathan Wilkes > wrote: > > > I thought it was in 0.43-- at least I'm using Pd > version 0.42.5-extended and there isn't the autopatching > feature. > > This is one of the rare features of Pd-vanilla 42 that is > disabled in Pd-extended 42. > > > I initially liked what I saw of the autopatching > features in Desiredata, but I haven't tried them enough to > judge. > > It's not very related : you'd press a separate keyboard > shortcut to explicitly get an autopatched objects. That's > not incompatible with users' habits. Miller's implementation > goes against the existing habits of users. Right, I remember that. I just didn't use it enough to find out exactly how convenient navigating around different objects/inlet /outlets and making connections with the keyboard was. I do remember that in Desiredata you have to actually create the object with before you are able to autoconnect another one, which is an unnecessary step. -Jonathan > > > I also seem to remember the possibility of increasing > the mouse-over radius around each inlet so you don't have to > be so precise to make a connection. > > That applied to everything you could click on (and drag > from or to) in a canvas. > > > ___ > | Mathieu Bouchard -- Villeray, > Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Thu, 23 Sep 2010, Jonathan Wilkes wrote: I thought it was in 0.43-- at least I'm using Pd version 0.42.5-extended and there isn't the autopatching feature. This is one of the rare features of Pd-vanilla 42 that is disabled in Pd-extended 42. I initially liked what I saw of the autopatching features in Desiredata, but I haven't tried them enough to judge. It's not very related : you'd press a separate keyboard shortcut to explicitly get an autopatched objects. That's not incompatible with users' habits. Miller's implementation goes against the existing habits of users. I also seem to remember the possibility of increasing the mouse-over radius around each inlet so you don't have to be so precise to make a connection. That applied to everything you could click on (and drag from or to) in a canvas. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
Jonathan Wilkes wrote: --- On Sun, 9/26/10, Kim Cascone wrote: From: Kim Cascone Subject: Re: [PD] jMax Phoenix To: "pd-list" Cc: zmoel...@iem.at Date: Sunday, September 26, 2010, 2:52 PM you can make _very_ elegant super-readable control flow with the use of [route] and friends. IOhannes I find this particular subject very interesting I was recently working on a patch using [expr] found the lack of being able to send the results of multiple 'if' statements to the same outlet frustrating - I am also used The reason [expr] doesn't work well in that case is that you must nest multiple if statements, which quickly makes the args hard to decipher. yes I found this out by trying if, then-if, else-if (it would be nice if the help patch would be updated/improved a little with more examples) but also found it hard to decipher when coming back to it later even with copious comments so I used multiple if statements and then tried to deal with the multiple outputs which I did but can't remember off hand how will post the patch at some point I'm on tour now so busy with other things :) to using the Max/MSP [if] object for these sorts of tasks can point me to some examples of using [route] and friends as control statements to check out? thanks! KIM ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
Jonathan Wilkes wrote: --- On Sun, 9/26/10, Kim Cascone wrote: From: Kim Cascone Subject: Re: [PD] jMax Phoenix To: "pd-list" Cc: zmoel...@iem.at Date: Sunday, September 26, 2010, 2:52 PM you can make _very_ elegant super-readable control flow with the use of [route] and friends. IOhannes I find this particular subject very interesting I was recently working on a patch using [expr] found the lack of being able to send the results of multiple 'if' statements to the same outlet frustrating - I am also used The reason [expr] doesn't work well in that case is that you must nest multiple if statements, which quickly makes the args hard to decipher. yes I found this out by trying if, then-if, else-if (it would be nice if the help patch would be updated/improved a little with more examples) but also found it hard to decipher when coming back to it later even with copious comments so I used multiple if statements and then tried to deal with the multiple outputs which I did but can't remember off hand how will post the patch at some point I'm on tour now so busy with other things :) to using the Max/MSP [if] object for these sorts of tasks can point me to some examples of using [route] and friends as control statements to check out? thanks! KIM ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Sun, 9/26/10, Kim Cascone wrote: > From: Kim Cascone > Subject: Re: [PD] jMax Phoenix > To: "pd-list" > Cc: zmoel...@iem.at > Date: Sunday, September 26, 2010, 2:52 PM > > > > you can make _very_ elegant super-readable control > flow with the use of > > [route] and friends. > IOhannes > > I find this particular subject very interesting > I was recently working on a patch using [expr] found the > lack of being able to send the results of multiple 'if' > statements to the same outlet frustrating - I am also used The reason [expr] doesn't work well in that case is that you must nest multiple if statements, which quickly makes the args hard to decipher. > to using the Max/MSP [if] object for these sorts of tasks > can point me to some examples of using [route] and friends > as control statements to check out? > thanks! > KIM > > > > > ___ > Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Sun, 26 Sep 2010, Kim Cascone wrote: I find this particular subject very interesting I was recently working on a patch using [expr] found the lack of being able to send the results of multiple 'if' statements to the same outlet frustrating - I am also used to using the Max/MSP [if] object for these sorts of tasks can point me to some examples of using [route] and friends as control statements to check out? thanks! KIM I don't understand "using [route] as a control statement". It already is a control statement. Maybe you should provide us with an example of problem-solving that you think is very easy to do with [if] and very hard to think of without. Well, or whichever problem you had in mind when you wrote this above. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
you can make _very_ elegant super-readable control flow with the use of [route] and friends. IOhannes I find this particular subject very interesting I was recently working on a patch using [expr] found the lack of being able to send the results of multiple 'if' statements to the same outlet frustrating - I am also used to using the Max/MSP [if] object for these sorts of tasks can point me to some examples of using [route] and friends as control statements to check out? thanks! KIM ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
Just curious, Any developer never considered taking a look at Nova? Once I skimmed Tim's thesis and it seemd interesting for Max-like languages like PD, It was reliable, performed 2 times faster then Pd and had a pretty Python+Qt Gui. (And Qt is very efficient, pretty and cross-platform). anuway, it was deprecated not because it has bad design, he just switched to supercollider/supernova. well, it looked nice. 2010/9/24 IOhannes zmölnig : > On 09/23/2010 11:33 PM, Jonathan Wilkes wrote: >> >> I thought it was in 0.43-- at least I'm using >> Pd version 0.42.5-extended and there isn't the autopatching >> feature. >> > it is in Pd-vanilla. > either Pd-extended has disabled it completely, or you have to turn it on > manually or it is turned off by default. > > fgmasr > IOhannes > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On 09/23/2010 11:33 PM, Jonathan Wilkes wrote: > > I thought it was in 0.43-- at least I'm using > Pd version 0.42.5-extended and there isn't the autopatching > feature. > it is in Pd-vanilla. either Pd-extended has disabled it completely, or you have to turn it on manually or it is turned off by default. fgmasr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Thu, 9/23/10, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: pd-list@iem.at, gridflow-...@artengine.ca > Date: Thursday, September 23, 2010, 8:22 PM > On Wed, 22 Sep 2010, Mathieu Bouchard > wrote: > > > At this point, [#expr 1000-100-10-1] = 909, and I'm > trying to make it so that it's 889. It's because > (1000-(100-(10-(1 = 909 and 1000)-100)-10)-1) = > 889. > > ok, it's fixed, [#expr 1000-100-10-1] > > I have a parser for + - * / & | ^ with correct operator > precedence and left-associativity, and support for float > literals and 0x hex literals. (nothing else yet) > > You can try it now if you compile the svn head of > gridflow. Hey, that's great! I'll try it out as soon as I get a chance. -Jonathan > > > ___ > | Mathieu Bouchard -- Villeray, > Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Thu, 9/23/10, IOhannes m zmoelnig wrote: > From: IOhannes m zmoelnig > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: pd-list@iem.at > Date: Thursday, September 23, 2010, 12:10 PM > On 2010-09-23 11:10, Jonathan Wilkes > wrote: > > > > > > I use keyboard shortcuts but they don't help the > problem of > > lining up objects with the mouse or with > , and > > of making connections between objects which requires a > click in > > a very specific place. Actually I find making 24 > connections, > > one-at-a-time with the mouse to be the most tedious > part of the > > i also became quite used to using the autopatch feature > introduced in > pd-0.42 (true, in the beginning it was _very_ annoying; but > once you get > around that, it starts to become fun) I thought it was in 0.43-- at least I'm using Pd version 0.42.5-extended and there isn't the autopatching feature. I initially liked what I saw of the autopatching features in Desiredata, but I haven't tried them enough to judge. I also seem to remember the possibility of increasing the mouse-over radius around each inlet so you don't have to be so precise to make a connection. -Jonathan > > fgasdr > IOhannes > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
the java gui for supercollider (swingosc) is not very efficient performance-wise. It makes the cpu go from 8 to 25%... The new Qt (gui toolkit with c++ code) is incredibly more efficient and much more pleasant to the eyes, at least on gnu/linux. I also can't understand a very good reason to start such a similar application all over (jmax), why not just improve what is already working (pd) ?? 2010/9/23 ydego...@gmail.com : > ola, > > i did try to install jmax sometimes ago... > but i never used it, > the reason being java is totally unfit > for real-time apps and fast response > > have the same problem now with webcamstudio.. > > but suerte!, > sevy > > Maurizio De Cecco wrote: >> >> Hallo, >> >> my name is Maurizio De Cecco, and i am the maintainer and developper of >> the jMax Phoenix project, >> a kind of cousin of Puredata. Having release a new beta for jMax (on Linux >> and Mac OS X), and after >> discussing with Miller Puckette, i think the members of this list may be >> interested in knowing more >> about the project, and may be take a look. >> >> A bit of history: i worked in Ircam in the 90s, where i was lucky enough >> to work with Miller Puckette >> on Max/ISPW and following versions; i then worked on jMax, that was >> intended to be a 'next generation' >> Max for the Ircam projects; jMax was used in a few large productions; i >> left in 99 for pursing other >> interest (Linux Mandrake, at that time :), and forgot for a while about >> jMax. >> >> In the meanwhile, jMax was put under a GPL licence, and after a couple of >> years Ircam stopped its development >> (don't ask me why, i wasn't there). >> >> In 2008 i was getting severely bored: server side Java, quality indicators >> and software engineering was my daily bread, and no code to write; so, to >> keep my developer mind healthy, i took up the development >> of jMax, starting from the last release i worked on. >> >> Given the fact that jMax slept a few years, it cannot compete with >> puredata in terms of available libraries, >> patches, and in general maturity of the solution. >> >> But it have its own peculiarity, a number of different ideas, and having a >> code base but no users (yet, i hope:) >> allows some bold design decision to be taken; think of jMax Phoenix as a >> kind of research project in same family where Puredata is. >> >> Describing the differences between jMax and Puredata would be long, >> because it would need to go back >> to the original developments; to be very synthetic i would resume in the >> following: >> >> 1) Architecture: the jMax user interface run on a different process, and >> it written in Java. >> >> 2) APIs are completely different, but see below. >> >> 3) The Object Set is reduced to the old ISPW object set; jMax can also >> transparently include LADSPA plugins as objects; finally, i developped >> compatibility layer (to be completed) that allows to recompile simple pd >> objects for jMax, and possibly to load pd abstractions. >> >> 4) User Interface: there is a lot of work going on in the UI, that allows, >> between other, the used of a single window IDE style interface. >> >> 5) Packaging and configuration: jMax Phoenix support the packaging >> of complex libraries and applications in a single file, and even >> automatically grab libraries from the internet. >> >> 6) The language: jMax support the use of expressions in object definition, >> like in | int ( 10 + $foo) | so that objects in abstractions can be >> parametrised with respect to the arguments. >> >> 7) Hopefully in between 6 month and a year: an optimising dsp compiler >> and engine able to run a patch in parallel on multiple core (where >> multiple means around 8). >> >> For anybody more interested, the project site is >> http://www.jmax-phoenix.org/, and the >> binaries and sources can be loaded from the project sourceforge site, >> http://sourceforge.net/projects/jmax-phoenix/ >> >> For your information, i include at the end of the mail the formal announce >> of the 0.6 beta release; it does not mention the Max OS X version, that was >> not ready at the time. >> >> Maurizio >> >> - >> >> After many month of development, we are proud to announce the version 0.6 >> beta of jMax Phoenix. >> >> The major highlights for this version are: >> - A first version of the puredata source compatibility kit, including the >> build system and a full example of recompiled object library. >> - A large set of usability bug fixed; all the bugs preventing a smooth >> work flow have been fixed. >> - Error handling improvements: most of the bugs and configuration errors >> now results in error messages, and not unexplained freezes. >> - A set of examples and tutorials has been recovered from old ISPW >> archives; they are not updated to include all the major jMax >> functionalities, but it is better than nothing. >> >> Full release notes are available in the release notes section of th
Re: [PD] jMax Phoenix
ola, i did try to install jmax sometimes ago... but i never used it, the reason being java is totally unfit for real-time apps and fast response have the same problem now with webcamstudio.. but suerte!, sevy Maurizio De Cecco wrote: Hallo, my name is Maurizio De Cecco, and i am the maintainer and developper of the jMax Phoenix project, a kind of cousin of Puredata. Having release a new beta for jMax (on Linux and Mac OS X), and after discussing with Miller Puckette, i think the members of this list may be interested in knowing more about the project, and may be take a look. A bit of history: i worked in Ircam in the 90s, where i was lucky enough to work with Miller Puckette on Max/ISPW and following versions; i then worked on jMax, that was intended to be a 'next generation' Max for the Ircam projects; jMax was used in a few large productions; i left in 99 for pursing other interest (Linux Mandrake, at that time :), and forgot for a while about jMax. In the meanwhile, jMax was put under a GPL licence, and after a couple of years Ircam stopped its development (don't ask me why, i wasn't there). In 2008 i was getting severely bored: server side Java, quality indicators and software engineering was my daily bread, and no code to write; so, to keep my developer mind healthy, i took up the development of jMax, starting from the last release i worked on. Given the fact that jMax slept a few years, it cannot compete with puredata in terms of available libraries, patches, and in general maturity of the solution. But it have its own peculiarity, a number of different ideas, and having a code base but no users (yet, i hope:) allows some bold design decision to be taken; think of jMax Phoenix as a kind of research project in same family where Puredata is. Describing the differences between jMax and Puredata would be long, because it would need to go back to the original developments; to be very synthetic i would resume in the following: 1) Architecture: the jMax user interface run on a different process, and it written in Java. 2) APIs are completely different, but see below. 3) The Object Set is reduced to the old ISPW object set; jMax can also transparently include LADSPA plugins as objects; finally, i developped compatibility layer (to be completed) that allows to recompile simple pd objects for jMax, and possibly to load pd abstractions. 4) User Interface: there is a lot of work going on in the UI, that allows, between other, the used of a single window IDE style interface. 5) Packaging and configuration: jMax Phoenix support the packaging of complex libraries and applications in a single file, and even automatically grab libraries from the internet. 6) The language: jMax support the use of expressions in object definition, like in | int ( 10 + $foo) | so that objects in abstractions can be parametrised with respect to the arguments. 7) Hopefully in between 6 month and a year: an optimising dsp compiler and engine able to run a patch in parallel on multiple core (where multiple means around 8). For anybody more interested, the project site is http://www.jmax-phoenix.org/, and the binaries and sources can be loaded from the project sourceforge site, http://sourceforge.net/projects/jmax-phoenix/ For your information, i include at the end of the mail the formal announce of the 0.6 beta release; it does not mention the Max OS X version, that was not ready at the time. Maurizio - After many month of development, we are proud to announce the version 0.6 beta of jMax Phoenix. The major highlights for this version are: - A first version of the puredata source compatibility kit, including the build system and a full example of recompiled object library. - A large set of usability bug fixed; all the bugs preventing a smooth work flow have been fixed. - Error handling improvements: most of the bugs and configuration errors now results in error messages, and not unexplained freezes. - A set of examples and tutorials has been recovered from old ISPW archives; they are not updated to include all the major jMax functionalities, but it is better than nothing. Full release notes are available in the release notes section of the projet site. This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian 5, Fedora 13 and Mandriva Spring 2010; check the installation instruction on the projet site for specific caveats for Debian and Fedora. The Puredata compatibility sub-project has been *very* time consuming; in order to better manage my scarce time resources, we need some user feedback (and possibly help) to be able to evaluate the actual interest of pursuing this development direction. For more information and download and installation instructions go to http://www.jmax-phoenix.org/. For contacting the project team: cont...@jmax-phoenix.org The jMax Phoenix
Re: [PD] jMax Phoenix
On Wed, 22 Sep 2010, Mathieu Bouchard wrote: At this point, [#expr 1000-100-10-1] = 909, and I'm trying to make it so that it's 889. It's because (1000-(100-(10-(1 = 909 and 1000)-100)-10)-1) = 889. ok, it's fixed, [#expr 1000-100-10-1] I have a parser for + - * / & | ^ with correct operator precedence and left-associativity, and support for float literals and 0x hex literals. (nothing else yet) You can try it now if you compile the svn head of gridflow. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
I don't know the multiple syntaxes SuperCollider supports is a bad or
good thing (comparing to Python where there is only one syntax for
everything):
if (0.5.coin) {"Hey".postln} {"Ho!"};
OR
if (0.5.coin, {"Hey".postln}, {"Ho!"});
But since SC is object-oriented and "if" is a method of "boolean",
this also works and would be considered more consistent with the
language design:
(0.5.coin).if({"Hey".postln}, {"Ho!"})
2010/9/23 Mathieu Bouchard :
> On Thu, 23 Sep 2010, IOhannes m zmoelnig wrote:
>
>> yes, but i believe this is because you are very used to C-like languages,
>> so you assume that expr's if looks like: "if , , ".
>> you have been trained on that, probably since high school (and eventually
>> used it before) [*]. if you had been fed on perl, you might find other
>> things more easily to read.
>
> Perl also has a conditional-statement almost like C's. There are some
> differences. Its syntax is if (a) {b} else {c} instead of if (a) b; else c;
> because Perl has no separate concept of compound statement.
>
> And then also Perl has more different implicit conversions to bool than C
> has.
>
> The if-statement is remarkably uniform across different languages, in a way
> that the for-loop and the switch-statement aren't.
>
> The biggest difference you will see, is that some if-statements are actually
> if-expressions instead. This is the case with if(,,) in the [expr] class.
> This is also the case with a?b:c in C language. It's the case with
> if/then/else/end in Ruby and the if {} {} {} in Tcl.
>
> Perl is somewhat in-between because although you can't assign the result of
> an if-statement to a variable, you can return it from a function, but that's
> because Perl uses the value of the last executed statement as the default
> return value.
>
> ___
> | Mathieu Bouchard -- Villeray, Montréal, QC
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Thu, 23 Sep 2010, IOhannes m zmoelnig wrote:
yes, but i believe this is because you are very used to C-like
languages, so you assume that expr's if looks like: "if ,
, ". you have been trained on that, probably since high
school (and eventually used it before) [*]. if you had been fed on perl,
you might find other things more easily to read.
Perl also has a conditional-statement almost like C's. There are some
differences. Its syntax is if (a) {b} else {c} instead of if (a) b; else
c; because Perl has no separate concept of compound statement.
And then also Perl has more different implicit conversions to bool than C
has.
The if-statement is remarkably uniform across different languages, in a
way that the for-loop and the switch-statement aren't.
The biggest difference you will see, is that some if-statements are
actually if-expressions instead. This is the case with if(,,) in the
[expr] class. This is also the case with a?b:c in C language. It's the
case with if/then/else/end in Ruby and the if {} {} {} in Tcl.
Perl is somewhat in-between because although you can't assign the result
of an if-statement to a variable, you can return it from a function, but
that's because Perl uses the value of the last executed statement as the
default return value.
___
| Mathieu Bouchard -- Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Thu, 23 Sep 2010, Maurizio De Cecco wrote: Well, i am not the right guy for that; i am the only guy in town that: 1) Know deeply the jMax code. Every programmer is the only programmer who knows a certain piece of code. It does not make it automatically something that is worth maintaining (I mean that you have other reasons that you haven't listed). 2) Have some (limited) time and the motivation to work on it. If you do have motivation to work on it, that's fine, but we'd be curious to know why jMax is more motivating to you, than pd could be. So surely my personal contribution to the community can be on reviving jMax, and trying to fulfils its promises. there is no jMax community. But the pd core code base is do not offer a lot of help for core extensions; and as core extensions i mean for example a different DSP compiler, a different DSP execution engine, an extended object model. You can either replace the existing one completely, or add some kind of if-statement or function-pointer variable(s) to select a DSP compiler at runtime (isn't it ?). What would you change (or add) to the object model in particular ? The core code base offer little or no abstraction, direct access to data structure elements and so on; and how does this affect you ? jMax, at least at the source level, make things a lot easier for a developer that want to hack the code base, there are less dependencies between the different parts, and more abstraction in the API (that is more verbose as a consequence). Ah, yeah, that's what happens to programmes written in C. Java would be better for that, but C++ is even better for that... I mean, for making abstract code nearly as short as non-abstract code. Whereas for languages like Ruby, it's the other way around, as abstract code is usually shorter than non-abstract code. And the fact there is no stable community of users (yet ?) reduce the fear of catastrophes :-> It also reduces the chance to any help for testing the software. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On 2010-09-23 11:10, Jonathan Wilkes wrote: > > > I use keyboard shortcuts but they don't help the problem of > lining up objects with the mouse or with , and > of making connections between objects which requires a click in > a very specific place. Actually I find making 24 connections, > one-at-a-time with the mouse to be the most tedious part of the i also became quite used to using the autopatch feature introduced in pd-0.42 (true, in the beginning it was _very_ annoying; but once you get around that, it starts to become fun) fgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Thu, 9/23/10, IOhannes m zmoelnig wrote: > From: IOhannes m zmoelnig > Subject: Re: [PD] jMax Phoenix > To: pd-list@iem.at > Date: Thursday, September 23, 2010, 9:20 AM > On 2010-09-22 20:04, Jonathan Wilkes > wrote: > > > > Yes, Max/MSP's [if] object has a more readable > syntax. Yet even > > i don't know max's [if], but i guess you could basically > implement this > with an abstraction. > > > with the two nested "ifs" I find it easier to read > than your > > implementation because I don't have to look up to the > inlet to > > remind myself which list elements correspond to which > variable. > > > > yes, but i believe this is because you are very used to > C-like > languages, so you assume that expr's if looks like: "if > , > , ". > you have been trained on that, probably since high school > (and > eventually used it before) [*]. if you had been fed on > perl, you might > find other things more easily to read. > > > > I could put comments closer to each object chain, but > then that's > > even more objects. > > so? > > we all know that source-lines-of-code has nothing to do > with raedability > nor complexity. > more objects doesn't mean that the code is better OR worse > to read. > > (though of course it might be preferrable that the code > makes it clear > what is going on without having to resort to comments). > > >> and as a matter of fact, i don't think the > >> pd-implementation of the > >> algorithm is so bad. > > > > Yes, IMO the way you implemented it is nice because > there are > > very few wires crossing over objects. > > i think the main problems come from people trying to > implement C-like > control flow in a dataflow language like Pd. > even my implementation was only trying to reproduce the > algorithm you > wrote down, rather than trying to figure a Pd-way to > implement pong. > > you can make _very_ elegant super-readable control flow > with the use of > [route] and friends. > > > > > > I'd also mention I find it more difficult to patch > your > > implementation because there are 25 objects (not > including the > > number boxes), 16 of which correspond to the args of > [expr] in > > my implementation. That's 16 objects for which I > have to change > > modes between the mouse (for connections) and the > keyboard (for > > text). > > > if you find it difficult to patch 25 objects, then you > should get > yourself accustomed to keyboard short-cuts. > if you need go to the menu->put->object for each of > the 25 objects, then > i understand your concerns. with Ctrl-1 i don't see the > problem with > patching 25 or 3 objects. I use keyboard shortcuts but they don't help the problem of lining up objects with the mouse or with , and of making connections between objects which requires a click in a very specific place. Actually I find making 24 connections, one-at-a-time with the mouse to be the most tedious part of the whole ordeal. If I could just imagine the wires into existence then I might not use [expr] as much as I do. > > > > > > With [expr] I find it conceptually easier (and more > ergonomic) to > > set up my [v] objects, my [sel], and my [outlet], then > code the > > entire algorithm inside one box. > > i hardly ever use [value]. > i think it doesn't integrate so well into the patcher > paradigm, thus > making you want to program C-like rather than Pd-like. That's only true when using it in conjunction with [expr]. At least the other times I've used it have been basically a shortcut for: [s] | [f] > > that's not to say that i never use [value], it surely has > its merits. > > > > > Btw- you can get rid of 3 overlapping wires if you put > [value py] > > closest to [unpack 0 0 0] and cascade them that way. > > btw, i'm not very interested in getting rid of all > overlapping wires. > spaghetti code is probably something that is unreadable, > but the odd > overlapping wire is something my brain has adapted to > decyphering very well. > > fgmasdr > IOhannes > > > > > [*] note that i went to highschool in austria around 1990; > things might > have changed substantially since then. > > > -Inline Attachment Follows- > > ___ > Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
>> Pd is not the end of history for the MAX language, > >That's not what I mean, what I mean is that it's more worthwhile to fork >Pd than to fork (or revive) jMax. Well, i am not the right guy for that; i am the only guy in town that: 1) Know deeply the jMax code. 2) Have some (limited) time and the motivation to work on it. So surely my personal contribution to the community can be on reviving jMax, and trying to fulfils its promises. >> there is still a lot that can be done at the core level. jMax Phoenix is >> a kind of research project; for now, i am trying to make it usable; >> later, to provide strong reasons for using it, at least in some specific >> field or projects. > >I think that some of those "core" features could become Pd externals >(albeit rather unusual ones). If jMax prove that some ideas are good, they may be translated in pd; i'll be happy to help, in this case. But the pd core code base is do not offer a lot of help for core extensions; and as core extensions i mean for example a different DSP compiler, a different DSP execution engine, an extended object model. The core code base offer little or no abstraction, direct access to data structure elements and so on; as i said, i emulate a part of the pd API on jMax, to allow porting of pd objects, but it is very* difficult to retrofit pd externals with for example an extended object model. So, there are limits in what you can do. jMax, at least at the source level, make things a lot easier for a developer that want to hack the code base, there are less dependencies between the different parts, and more abstraction in the API (that is more verbose as a consequence). And the fact there is no stable community of users (yet ?) reduce the fear of catastrophes :-> Maurizio ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On 2010-09-23 09:20, IOhannes m zmoelnig wrote: > > i think the main problems come from people trying to implement C-like > control flow in a dataflow language like Pd. > even my implementation was only trying to reproduce the algorithm you > wrote down, rather than trying to figure a Pd-way to implement pong. > so i think that one is more Pd'ish. it's not trying to mimick your algorithm but rather solve the original problem. this eventually leads to a slight difference in the output (your implementation and mine are not fully compatible), as here the py denotes the middle of the paddle rather than the lower edge. for the sake of simplicity i used an abstraction. masrt IOhannes #N canvas 789 122 450 570 10; #X obj 104 51 inlet; #X obj 104 128 list split 1; #X obj 104 156 \$1 \$2; #X obj 103 175 select 1 0; #X obj 103 278 list append; #X obj 104 72 t l l; #X obj 192 248 list append; #X obj 103 299 outlet; #X obj 192 268 outlet reject; #X connect 0 0 5 0; #X connect 1 0 2 0; #X connect 1 1 4 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 1 6 0; #X connect 4 0 7 0; #X connect 5 0 1 0; #X connect 5 1 6 1; #X connect 6 0 8 0; #N canvas 178 0 828 611 10; #X obj 150 447 t f; #X obj 150 230 ifroute <= 0; #X obj 150 468 outlet; #X text 358 238 check y-boundaries; #X text 189 169 check x-boundaries; #X obj 508 296 -; #X obj 508 317 abs; #X obj 508 338 < 30; #X text 655 325 check paddle; #X obj 230 230 ifroute < 500; #X obj 50 54 inlet bx by py; #X msg 50 175 2 bounce right; #X msg 150 261 4 bounce bottom; #X msg 305 261 5 bounce top; #X msg 508 359 \$1 hit/miss paddle; #X obj 50 147 ifroute >= 415; #X obj 150 147 ifroute > 20; #X obj 508 147 ifroute > 0; #X connect 0 0 2 0; #X connect 1 0 12 0; #X connect 1 1 9 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 14 0; #X connect 9 1 13 0; #X connect 10 0 15 0; #X connect 11 0 0 0; #X connect 12 0 0 0; #X connect 13 0 0 0; #X connect 14 0 0 0; #X connect 15 0 11 0; #X connect 15 1 16 0; #X connect 16 0 1 0; #X connect 16 1 17 0; #X connect 17 0 5 0; smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On 2010-09-22 20:04, Jonathan Wilkes wrote: > > Yes, Max/MSP's [if] object has a more readable syntax. Yet even i don't know max's [if], but i guess you could basically implement this with an abstraction. > with the two nested "ifs" I find it easier to read than your > implementation because I don't have to look up to the inlet to > remind myself which list elements correspond to which variable. > yes, but i believe this is because you are very used to C-like languages, so you assume that expr's if looks like: "if , , ". you have been trained on that, probably since high school (and eventually used it before) [*]. if you had been fed on perl, you might find other things more easily to read. > I could put comments closer to each object chain, but then that's > even more objects. so? we all know that source-lines-of-code has nothing to do with raedability nor complexity. more objects doesn't mean that the code is better OR worse to read. (though of course it might be preferrable that the code makes it clear what is going on without having to resort to comments). >> and as a matter of fact, i don't think the >> pd-implementation of the >> algorithm is so bad. > > Yes, IMO the way you implemented it is nice because there are > very few wires crossing over objects. i think the main problems come from people trying to implement C-like control flow in a dataflow language like Pd. even my implementation was only trying to reproduce the algorithm you wrote down, rather than trying to figure a Pd-way to implement pong. you can make _very_ elegant super-readable control flow with the use of [route] and friends. > > I'd also mention I find it more difficult to patch your > implementation because there are 25 objects (not including the > number boxes), 16 of which correspond to the args of [expr] in > my implementation. That's 16 objects for which I have to change > modes between the mouse (for connections) and the keyboard (for > text). if you find it difficult to patch 25 objects, then you should get yourself accustomed to keyboard short-cuts. if you need go to the menu->put->object for each of the 25 objects, then i understand your concerns. with Ctrl-1 i don't see the problem with patching 25 or 3 objects. > > With [expr] I find it conceptually easier (and more ergonomic) to > set up my [v] objects, my [sel], and my [outlet], then code the > entire algorithm inside one box. i hardly ever use [value]. i think it doesn't integrate so well into the patcher paradigm, thus making you want to program C-like rather than Pd-like. that's not to say that i never use [value], it surely has its merits. > > Btw- you can get rid of 3 overlapping wires if you put [value py] > closest to [unpack 0 0 0] and cascade them that way. btw, i'm not very interested in getting rid of all overlapping wires. spaghetti code is probably something that is unreadable, but the odd overlapping wire is something my brain has adapted to decyphering very well. fgmasdr IOhannes [*] note that i went to highschool in austria around 1990; things might have changed substantially since then. smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Wed, 9/22/10, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: pd-list@iem.at, gridflow-...@artengine.ca > Date: Wednesday, September 22, 2010, 8:46 PM > On Wed, 22 Sep 2010, Jonathan Wilkes > wrote: > > --- On Wed, 9/22/10, Mathieu Bouchard > wrote: > >> Btw I started coding [#expr] last week... but I > think that > >> it will take a long time to finish coding it. > > > > Great! > > * [#expr 3 / 2] ? > > At this point 1.5, and I think I will keep it that way, > unless I require everything to default to being a grid. I > wondered whether I ought to split between a float-centric > version called [gf/expr] and a grid-centric version called > [#expr], or have everything together in the same version. At > this point, though, I only have plain floats. I prefer your current way to the Max/MSP-oriented way that [expr] does it. I find the [expr] way particularly ill-suited to Pd since Pd strips away unnecessary decimals and decimal places, thus making it look like it's Max-compatible when, depending on where the user puts whitespace, it may not be: [expr 2.0/3] is the same in Max/Pd [expr 2.0 /3] is not > > GridFlow's grids default to int32 (This is because this is > the int type in jMax. It's also the int type in Max and > others except Pd) > > > * [#expr if $f1 < 3 then $f1 goes to the left > outlet else $f1 goes to the right outlet] ? > > I don't know how this would work. In [expr], the number of > outlets depends on the number of semicolon-separated > expressions, and each triggering of [expr] causes them to be > evaluated right-to-left. There's no syntax for not > outputting on an outlet. What do you suggest ? It's tricky. You could add a function that takes no arguments which means, "Don't output." But then I think it would be more useful to have a flexible if, then, else syntax where you can specify the outlet explicitly. Maybe that means this is a separate object than expr. I read the Max 5 documentation and they have if and else functions where you specify the outlet with out1, out2, etc. http://cycling74.com/docs/max5/refpages/max-ref/if.html > > > * [#expr $0-array[$f1] ] ? > > I suppose so, but we're far from that. > > At this point, [#expr 1000-100-10-1] = 909, and I'm trying > to make it so that it's 889. It's because > (1000-(100-(10-(1 = 909 and 1000)-100)-10)-1) = > 889. > > The only supported method is bang and even $f1 doesn't even > exist yet. > > > ___ > | Mathieu Bouchard -- Villeray, > Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
Now you just need Chris Klippel to dust off the old video code he and I worked on those many, many years ago (almost a decade!). On Tue, Sep 21, 2010 at 4:11 PM, Maurizio De Cecco wrote: > Hallo, > > my name is Maurizio De Cecco, and i am the maintainer and developper of the > jMax Phoenix project, > a kind of cousin of Puredata. Having release a new beta for jMax (on Linux > and Mac OS X), and after > discussing with Miller Puckette, i think the members of this list may be > interested in knowing more > about the project, and may be take a look. > > A bit of history: i worked in Ircam in the 90s, where i was lucky enough to > work with Miller Puckette > on Max/ISPW and following versions; i then worked on jMax, that was > intended to be a 'next generation' > Max for the Ircam projects; jMax was used in a few large productions; i > left in 99 for pursing other > interest (Linux Mandrake, at that time :), and forgot for a while about > jMax. > > In the meanwhile, jMax was put under a GPL licence, and after a couple of > years Ircam stopped its development > (don't ask me why, i wasn't there). > > In 2008 i was getting severely bored: server side Java, quality indicators > and software engineering was my daily bread, and no code to write; so, to > keep my developer mind healthy, i took up the development > of jMax, starting from the last release i worked on. > > Given the fact that jMax slept a few years, it cannot compete with puredata > in terms of available libraries, > patches, and in general maturity of the solution. > > But it have its own peculiarity, a number of different ideas, and having a > code base but no users (yet, i hope:) > allows some bold design decision to be taken; think of jMax Phoenix as a > kind of research project in same family where Puredata is. > > Describing the differences between jMax and Puredata would be long, because > it would need to go back > to the original developments; to be very synthetic i would resume in the > following: > > 1) Architecture: the jMax user interface run on a different process, and it > written in Java. > > 2) APIs are completely different, but see below. > > 3) The Object Set is reduced to the old ISPW object set; jMax can also > transparently include LADSPA plugins as objects; finally, i developped > compatibility layer (to be completed) that allows to recompile simple pd > objects for jMax, and possibly to load pd abstractions. > > 4) User Interface: there is a lot of work going on in the UI, that allows, > between other, the used of a single window IDE style interface. > > 5) Packaging and configuration: jMax Phoenix support the packaging > of complex libraries and applications in a single file, and even > automatically grab libraries from the internet. > > 6) The language: jMax support the use of expressions in object definition, > like in | int ( 10 + $foo) | so that objects in abstractions can be > parametrised with respect to the arguments. > > 7) Hopefully in between 6 month and a year: an optimising dsp compiler > and engine able to run a patch in parallel on multiple core (where multiple > means around 8). > > For anybody more interested, the project site is > http://www.jmax-phoenix.org/, and the > binaries and sources can be loaded from the project sourceforge site, > http://sourceforge.net/projects/jmax-phoenix/ > > For your information, i include at the end of the mail the formal announce > of the 0.6 beta release; it does not mention the Max OS X version, that was > not ready at the time. > > Maurizio > > - > > After many month of development, we are proud to announce the version 0.6 > beta of jMax Phoenix. > > The major highlights for this version are: > - A first version of the puredata source compatibility kit, including the > build system and a full example of recompiled object library. > - A large set of usability bug fixed; all the bugs preventing a smooth > work flow have been fixed. > - Error handling improvements: most of the bugs and configuration errors > now results in error messages, and not unexplained freezes. > - A set of examples and tutorials has been recovered from old ISPW > archives; they are not updated to include all the major jMax > functionalities, but it is better than nothing. > > Full release notes are available in the release notes section of the projet > site. > > This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian 5, > Fedora 13 and Mandriva Spring 2010; check the installation > instruction on the projet site for specific caveats for Debian and Fedora. > > The Puredata compatibility sub-project has been *very* time consuming; in > order to better manage my scarce time resources, > we need some user feedback (and possibly help) to be able to evaluate the > actual interest of pursuing this development direction. > > For more information and download and installation instructions go to > http://www.jmax-phoenix
Re: [PD] jMax Phoenix
Iterative loops are pretty easy with [until]. In certain circumstances recursive loops are not so difficult, either. For me there are just certain types of conditional statements and chains of operators that are easier to do and read in expr rather than with several objects. In the attached example, the comparison between the object chain with [random] and [expr random($f2, $f1)] isn't really fair, but even if expr's random function only took one argument, I still prefer [expr random($f1-$f2) + $f2]. Also, I just realized that if I want to really make "max" be the maximum I just have to insert "+1", whereas with [random] I have to disconnect some wires and connect a new object [+ 1] to the chain. -Jonathan --- On Wed, 9/22/10, Bernardo Barros wrote: > From: Bernardo Barros > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: pd-list@iem.at, "IOhannes m zmoelnig" > Date: Wednesday, September 22, 2010, 8:57 PM > the only solution I see to write this > kind of things in Max-like > languages is to allow the user to just open a text-box and > write what > he/she wants in python or supercollider :-) that's for > control > structures, loops, etc > > 2010/9/22 Jonathan Wilkes : > > > > > > --- On Wed, 9/22/10, IOhannes m zmoelnig > wrote: > > > >> From: IOhannes m zmoelnig > >> Subject: Re: [PD] jMax Phoenix > >> To: pd-list@iem.at > >> Date: Wednesday, September 22, 2010, 6:36 PM > >> On 2010-09-22 16:48, Jonathan Wilkes > >> wrote: > >> > > >> > > >> > expr if(bx<=20, if (py<=by && > >> py+60>=by, 0, 1), -1); > >> > if (bx>=415, 2, -1); > >> > if (by<=0, 4, if (by>=500, 5, -1)) > >> > > >> > >> honestly i find this hard to read as well, esp. > compared to > >> traditional > >> C-like syntax: > >> > >> if(bx<=20) > >> if(py<=by && py+60>=by) > >> return 0; > >> else > >> return 1; > >> if(by>=415) > >> return 2; > >> else > >> return -1; > >> if(by<=0) > >> return 4; > >> else if (by>=500) > >> return 5; > > > > Yes, Max/MSP's [if] object has a more readable syntax. > Yet even > > with the two nested "ifs" I find it easier to read > than your > > implementation because I don't have to look up to the > inlet to > > remind myself which list elements correspond to which > variable. > > > > I could put comments closer to each object chain, but > then that's > > even more objects. > > > >> > >> > >> and as a matter of fact, i don't think the > >> pd-implementation of the > >> algorithm is so bad. > > > > Yes, IMO the way you implemented it is nice because > there are > > very few wires crossing over objects. > > > > I'd also mention I find it more difficult to patch > your > > implementation because there are 25 objects (not > including the > > number boxes), 16 of which correspond to the args of > [expr] in > > my implementation. That's 16 objects for which I > have to change > > modes between the mouse (for connections) and the > keyboard (for > > text). > > > > With [expr] I find it conceptually easier (and more > ergonomic) to > > set up my [v] objects, my [sel], and my [outlet], then > code the > > entire algorithm inside one box. > > > > Btw- you can get rid of 3 overlapping wires if you put > [value py] > > closest to [unpack 0 0 0] and cascade them that way. > > > > -Jonathan > > > >> the only awkwardness in my implementation i find > is the > >> [*-1]->[moses 0] > >> , which one could simply replace by [moses -1] > (supposed we > >> don't care > >> about values between -1 and 0) (or with a > >> [<=0]->[select 1] which i > >> didn't do for conceptual reasons) > >> > >> fgmasdr > >> IOhannes > >> > >> -Inline Attachment Follows- > >> > >> ___ > >> Pd-list@iem.at > >> mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > > > > > > > > > > ___ > > Pd-list@iem.at > mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > random-number.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
Well maybe there is a Python object? If it has a neat and clean implementations would be brilliant. 2010/9/22 Bernardo Barros : > the only solution I see to write this kind of things in Max-like > languages is to allow the user to just open a text-box and write what > he/she wants in python or supercollider :-) that's for control > structures, loops, etc > > 2010/9/22 Jonathan Wilkes : >> >> >> --- On Wed, 9/22/10, IOhannes m zmoelnig wrote: >> >>> From: IOhannes m zmoelnig >>> Subject: Re: [PD] jMax Phoenix >>> To: pd-list@iem.at >>> Date: Wednesday, September 22, 2010, 6:36 PM >>> On 2010-09-22 16:48, Jonathan Wilkes >>> wrote: >>> > >>> > >>> > expr if(bx<=20, if (py<=by && >>> py+60>=by, 0, 1), -1); >>> > if (bx>=415, 2, -1); >>> > if (by<=0, 4, if (by>=500, 5, -1)) >>> > >>> >>> honestly i find this hard to read as well, esp. compared to >>> traditional >>> C-like syntax: >>> >>> if(bx<=20) >>> if(py<=by && py+60>=by) >>> return 0; >>> else >>> return 1; >>> if(by>=415) >>> return 2; >>> else >>> return -1; >>> if(by<=0) >>> return 4; >>> else if (by>=500) >>> return 5; >> >> Yes, Max/MSP's [if] object has a more readable syntax. Yet even >> with the two nested "ifs" I find it easier to read than your >> implementation because I don't have to look up to the inlet to >> remind myself which list elements correspond to which variable. >> >> I could put comments closer to each object chain, but then that's >> even more objects. >> >>> >>> >>> and as a matter of fact, i don't think the >>> pd-implementation of the >>> algorithm is so bad. >> >> Yes, IMO the way you implemented it is nice because there are >> very few wires crossing over objects. >> >> I'd also mention I find it more difficult to patch your >> implementation because there are 25 objects (not including the >> number boxes), 16 of which correspond to the args of [expr] in >> my implementation. That's 16 objects for which I have to change >> modes between the mouse (for connections) and the keyboard (for >> text). >> >> With [expr] I find it conceptually easier (and more ergonomic) to >> set up my [v] objects, my [sel], and my [outlet], then code the >> entire algorithm inside one box. >> >> Btw- you can get rid of 3 overlapping wires if you put [value py] >> closest to [unpack 0 0 0] and cascade them that way. >> >> -Jonathan >> >>> the only awkwardness in my implementation i find is the >>> [*-1]->[moses 0] >>> , which one could simply replace by [moses -1] (supposed we >>> don't care >>> about values between -1 and 0) (or with a >>> [<=0]->[select 1] which i >>> didn't do for conceptual reasons) >>> >>> fgmasdr >>> IOhannes >>> >>> -Inline Attachment Follows- >>> >>> ___ >>> Pd-list@iem.at >>> mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >> >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
the only solution I see to write this kind of things in Max-like languages is to allow the user to just open a text-box and write what he/she wants in python or supercollider :-) that's for control structures, loops, etc 2010/9/22 Jonathan Wilkes : > > > --- On Wed, 9/22/10, IOhannes m zmoelnig wrote: > >> From: IOhannes m zmoelnig >> Subject: Re: [PD] jMax Phoenix >> To: pd-list@iem.at >> Date: Wednesday, September 22, 2010, 6:36 PM >> On 2010-09-22 16:48, Jonathan Wilkes >> wrote: >> > >> > >> > expr if(bx<=20, if (py<=by && >> py+60>=by, 0, 1), -1); >> > if (bx>=415, 2, -1); >> > if (by<=0, 4, if (by>=500, 5, -1)) >> > >> >> honestly i find this hard to read as well, esp. compared to >> traditional >> C-like syntax: >> >> if(bx<=20) >> if(py<=by && py+60>=by) >> return 0; >> else >> return 1; >> if(by>=415) >> return 2; >> else >> return -1; >> if(by<=0) >> return 4; >> else if (by>=500) >> return 5; > > Yes, Max/MSP's [if] object has a more readable syntax. Yet even > with the two nested "ifs" I find it easier to read than your > implementation because I don't have to look up to the inlet to > remind myself which list elements correspond to which variable. > > I could put comments closer to each object chain, but then that's > even more objects. > >> >> >> and as a matter of fact, i don't think the >> pd-implementation of the >> algorithm is so bad. > > Yes, IMO the way you implemented it is nice because there are > very few wires crossing over objects. > > I'd also mention I find it more difficult to patch your > implementation because there are 25 objects (not including the > number boxes), 16 of which correspond to the args of [expr] in > my implementation. That's 16 objects for which I have to change > modes between the mouse (for connections) and the keyboard (for > text). > > With [expr] I find it conceptually easier (and more ergonomic) to > set up my [v] objects, my [sel], and my [outlet], then code the > entire algorithm inside one box. > > Btw- you can get rid of 3 overlapping wires if you put [value py] > closest to [unpack 0 0 0] and cascade them that way. > > -Jonathan > >> the only awkwardness in my implementation i find is the >> [*-1]->[moses 0] >> , which one could simply replace by [moses -1] (supposed we >> don't care >> about values between -1 and 0) (or with a >> [<=0]->[select 1] which i >> didn't do for conceptual reasons) >> >> fgmasdr >> IOhannes >> >> -Inline Attachment Follows- >> >> ___ >> Pd-list@iem.at >> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Wed, 22 Sep 2010, Jonathan Wilkes wrote: --- On Wed, 9/22/10, Mathieu Bouchard wrote: Btw I started coding [#expr] last week... but I think that it will take a long time to finish coding it. Great! * [#expr 3 / 2] ? At this point 1.5, and I think I will keep it that way, unless I require everything to default to being a grid. I wondered whether I ought to split between a float-centric version called [gf/expr] and a grid-centric version called [#expr], or have everything together in the same version. At this point, though, I only have plain floats. GridFlow's grids default to int32 (This is because this is the int type in jMax. It's also the int type in Max and others except Pd) * [#expr if $f1 < 3 then $f1 goes to the left outlet else $f1 goes to the right outlet] ? I don't know how this would work. In [expr], the number of outlets depends on the number of semicolon-separated expressions, and each triggering of [expr] causes them to be evaluated right-to-left. There's no syntax for not outputting on an outlet. What do you suggest ? * [#expr $0-array[$f1] ] ? I suppose so, but we're far from that. At this point, [#expr 1000-100-10-1] = 909, and I'm trying to make it so that it's 889. It's because (1000-(100-(10-(1 = 909 and 1000)-100)-10)-1) = 889. The only supported method is bang and even $f1 doesn't even exist yet. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Wed, 9/22/10, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] jMax Phoenix > To: "Jonathan Wilkes" > Cc: "Hans-Christoph Steiner" , pd-list@iem.at > Date: Wednesday, September 22, 2010, 6:09 PM > On Wed, 22 Sep 2010, Jonathan Wilkes > wrote: > > > The point is the [expr] object supplies a way to do > the kind of syntax under discussion, and in certain cases it > seems necessary to avoid the Max paradigm cliche of > spaghetti/spider webs. At least that's my position-- > > Btw I started coding [#expr] last week... but I think that > it will take a long time to finish coding it. Great! * [#expr 3 / 2] ? * [#expr if $f1 < 3 then $f1 goes to the left outlet else $f1 goes to the right outlet] ? * [#expr $0-array[$f1] ] ? * [#expr $inbox - $spam] ? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Wed, 9/22/10, IOhannes m zmoelnig wrote: > From: IOhannes m zmoelnig > Subject: Re: [PD] jMax Phoenix > To: pd-list@iem.at > Date: Wednesday, September 22, 2010, 6:36 PM > On 2010-09-22 16:48, Jonathan Wilkes > wrote: > > > > > > expr if(bx<=20, if (py<=by && > py+60>=by, 0, 1), -1); > > if (bx>=415, 2, -1); > > if (by<=0, 4, if (by>=500, 5, -1)) > > > > honestly i find this hard to read as well, esp. compared to > traditional > C-like syntax: > > if(bx<=20) > if(py<=by && py+60>=by) > return 0; > else > return 1; > if(by>=415) > return 2; > else > return -1; > if(by<=0) > return 4; > else if (by>=500) > return 5; Yes, Max/MSP's [if] object has a more readable syntax. Yet even with the two nested "ifs" I find it easier to read than your implementation because I don't have to look up to the inlet to remind myself which list elements correspond to which variable. I could put comments closer to each object chain, but then that's even more objects. > > > and as a matter of fact, i don't think the > pd-implementation of the > algorithm is so bad. Yes, IMO the way you implemented it is nice because there are very few wires crossing over objects. I'd also mention I find it more difficult to patch your implementation because there are 25 objects (not including the number boxes), 16 of which correspond to the args of [expr] in my implementation. That's 16 objects for which I have to change modes between the mouse (for connections) and the keyboard (for text). With [expr] I find it conceptually easier (and more ergonomic) to set up my [v] objects, my [sel], and my [outlet], then code the entire algorithm inside one box. Btw- you can get rid of 3 overlapping wires if you put [value py] closest to [unpack 0 0 0] and cascade them that way. -Jonathan > the only awkwardness in my implementation i find is the > [*-1]->[moses 0] > , which one could simply replace by [moses -1] (supposed we > don't care > about values between -1 and 0) (or with a > [<=0]->[select 1] which i > didn't do for conceptual reasons) > > fgmasdr > IOhannes > > -Inline Attachment Follows- > > ___ > Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Wed, 22 Sep 2010, Maurizio De Cecco wrote: By the way, jMax expressions are *compile* time expression (actually, load time expression), not objects like expr (that exists in jMax, coming straight from the ISPW). It is just a way to parametrise an abstraction/patch wrt its arguments. Well, I was comparing to [expr] because the jMax expressions also exist in messageboxes, where they behave more like [expr]. Pd is not the end of history for the MAX language, That's not what I mean, what I mean is that it's more worthwhile to fork Pd than to fork (or revive) jMax. there is still a lot that can be done at the core level. jMax Phoenix is a kind of research project; for now, i am trying to make it usable; later, to provide strong reasons for using it, at least in some specific field or projects. I think that some of those "core" features could become Pd externals (albeit rather unusual ones). ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On 2010-09-22 16:48, Jonathan Wilkes wrote: > > > expr if(bx<=20, if (py<=by && py+60>=by, 0, 1), -1); > if (bx>=415, 2, -1); > if (by<=0, 4, if (by>=500, 5, -1)) > honestly i find this hard to read as well, esp. compared to traditional C-like syntax: if(bx<=20) if(py<=by && py+60>=by) return 0; else return 1; if(by>=415) return 2; else return -1; if(by<=0) return 4; else if (by>=500) return 5; and as a matter of fact, i don't think the pd-implementation of the algorithm is so bad. the only awkwardness in my implementation i find is the [*-1]->[moses 0] , which one could simply replace by [moses -1] (supposed we don't care about values between -1 and 0) (or with a [<=0]->[select 1] which i didn't do for conceptual reasons) fgmasdr IOhannes #N canvas 358 123 819 607 10; #X obj 450 138 expr if(bx<=20 \, if (py<=by && py+60>=by \, 0 \, 1) \, -1) \; if (bx>=415 \, 2 \, -1) \; if (by<=0 \, 4 \, if (by>=500 \, 5 \, -1)); #X floatatom 460 183 5 0 0 0 - - -; #X floatatom 604 186 5 0 0 0 - - -; #X floatatom 759 184 5 0 0 0 - - -; #X obj 503 75 value bx; #X obj 537 95 value by; #X obj 572 115 value py; #X obj 450 33 t b l; #X obj 205 192 moses 415; #X msg 256 213 2; #X obj 256 234 t f; #X floatatom 266 255 5 0 0 0 - - -; #X obj 312 195 moses 500; #X msg 383 257 5; #X obj 312 216 * -1; #X obj 312 237 moses 0; #X obj 351 279 t f; #X floatatom 357 300 5 0 0 0 - - -; #X obj 205 167 t f; #X obj 312 162 t f; #X obj 73 186 <= 20; #X obj 142 258 t f f; #X obj 73 -29 inlet bx by py; #X obj 503 55 unpack 0 0 0; #X obj 73 165 unpack 0 0 0; #X obj 169 277 + 60; #X obj 107 279 t f f; #X obj 107 321 *; #X obj 73 -8 t l l; #X obj 205 137 unpack 0 0 0; #X obj 73 112 t l l; #X msg 351 257 4; #X obj 107 342 == 0; #X obj 134 300 <=; #X obj 107 300 >=; #X obj 256 411 t f; #X floatatom 351 462 5 0 0 0 - - -; #X floatatom 73 409 5 0 0 0 - - -; #X obj 73 207 select 1; #X obj 351 480 t f; #X obj 351 501 outlet; #X obj 450 230 t f; #X obj 450 251 select -1; #X obj 73 366 f; #X obj 501 404 t f; #X floatatom 501 460 5 0 0 0 - - -; #X obj 501 478 t f; #X obj 501 499 outlet; #X connect 0 0 1 0; #X connect 0 0 41 0; #X connect 0 1 2 0; #X connect 0 1 41 0; #X connect 0 2 3 0; #X connect 0 2 41 0; #X connect 7 0 0 0; #X connect 7 1 23 0; #X connect 8 1 9 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 10 0 35 0; #X connect 12 0 14 0; #X connect 12 1 13 0; #X connect 13 0 16 0; #X connect 14 0 15 0; #X connect 15 1 31 0; #X connect 16 0 17 0; #X connect 16 0 35 0; #X connect 18 0 8 0; #X connect 19 0 12 0; #X connect 20 0 38 0; #X connect 21 0 34 1; #X connect 21 1 25 0; #X connect 22 0 28 0; #X connect 23 0 4 0; #X connect 23 1 5 0; #X connect 23 2 6 0; #X connect 24 0 20 0; #X connect 24 1 26 0; #X connect 24 2 21 0; #X connect 25 0 33 1; #X connect 26 0 34 0; #X connect 26 1 33 0; #X connect 27 0 32 0; #X connect 28 0 30 0; #X connect 28 1 7 0; #X connect 29 0 18 0; #X connect 29 1 19 0; #X connect 30 0 24 0; #X connect 30 1 29 0; #X connect 31 0 16 0; #X connect 32 0 43 1; #X connect 33 0 27 1; #X connect 34 0 27 0; #X connect 35 0 36 0; #X connect 36 0 39 0; #X connect 38 0 43 0; #X connect 39 0 40 0; #X connect 41 0 42 0; #X connect 42 1 44 0; #X connect 43 0 35 0; #X connect 43 0 37 0; #X connect 44 0 45 0; #X connect 45 0 46 0; #X connect 46 0 47 0; smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
>On Wed, 22 Sep 2010, Maurizio De Cecco wrote: > >> For the record, jMax Phoenix support the jMax 2.x API, not the 4; the >> APIs are extended wrt 2.x, but in a backward compatible way. > >Ah, that's good. What motivated you to go back to the 2.x API ? Well, the biggest motivation for working of jMax was my personal pleasure; essentially, jMax was one of most interesting software project i worked in. So, i simply forked from the day (more or less) i left Ircam, and started where i left over; essentially, from *my* code base :->, and that was jMax 2.x. For the rest about jMax 4; i really know nothing about it; it is true that in the jMax history the development team was not really bright in listening the needs of the users, but its seems that they got really crazy :->. By the way, jMax expressions are *compile* time expression (actually, load time expression), not objects like expr (that exists in jMax, coming straight from the ISPW). It is just a way to parametrise an abstraction/patch wrt its arguments. >> The point is not to be competitive with pd, is more matter to see things >> going on, and produce new ideas and system that may have their role and >> use. > >If it can't compete with Pd, then it can't be very relevant. > >jMax has its upsides, but people will use Pd anyway, because Pd has more >upsides. Pd is not the end of history for the MAX language, there is still a lot that can be done at the core level. jMax Phoenix is a kind of research project; for now, i am trying to make it usable; later, to provide strong reasons for using it, at least in some specific field or projects. Maurizio ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Wed, 22 Sep 2010, Jonathan Wilkes wrote: The point is the [expr] object supplies a way to do the kind of syntax under discussion, and in certain cases it seems necessary to avoid the Max paradigm cliche of spaghetti/spider webs. At least that's my position-- Btw I started coding [#expr] last week... but I think that it will take a long time to finish coding it. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Wed, 22 Sep 2010, Maurizio De Cecco wrote: For the record, jMax Phoenix support the jMax 2.x API, not the 4; the APIs are extended wrt 2.x, but in a backward compatible way. Ah, that's good. What motivated you to go back to the 2.x API ? I would call it a bug (even fatal), no a showstopper; ok, a fatal bug *is* a showstopper if there is nobody able to fix it :->, or anybody there to listen to complaints, but now there is. The syntax has changed such that [myclass + 42] is a syntax error caused by a new feature, so it doesn't look very fixable. I needed to pass the plus-sign as $1, and 42 as $2. I didn't want to go through all my patches changing + to "add" and * to "mul" (etc) and I didn't want to have to use it like that, especially while Pd allowed me to keep the same syntax... In the end, for me, the transition from jMax2 to Pd was smoother than from jMax2 to jMax4. But it doesn't matter to me now, as my code doesn't support jMax since 2004 or 2005, ... it's all far behind now. For example, using the new paradigm there would be *no* need of something equivalent to the pd '$0-foo'; In jMax4 all receive-symbols were local. Not only that's completely incompatible with jMax2, that's another feature removal because there was no way to have global receive-symbols. In the process, we probably throw away the baby with the bath water, wrt simplicity of the language. Simplicity of the language isn't completely necessary, and it often pays off to have complex syntax, but simple syntax pays off too, in different situations. Because of this, for example, Pd has [expr], and Tcl has [expr] too. Both cases are remarkably similar because the [expr] of each language is there to complement a simple syntax language with a complex syntax component. The point is not to be competitive with pd, is more matter to see things going on, and produce new ideas and system that may have their role and use. If it can't compete with Pd, then it can't be very relevant. jMax has its upsides, but people will use Pd anyway, because Pd has more upsides. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
--- On Wed, 9/22/10, Hans-Christoph Steiner wrote: > From: Hans-Christoph Steiner > Subject: Re: [PD] jMax Phoenix > To: "Mathieu Bouchard" > Cc: pd-list@iem.at > Date: Wednesday, September 22, 2010, 8:01 AM > > On Sep 21, 2010, at 6:36 PM, Mathieu Bouchard wrote: > > > On Tue, 21 Sep 2010, Maurizio De Cecco wrote: > > > >> Given the fact that jMax slept a few years, it > cannot compete with puredata in terms of available > libraries, patches, and in general maturity of the > solution. > > > > No, it wasn't in this order : first it already > couldn't compete with PureData, AND THEN jMax 4 appeared, > which finished killing it, as the API was all different and > no-one bothered porting externals to it (well, I tried, and > I had to give up because some features had been removed from > jMax). By the time the project was called dead, everybody > had already switched to Pd or was in the process of doing > so. > > > >> 6) The language: jMax support the use of > expressions in object definition, like in | int ( 10 + $foo) > | so that objects in abstractions can be parametrised with > respect to the arguments. > > > > I gave up jMax because this feature was introduced. > This is because it removed the possibility to pass an > arithmetic operator as an argument. It was a showstopper for > me. > > I agree for different reasons. This syntax does seem > overly complicated and takes away from one of the things I > like best about the Max paradigm: really simple syntax. > > .hc Here's a left-paddled pong engine using the [expr] object: expr if(bx<=20, if (py<=by && py+60>=by, 0, 1), -1); if (bx>=415, 2, -1); if (by<=0, 4, if (by>=500, 5, -1)) 0 = left paddle hit 1 = left paddle miss 2 = richochet off right wall 3 = die at right paddle (to be implemented) 4 = richochet off top 5 = richochet off bottom I've got three variables being used in the conditionals, all of which come from [value] objects. Also, I'm sending a bogus value -1 for the "else" clause that expr's if operator tries to force on me-- this keeps from having to nest an "if" two levels deep, which becomes hard to read. So at the end all I need is [sel 0 1 2 3 4 5] and everything is clear. The point is the [expr] object supplies a way to do the kind of syntax under discussion, and in certain cases it seems necessary to avoid the Max paradigm cliche of spaghetti/spider webs. At least that's my position-- if someone can patch my expr statement above without expr where a) objects don't overlap much and b) the patch is compact enough that it can be read at a glance, then I'm happy to be wrong. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
>>> Given the fact that jMax slept a few years, it cannot compete with >>> puredata in terms of available libraries, patches, and in general >>> maturity of the solution. >> >> No, it wasn't in this order : first it already couldn't compete with >> PureData, AND THEN jMax 4 appeared, which finished killing it, as >> the API was all different and no-one bothered porting externals to >> it (well, I tried, and I had to give up because some features had >> been removed from jMax). By the time the project was called dead, >> everybody had already switched to Pd or was in the process of doing >> so. Well, as i said, i left Ircam around the 2.x version, just before the public announce of the GPL version. I am not familiar with what happened after that, including the history of jMax 4, that i read on the WikiPedia :->. I know anyway that it was kind of sleepy; while under a GPL license it was never a community project, because driven by the internal Ircam needs, and even that wasn't very clear. For the record, jMax Phoenix support the jMax 2.x API, not the 4; the APIs are extended wrt 2.x, but in a backward compatible way. >>> 6) The language: jMax support the use of expressions in object >>> definition, like in | int ( 10 + $foo) | so that objects in >>> abstractions can be parametrised with respect to the arguments. >> >> I gave up jMax because this feature was introduced. This is because >> it removed the possibility to pass an arithmetic operator as an >> argument. It was a showstopper for me. I would call it a bug (even fatal), no a showstopper; ok, a fatal bug *is* a showstopper if there is nobody able to fix it :->, or anybody there to listen to complaints, but now there is. >I agree for different reasons. This syntax does seem overly >complicated and takes away from one of the things I like best about >the Max paradigm: really simple syntax. Well, i have two different answers: the first is, yes, the syntax is overly complex: $args[1] instead of $1 make an object description unreadeable. There is another point: the syntax was built to complement a different paradigm for sharing data between objects; this paradigm was never exploited by a reasonable object set, so we are left with a syntax that would be adequate for objects using the new paradigm, but it is very heavy for objects not using the paradigm. For example, using the new paradigm there would be *no* need of something equivalent to the pd '$0-foo'; but since the new paradigm is not used by the object set, the $0 is still needed, but in the new syntax is a nightmare today (something like ( $__ + "foo" ) ), and just impossible at the time. On the other side, the complex syntax allows to do things that simpler syntax do not allows; the point is that simple things should be simple to do, and complex things may require more complex syntax; the syntax design failed to do this, but there is still room for improvement, if anyway want to discuss the subject and help the poor designer :->. Actually, the point of view taken by jMax is/was the following: the main customers where people, inside the organisation, spending one year or more designing a single library of abstractions for jMax. In this context, the ability to industrialise the development and having more expressive power to simplify these developments were essential. The goal was to make this abstractions easier to use, in terms of patch programming and in terms of logistic and infrastructure. In the process, we probably throw away the baby with the bath water, wrt simplicity of the language. I know, i was the guy implemented all this, with Norber Schnell doing the specifications. Now, all this is 10 years ago; i now works on jMax for fun, i am free to listen critics and to make the system evolve; i would be more than happy to discuss the subjects in more details (may be in private or elsewhere). The point is not to be competetitive with pd, is more matter to see things going on, and produce new ideas and system that may have their role and use. >> You too write "Max OS X" instead of "Mac OS X" ? Is this a virus you >> caught from Miller ? ;) Uh, so that is where it came from .. i was wondering :-> Maurizio De Cecco ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Sep 21, 2010, at 6:36 PM, Mathieu Bouchard wrote: On Tue, 21 Sep 2010, Maurizio De Cecco wrote: Given the fact that jMax slept a few years, it cannot compete with puredata in terms of available libraries, patches, and in general maturity of the solution. No, it wasn't in this order : first it already couldn't compete with PureData, AND THEN jMax 4 appeared, which finished killing it, as the API was all different and no-one bothered porting externals to it (well, I tried, and I had to give up because some features had been removed from jMax). By the time the project was called dead, everybody had already switched to Pd or was in the process of doing so. 6) The language: jMax support the use of expressions in object definition, like in | int ( 10 + $foo) | so that objects in abstractions can be parametrised with respect to the arguments. I gave up jMax because this feature was introduced. This is because it removed the possibility to pass an arithmetic operator as an argument. It was a showstopper for me. I agree for different reasons. This syntax does seem overly complicated and takes away from one of the things I like best about the Max paradigm: really simple syntax. .hc the 0.6 beta release; it does not mention the Max OS X version, that was not ready at the time. You too write "Max OS X" instead of "Mac OS X" ? Is this a virus you caught from Miller ? ;) ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
On Tue, 21 Sep 2010, Maurizio De Cecco wrote: Given the fact that jMax slept a few years, it cannot compete with puredata in terms of available libraries, patches, and in general maturity of the solution. No, it wasn't in this order : first it already couldn't compete with PureData, AND THEN jMax 4 appeared, which finished killing it, as the API was all different and no-one bothered porting externals to it (well, I tried, and I had to give up because some features had been removed from jMax). By the time the project was called dead, everybody had already switched to Pd or was in the process of doing so. 6) The language: jMax support the use of expressions in object definition, like in | int ( 10 + $foo) | so that objects in abstractions can be parametrised with respect to the arguments. I gave up jMax because this feature was introduced. This is because it removed the possibility to pass an arithmetic operator as an argument. It was a showstopper for me. the 0.6 beta release; it does not mention the Max OS X version, that was not ready at the time. You too write "Max OS X" instead of "Mac OS X" ? Is this a virus you caught from Miller ? ;) ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
Hi Maurizio Really interesting news- Im going to check it out- Iv always kept an eye on jmax and really glad to see it coming back ! On Tue, Sep 21, 2010 at 9:11 PM, Maurizio De Cecco wrote: > Hallo, > > my name is Maurizio De Cecco, and i am the maintainer and developper of the > jMax Phoenix project, > a kind of cousin of Puredata. Having release a new beta for jMax (on Linux > and Mac OS X), and after > discussing with Miller Puckette, i think the members of this list may be > interested in knowing more > about the project, and may be take a look. > > A bit of history: i worked in Ircam in the 90s, where i was lucky enough to > work with Miller Puckette > on Max/ISPW and following versions; i then worked on jMax, that was > intended to be a 'next generation' > Max for the Ircam projects; jMax was used in a few large productions; i > left in 99 for pursing other > interest (Linux Mandrake, at that time :), and forgot for a while about > jMax. > > In the meanwhile, jMax was put under a GPL licence, and after a couple of > years Ircam stopped its development > (don't ask me why, i wasn't there). > > In 2008 i was getting severely bored: server side Java, quality indicators > and software engineering was my daily bread, and no code to write; so, to > keep my developer mind healthy, i took up the development > of jMax, starting from the last release i worked on. > > Given the fact that jMax slept a few years, it cannot compete with puredata > in terms of available libraries, > patches, and in general maturity of the solution. > > But it have its own peculiarity, a number of different ideas, and having a > code base but no users (yet, i hope:) > allows some bold design decision to be taken; think of jMax Phoenix as a > kind of research project in same family where Puredata is. > > Describing the differences between jMax and Puredata would be long, because > it would need to go back > to the original developments; to be very synthetic i would resume in the > following: > > 1) Architecture: the jMax user interface run on a different process, and it > written in Java. > > 2) APIs are completely different, but see below. > > 3) The Object Set is reduced to the old ISPW object set; jMax can also > transparently include LADSPA plugins as objects; finally, i developped > compatibility layer (to be completed) that allows to recompile simple pd > objects for jMax, and possibly to load pd abstractions. > > 4) User Interface: there is a lot of work going on in the UI, that allows, > between other, the used of a single window IDE style interface. > > 5) Packaging and configuration: jMax Phoenix support the packaging > of complex libraries and applications in a single file, and even > automatically grab libraries from the internet. > > 6) The language: jMax support the use of expressions in object definition, > like in | int ( 10 + $foo) | so that objects in abstractions can be > parametrised with respect to the arguments. > > 7) Hopefully in between 6 month and a year: an optimising dsp compiler > and engine able to run a patch in parallel on multiple core (where multiple > means around 8). > > For anybody more interested, the project site is > http://www.jmax-phoenix.org/, and the > binaries and sources can be loaded from the project sourceforge site, > http://sourceforge.net/projects/jmax-phoenix/ > > For your information, i include at the end of the mail the formal announce > of the 0.6 beta release; it does not mention the Max OS X version, that was > not ready at the time. > > Maurizio > > - > > After many month of development, we are proud to announce the version 0.6 > beta of jMax Phoenix. > > The major highlights for this version are: > - A first version of the puredata source compatibility kit, including the > build system and a full example of recompiled object library. > - A large set of usability bug fixed; all the bugs preventing a smooth > work flow have been fixed. > - Error handling improvements: most of the bugs and configuration errors > now results in error messages, and not unexplained freezes. > - A set of examples and tutorials has been recovered from old ISPW > archives; they are not updated to include all the major jMax > functionalities, but it is better than nothing. > > Full release notes are available in the release notes section of the projet > site. > > This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian 5, > Fedora 13 and Mandriva Spring 2010; check the installation > instruction on the projet site for specific caveats for Debian and Fedora. > > The Puredata compatibility sub-project has been *very* time consuming; in > order to better manage my scarce time resources, > we need some user feedback (and possibly help) to be able to evaluate the > actual interest of pursuing this development direction. > > For more information and download and installation instructions go to > http://www.jmax-ph
[PD] jMax Phoenix
Hallo, my name is Maurizio De Cecco, and i am the maintainer and developper of the jMax Phoenix project, a kind of cousin of Puredata. Having release a new beta for jMax (on Linux and Mac OS X), and after discussing with Miller Puckette, i think the members of this list may be interested in knowing more about the project, and may be take a look. A bit of history: i worked in Ircam in the 90s, where i was lucky enough to work with Miller Puckette on Max/ISPW and following versions; i then worked on jMax, that was intended to be a 'next generation' Max for the Ircam projects; jMax was used in a few large productions; i left in 99 for pursing other interest (Linux Mandrake, at that time :), and forgot for a while about jMax. In the meanwhile, jMax was put under a GPL licence, and after a couple of years Ircam stopped its development (don't ask me why, i wasn't there). In 2008 i was getting severely bored: server side Java, quality indicators and software engineering was my daily bread, and no code to write; so, to keep my developer mind healthy, i took up the development of jMax, starting from the last release i worked on. Given the fact that jMax slept a few years, it cannot compete with puredata in terms of available libraries, patches, and in general maturity of the solution. But it have its own peculiarity, a number of different ideas, and having a code base but no users (yet, i hope:) allows some bold design decision to be taken; think of jMax Phoenix as a kind of research project in same family where Puredata is. Describing the differences between jMax and Puredata would be long, because it would need to go back to the original developments; to be very synthetic i would resume in the following: 1) Architecture: the jMax user interface run on a different process, and it written in Java. 2) APIs are completely different, but see below. 3) The Object Set is reduced to the old ISPW object set; jMax can also transparently include LADSPA plugins as objects; finally, i developped compatibility layer (to be completed) that allows to recompile simple pd objects for jMax, and possibly to load pd abstractions. 4) User Interface: there is a lot of work going on in the UI, that allows, between other, the used of a single window IDE style interface. 5) Packaging and configuration: jMax Phoenix support the packaging of complex libraries and applications in a single file, and even automatically grab libraries from the internet. 6) The language: jMax support the use of expressions in object definition, like in | int ( 10 + $foo) | so that objects in abstractions can be parametrised with respect to the arguments. 7) Hopefully in between 6 month and a year: an optimising dsp compiler and engine able to run a patch in parallel on multiple core (where multiple means around 8). For anybody more interested, the project site is http://www.jmax-phoenix.org/, and the binaries and sources can be loaded from the project sourceforge site, http://sourceforge.net/projects/jmax-phoenix/ For your information, i include at the end of the mail the formal announce of the 0.6 beta release; it does not mention the Max OS X version, that was not ready at the time. Maurizio - After many month of development, we are proud to announce the version 0.6 beta of jMax Phoenix. The major highlights for this version are: - A first version of the puredata source compatibility kit, including the build system and a full example of recompiled object library. - A large set of usability bug fixed; all the bugs preventing a smooth work flow have been fixed. - Error handling improvements: most of the bugs and configuration errors now results in error messages, and not unexplained freezes. - A set of examples and tutorials has been recovered from old ISPW archives; they are not updated to include all the major jMax functionalities, but it is better than nothing. Full release notes are available in the release notes section of the projet site. This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian 5, Fedora 13 and Mandriva Spring 2010; check the installation instruction on the projet site for specific caveats for Debian and Fedora. The Puredata compatibility sub-project has been *very* time consuming; in order to better manage my scarce time resources, we need some user feedback (and possibly help) to be able to evaluate the actual interest of pursuing this development direction. For more information and download and installation instructions go to http://www.jmax-phoenix.org/. For contacting the project team: cont...@jmax-phoenix.org The jMax Phoenix team __ Maurizio De Cecco - Music:http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/ ___ Pd-list@iem.at mai
