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:
- Architecture: the jMax user interface run on a different process, and
it written in Java.
APIs are completely different, but see below.
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.
- 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.
- 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.
- 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.
- 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: contact@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/
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 jmax@dececco.namewrote:
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:
- Architecture: the jMax user interface run on a different process, and it
written in Java.
APIs are completely different, but see below.
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.
- 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.
- 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.
- 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.
- 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: contact@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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
- 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
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.
- 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
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.
- 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
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
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
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 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:
- Know deeply the jMax code.
- 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
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).
- 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
--- On Wed, 9/22/10, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] jMax Phoenix To: "Mathieu Bouchard" matju@artengine.ca 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.
- 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
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
--- On Wed, 9/22/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@at.or.at, 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
On Wed, 22 Sep 2010, Jonathan Wilkes wrote:
--- On Wed, 9/22/10, Mathieu Bouchard matju@artengine.ca 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
--- On Wed, 9/22/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@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 matju@artengine.ca
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
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
--- On Thu, 9/23/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@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
On Thu, 23 Sep 2010, Jonathan Wilkes wrote:
--- On Thu, 9/23/10, Mathieu Bouchard matju@artengine.ca wrote:
I have a parser for + - * / & | ^ with correct operator precedence and left-associativity, and support for float literals and 0x hex literals. (nothing else yet)
Hey, that's great! I'll try it out as soon as I get a chance.
I also have added << >> < > <= >= == != % && ||. The last three are different from the ones in [expr] because they are what [#] supports.
I also added unary + - ! ~.
I also added the semicolon (multiple outlets).
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Fri, 9/24/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: [#expr] (was: jMax) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@artengine.ca Date: Friday, September 24, 2010, 6:29 PM On Thu, 23 Sep 2010, Jonathan Wilkes wrote:
--- On Thu, 9/23/10, Mathieu Bouchard matju@artengine.ca
wrote:
I have a parser for + - * / & | ^ with correct
operator
precedence and left-associativity, and support for
float
literals and 0x hex literals. (nothing else yet)
Hey, that's great! I'll try it out as soon as I
get a chance.
I also have added << >> < > <= >= == != % && ||. The last three are different from the ones in [expr] because they are what [#] supports.
I also added unary + - ! ~.
I also added the semicolon (multiple outlets).
Can there be semicolons in addition to some future mechanism for naming outlets? Or does that get too complex?
[#expr 0; 1] -> data output on two outlets. [#expr if 0 then 0 else out1 1] -> since there is "out1" an additional outlet is created, and data goes to outlet1 but not outlet0. [#expr 2; if 0 then 3 else out0 1] -> two outlets, but when the rightmost expression is evaluated the output is redirected to the first inlet.
I'm just using the Max/MSP style but changing the outlet numbers to start from zero. I don't know many other programming languages so I'm not sure if there's a better word for "out1", "out2", etc.
-Jonathan
On Fri, 24 Sep 2010, Jonathan Wilkes wrote:
Can there be semicolons in addition to some future mechanism for naming outlets? Or does that get too complex?
I think that [#expr] could be split into several classes for that kind of thing. [#expr] would work most closely like [expr], whereas an [if] or [#if] class could work like what you say.
I think that the right-to-left output of [#expr] is important and should be kept as-is. In Pd, either classes behave exactly like that, or they do something completely different (where only a portion of the outlets are used at a time, usually just one); I don't think that there is any class that uses both of those "modes" at once.
btw I just got $f1 $f2 $f3 etc into [#expr].
I just tested [#expr $f4+($f5-$f4)*($f1-$f2)/($f3-$f2)] and it works.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Fri, 9/24/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [#expr] (was: jMax) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@artengine.ca Date: Friday, September 24, 2010, 7:31 PM On Fri, 24 Sep 2010, Jonathan Wilkes wrote:
Can there be semicolons in addition to some future
mechanism for naming outlets? Or does that get too complex?
I think that [#expr] could be split into several classes for that kind of thing. [#expr] would work most closely like [expr], whereas an [if] or [#if] class could work like what you say.
I think that the right-to-left output of [#expr] is important and should be kept as-is. In Pd, either classes behave exactly like that, or they do something completely different (where only a portion of the outlets are used at a time, usually just one); I don't think that there is any class that uses both of those "modes" at once.
That's a really good point, and I think you're right that it is this kind of "if" behavior really belongs in a different object.
btw I just got $f1 $f2 $f3 etc into [#expr].
I just tested [#expr $f4+($f5-$f4)*($f1-$f2)/($f3-$f2)] and it works.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Fri, 24 Sep 2010, Jonathan Wilkes wrote:
That's a really good point, and I think you're right that it is this kind of "if" behavior really belongs in a different object.
btw i just added sin() cos() exp() log() tanh() sqrt() abs() rand().
Now I would like to know, when you write something like [expr a*b+c], how would you make those variables local. For example, if you have :
[v $0-a] [v $0-b] [v $0-c]
How do you write an [expr] formula that uses those three variables. Now, if there's no way to support that in [expr], how would I add support for that in [#expr] ?
If they are going to work only with global variables, i'm not really interested in those, because I can't use [expr a*b+c] in an abstraction without causing a conflict of variables when instantiated more than once (and perhaps even when instantiated just once !).
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Fri, 9/24/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [#expr] (was: jMax) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@artengine.ca Date: Friday, September 24, 2010, 10:11 PM On Fri, 24 Sep 2010, Jonathan Wilkes wrote:
That's a really good point, and I think you're right
that it is this kind of "if" behavior really belongs in a different object.
btw i just added sin() cos() exp() log() tanh() sqrt() abs() rand().
Now I would like to know, when you write something like [expr a*b+c], how would you make those variables local. For example, if you have :
[v $0-a] [v $0-b] [v $0-c]
How do you write an [expr] formula that uses those three variables. Now, if there's no way to support that in [expr], how would I add support for that in [#expr] ?
It's a little ugly:
[expr _$0_a]
[v _$0_a]
[expr _$0.a] seems to fail, and of course [expr _$0-a] won't do what you want.
But my hack seems only to work because $0 is guaranteed to exist. With $1 or greater if you're not inside an abstraction with that arg, [v _$1_a] will create but [expr _$1_a] will not.
-Jonathan
If they are going to work only with global variables, i'm not really interested in those, because I can't use [expr a*b+c] in an abstraction without causing a conflict of variables when instantiated more than once (and perhaps even when instantiated just once !).
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Fri, 24 Sep 2010, Jonathan Wilkes wrote:
btw i just added sin() cos() exp() log() tanh() sqrt() abs() rand().
I just added min() max() div() rem() cmp() hypot() atan2() avg() c2p() p2c().
It's a little ugly: [expr _$0_a] [v _$0_a]
yikes. actually, I'd rather write 'a' and have it mean '$0-a'. However, I can't put that '$0-' prefix as an attribute of [#expr] because :
comma-messages only are sent after the constructor processes the arguments
comma-messages are disabled for [#expr] anyway, using the new CLASS_NOCOMMA option, because comma already means something in [#expr] (for the two-argument function support that I have just added)
And then I'd rather not write things like [#expr -local $0- a-b] because that's three meanings of "-" in the same box. ;) I mean something like a commandline switch that would set "$0-" as the prefix of all following variables.
[expr _$0.a] seems to fail, and of course [expr _$0-a] won't do what you want.
I suppose only /[_A-Za-z][_A-Za-z0-9]*/ are accepted in symbols, just like C syntax.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Sat, 9/25/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [#expr] (was: jMax) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@artengine.ca Date: Saturday, September 25, 2010, 5:30 AM On Fri, 24 Sep 2010, Jonathan Wilkes wrote:
btw i just added sin() cos() exp() log() tanh()
sqrt()
abs() rand().
I just added min() max() div() rem() cmp() hypot() atan2() avg() c2p() p2c().
It's a little ugly: [expr _$0_a] [v _$0_a]
yikes. actually, I'd rather write 'a' and have it mean '$0-a'. However, I can't put that '$0-' prefix as an attribute of [#expr] because :
1. comma-messages only are sent after the constructor processes the arguments
2. comma-messages are disabled for [#expr] anyway, using the new CLASS_NOCOMMA option, because comma already means something in [#expr] (for the two-argument function support that I have just added)
And then I'd rather not write things like [#expr -local $0- a-b] because that's three meanings of "-" in the same box. ;) I mean something like a commandline switch that would set "$0-" as the prefix of all following variables.
[expr _$0.a] seems to fail, and of course [expr _$0-a]
won't do what you want.
I suppose only /[_A-Za-z][_A-Za-z0-9]*/ are accepted in symbols, just like C syntax.
Hm, [expr a$0] works.
-Jonathan
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Sat, 25 Sep 2010, Jonathan Wilkes wrote:
Hm, [expr a$0] works.
Yeah, but I'd use $0-a everywhere else. I'd like to be able to write 'a' for '$0-a', and I know that there isn't a standard for local-variables in Pd, but I'd like to pretend that there is one, and if I have to write a$0, there isn't one. Furthermore, when I write a$0, I'm probably trying to write a complicated formula and thus I'd rather not have $0 in my face. I want to write 'a' for local variables, and if ever I want a global variable, I wouldn't mind writing '::a' for it, because local is the most common case by far.
So, how do you suggest that we do that ?
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Sat, 9/25/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [#expr] (was: jMax) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@artengine.ca Date: Saturday, September 25, 2010, 3:07 PM On Sat, 25 Sep 2010, Jonathan Wilkes wrote:
Hm, [expr a$0] works.
Yeah, but I'd use $0-a everywhere else. I'd like to be able to write 'a' for '$0-a', and I know that there isn't a standard for local-variables in Pd, but I'd like to pretend that there is one, and if I have to write a$0, there isn't one. Furthermore, when I write a$0, I'm probably trying to write a complicated formula and thus I'd rather not have $0 in my face. I want to write 'a' for local variables, and if ever I want a global variable, I wouldn't mind writing '::a' for it, because local is the most common case by far.
So, how do you suggest that we do that ?
Seems like this is a bigger problem, because most of the time when I use send/receive, IEMGUIs, or [value] in an [expr]-less context I am also using $0-foo as the most common case.
So I think your reasoning for not wanting $0 "in your face" in
a complex formula also extends quite naturally to Pd in general.
Anytime I use [s $0-a] I'd rather write [s a] and have it be
local by default.
-Jonathan
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Sat, 9/25/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [#expr] (was: jMax) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@artengine.ca Date: Saturday, September 25, 2010, 5:30 AM On Fri, 24 Sep 2010, Jonathan Wilkes wrote:
btw i just added sin() cos() exp() log() tanh()
sqrt()
abs() rand().
For some reason, [expr] has random, which takes two arguments, but no rand.
I noticed that [#expr] (i.e., with no args) doesn't create.
If I do [#expr max(1,3)] and send a float to the inlet it crashes Pd. (Same with other functions)
What are rem, cmp, c2p and p2c?
I just added min() max() div() rem() cmp() hypot() atan2() avg() c2p() p2c().
It's a little ugly: [expr _$0_a] [v _$0_a]
yikes. actually, I'd rather write 'a' and have it mean '$0-a'. However, I can't put that '$0-' prefix as an attribute of [#expr] because :
1. comma-messages only are sent after the constructor processes the arguments
2. comma-messages are disabled for [#expr] anyway, using the new CLASS_NOCOMMA option, because comma already means something in [#expr] (for the two-argument function support that I have just added)
And then I'd rather not write things like [#expr -local $0- a-b] because that's three meanings of "-" in the same box. ;) I mean something like a commandline switch that would set "$0-" as the prefix of all following variables.
[expr _$0.a] seems to fail, and of course [expr _$0-a]
won't do what you want.
I suppose only /[_A-Za-z][_A-Za-z0-9]*/ are accepted in symbols, just like C syntax.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Sun, 26 Sep 2010, Jonathan Wilkes wrote:
For some reason, [expr] has random, which takes two arguments, but no rand.
That's because it's only based on functions that are already in GridFlow, and there is no such random() in GridFlow. I already fudged quite a few things in [#expr] though, so I might be able to fudge this one. At this point, the only ops I can import directly into [#expr] are the ones that already exist in [#]. Maybe it's just easier to add 'random' to [#].
I noticed that [#expr] (i.e., with no args) doesn't create.
With the current grammar used by [#expr], empty expression doesn't parse. So I just set the expression "0" as the default args of [expr] when there are no args at all.
If I do [#expr max(1,3)] and send a float to the inlet it crashes Pd. (Same with other functions)
[#expr] without any $f1-style variables has an empty 'inputs' array but try to assign to inputs[0] anyway.
What are rem, cmp
'rem' is [expr $f1 % $f2] 'cmp' is [expr $f1<0 ? -1 : $f1>$f2]
c2p and p2c?
They never were in. It was a mistake. Those are 'vecops', which means that each of them take as inputs two pairs of numbers and output one pair. But [#expr] doesn't support grids yet, so, it didn't make any sense whatsoever to include them at this point.
Seems like this is a bigger problem, because most of the time when I use send/receive, IEMGUIs, or [value] in an [expr]-less context I am also using $0-foo as the most common case.
It sounds like "$0-" would make a good default prefix, then, especially with the number of people using it (though a few people use different conventions).
So I think your reasoning for not wanting $0 "in your face" in a complex formula also extends quite naturally to Pd in general. Anytime I use [s $0-a] I'd rather write [s a] and have it be local by default.
Yeah, but the way Pd is made, it's too late, we can't change this, or we have to change pd_bind and all the externals that use receive-symbols.
Then the only way out is to make individual solutions whenever "$0-" gets too annoying. For example, [receives] allows you to write something like [r $0-a] [r $0-b] [r $0-c] as [receives $0- a b c] which outputs symbol a or symbol b or symbol c by the right-outlet just before outputting the received message by the left-outlet.
see http://gridflow.ca/help/receives-help.png
I could be making more classes like that if you want.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Sun, 9/26/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [#expr] (was: jMax) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, gridflow-dev@artengine.ca Date: Sunday, September 26, 2010, 10:21 PM On Sun, 26 Sep 2010, Jonathan Wilkes wrote:
For some reason, [expr] has random, which takes two
arguments, but no rand.
That's because it's only based on functions that are already in GridFlow, and there is no such random() in GridFlow. I already fudged quite a few things in [#expr] though, so I might be able to fudge this one. At this point, the only ops I can import directly into [#expr] are the ones that already exist in [#]. Maybe it's just easier to add 'random' to [#].
I noticed that [#expr] (i.e., with no args) doesn't
create.
With the current grammar used by [#expr], empty expression doesn't parse. So I just set the expression "0" as the default args of [expr] when there are no args at all.
If I do [#expr max(1,3)] and send a float to the inlet
it crashes Pd. (Same with other functions)
[#expr] without any $f1-style variables has an empty 'inputs' array but try to assign to inputs[0] anyway.
What are rem, cmp
'rem' is [expr $f1 % $f2] 'cmp' is [expr $f1<0 ? -1 : $f1>$f2]
c2p and p2c?
They never were in. It was a mistake. Those are 'vecops', which means that each of them take as inputs two pairs of numbers and output one pair. But [#expr] doesn't support grids yet, so, it didn't make any sense whatsoever to include them at this point.
Seems like this is a bigger problem, because most of
the time when I use send/receive, IEMGUIs, or [value] in an [expr]-less context I am also using $0-foo as the most common case.
It sounds like "$0-" would make a good default prefix, then, especially with the number of people using it (though a few people use different conventions).
So I think your reasoning for not wanting $0 "in your
face" in a complex formula also extends quite naturally to Pd in general. Anytime I use [s $0-a] I'd rather write [s a] and have it be local by default.
Yeah, but the way Pd is made, it's too late, we can't change this, or we have to change pd_bind and all the externals that use receive-symbols.
Then the only way out is to make individual solutions whenever "$0-" gets too annoying. For example, [receives] allows you to write something like [r $0-a] [r $0-b] [r $0-c] as [receives $0- a b c] which outputs symbol a or symbol b or symbol c by the right-outlet just before outputting the received message by the left-outlet.
Thanks, I'll have a look at that.
I could be making more classes like that if you want.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
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
--- On Wed, 9/22/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at 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
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 jancsika@yahoo.com:
--- On Wed, 9/22/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at 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
Well maybe there is a Python object? If it has a neat and clean implementations would be brilliant.
2010/9/22 Bernardo Barros bernardobarros2@gmail.com:
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 jancsika@yahoo.com:
--- On Wed, 9/22/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at 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
On 2010-09-22 20:58, Bernardo Barros wrote:
Well maybe there is a Python object? If it has a neat and clean implementations would be brilliant.
i guess you are not really aware that there _is_ a python object? and bindings to all other kinds of languages, like lua,...
2010/9/22 Bernardo Barros bernardobarros2@gmail.com:
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
if this is the only solution you see then you might really have some problems with the way Pd works :-)
however, despite my brilliant defense of the Pd language, i would like to point out that there are indeed a lot of control-flow things that you cannot solve easily within a patcher language. some of them will probably always become unreadable spaghetti.
that's why my second language is C/C++ (which i find much mor readable and esp. writeable than python)
hmad IOhannes
At one point Jmax was going to be revived as pymax- with a python front end
On Thu, Sep 23, 2010 at 8:28 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
On 2010-09-22 20:58, Bernardo Barros wrote:
Well maybe there is a Python object? If it has a neat and clean implementations would be brilliant.
i guess you are not really aware that there _is_ a python object? and bindings to all other kinds of languages, like lua,...
2010/9/22 Bernardo Barros bernardobarros2@gmail.com:
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
if this is the only solution you see then you might really have some problems with the way Pd works :-)
however, despite my brilliant defense of the Pd language, i would like to point out that there are indeed a lot of control-flow things that you cannot solve easily within a patcher language. some of them will probably always become unreadable spaghetti.
that's why my second language is C/C++ (which i find much mor readable and esp. writeable than python)
hmad IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 23 Sep 2010, ALAN BROOKER wrote:
At one point Jmax was going to be revived as pymax- with a python front end
No, this was announced well before jMax was declared dead. I think that it was in the early days of jMax 4 bêta. It was being proposed as an alternative offered in parallel to the java gui of jMax at a time when there was still development going on at IRCAM.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
Yes, I see there is a py object now. thanks
2010/9/23 IOhannes m zmoelnig zmoelnig@iem.at:
On 2010-09-22 20:58, Bernardo Barros wrote:
Well maybe there is a Python object? If it has a neat and clean implementations would be brilliant.
i guess you are not really aware that there _is_ a python object? and bindings to all other kinds of languages, like lua,...
2010/9/22 Bernardo Barros bernardobarros2@gmail.com:
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
if this is the only solution you see then you might really have some problems with the way Pd works :-)
however, despite my brilliant defense of the Pd language, i would like to point out that there are indeed a lot of control-flow things that you cannot solve easily within a patcher language. some of them will probably always become unreadable spaghetti.
that's why my second language is C/C++ (which i find much mor readable and esp. writeable than python)
hmad IOhannes
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 <condition>, <then>, <else>". 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.
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
--- On Thu, 9/23/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at 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 <condition>, <then>, <else>". 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 <shift-arrow>, 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
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 <shift-arrow>, 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
--- On Thu, 9/23/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com 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
<shift-arrow>, 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
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
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 zmoelnig@iem.at:
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
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
--- On Mon, 10/4/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, 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 <ctrl-Enter> 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
On Mon, 4 Oct 2010, Jonathan Wilkes wrote:
I do remember that in Desiredata you have to actually create the object with <ctrl-Enter> 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
--- On Tue, 10/5/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, 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 <ctrl-Enter> 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 <ctrl-Enter> 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
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
--- On Fri, 10/8/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] jMax Phoenix To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, 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
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
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 <condition>, <then>, <else>". 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
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 matju@artengine.ca:
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 <condition>, <then>, <else>". 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
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
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 jmax@dececco.namewrote:
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:
- Architecture: the jMax user interface run on a different process, and it
written in Java.
APIs are completely different, but see below.
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.
- 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.
- 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.
- 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.
- 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: contact@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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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:
- Architecture: the jMax user interface run on a different process,
and it written in Java.
APIs are completely different, but see below.
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.
- 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.
- 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.
- 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.
- 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: contact@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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 ydegoyon@gmail.com ydegoyon@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:
- Architecture: the jMax user interface run on a different process, and
it written in Java.
APIs are completely different, but see below.
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.
- 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.
- 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.
- 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.
- 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: contact@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 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
-
ALAN BROOKER -
Bernardo Barros -
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Jonathan Wilkes -
Mathieu Bouchard -
Maurizio De Cecco -
ydegoyon＠gmail.com