More readable? Hah. That has to be some kind of crazy joke, good one Olaf. ;)
You don't happen to have that patch available do you? I like being able to hold down shift and have the option. I remember a while back there was IMPD somewhere on the net that had some screens of some traditional and wacky segments in action. Never could find a binary or the source for it. Oh well.
I think it would be a worthy cause to pursue, Olaf. They are very useful. Having no segmented patch chords is keeping me stuck in Windows using Max and with all these new distros floating around I really want to make the switch at some point.
there was IMPD somewhere on the net that had some screens of some traditional and wacky segments in action. Never could find a binary or the source for it. Oh well.
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data co -r impd_0_37 pd
t
Hallo, James Aldridge hat gesagt: // James Aldridge wrote:
More readable? Hah. That has to be some kind of crazy joke, good one Olaf. ;)
Whatever Olaf wrote (I didn't get his mail): Not having segmented patchcord forces the user to be clearer and more orgaized in the layout of the *objects* inside - which is most of what Max/Pd is about. I know people who do not use segments in their Max patches. Personally, as a Pd only user, I have never missed segmented cords.
Anyway, having these as an option would be nice, but apart from imPd they haven't arrived yet.
Having no segmented patch chords is keeping me stuck in Windows using Max
Cool, you are easy to convince then! ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
Whatever Olaf wrote (I didn't get his mail): Not having segmented patchcord forces the user to be clearer and more orgaized in the layout of the *objects* inside - which is most of what Max/Pd is about. I know people who do not use segments in their Max patches. Personally, as a Pd only user, I have never missed segmented cords. Anyway, having these as an option would be nice, but apart from imPd they haven't arrived yet.
-Wasn't Miller talking sometime ago about this doing, but that IRCAM(!) objected to it (?), because it made PD more look like their jMax... Considering that jMax has been recently regarded as being deceased, it might justify another attempt.
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
On Sun, 6 Mar 2005, Arie van Schutterhoef wrote:
Personally, as a Pd only user, I have never missed segmented cords. Anyway, having these as an option would be nice, but apart from imPd they haven't arrived yet.
-Wasn't Miller talking sometime ago about this doing, but that IRCAM(!) objected to it (?), because it made PD more look like their jMax... Considering that jMax has been recently regarded as being deceased, it might justify another attempt.
there exists no version of jMax supporting segmented patchcords.
however it is true that jMax is very dead now.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
is jMax dead because the Java VM is too slow for DSP?
Mathieu Bouchard wrote:
On Sun, 6 Mar 2005, Arie van Schutterhoef wrote:
Personally, as a Pd only user, I have never missed segmented cords. Anyway, having these as an option would be nice, but apart from imPd they haven't arrived yet.
-Wasn't Miller talking sometime ago about this doing, but that IRCAM(!) objected to it (?), because it made PD more look like their jMax... Considering that jMax has been recently regarded as being deceased, it might justify another attempt.
there exists no version of jMax supporting segmented patchcords.
however it is true that jMax is very dead now.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, brendan asselstine hat gesagt: // brendan asselstine wrote:
is jMax dead because the Java VM is too slow for DSP?
Well, jMax is not really dead, but IRCAM dropped (direct) support for jMax officially some days ago and closed the jmax@ircam mailing list. jMax is still alive as a Sourceforge project. How alive? Only time will tell. The user base was never as big as that of Pd anyway, according to my impression.
Oh, and AFAIK Java is only used for the GUI part, not for the DSP part of jMax.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
The user base was never as big as that of Pd anyway,
-I think jMax was mainly used within IRCAM itself for productions and concert performances. Strangely enough their technical performance manuals all refer to Max/MSP. Iike in Jonathan Harvey's String Quartet N ° 4 with live electronics http://www.ircam.fr/fileadmin/sites/WWW_Ircam/fichiers/Cahiers_exploitation/... ey-SQ4_en.pdf
Java is only used for the GUI part,
-There are/have been attempts to add Python & C++versions as well for the clientside.
not for the DSP part of jMax.
-That's written in oldfashioned/decent C...
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
On Mon, 7 Mar 2005, Frank Barknecht wrote:
brendan asselstine hat gesagt: // brendan asselstine wrote:
is jMax dead because the Java VM is too slow for DSP?
Well, jMax is not really dead, but IRCAM dropped (direct) support for jMax officially some days ago and closed the jmax@ircam mailing list. jMax is still alive as a Sourceforge project. How alive? Only time will tell. The user base was never as big as that of Pd anyway, according to my impression.
My impression is that when I started lurking on the Pd list, which was in mid-2002, the Pd crowd was already many times bigger than the jMax crowd -- say twenty times, and possibly a lot more.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
My impression is that when I started lurking on the Pd list, which was in mid-2002, the Pd crowd was already many times bigger than the jMax crowd -- say twenty times, and possibly a lot more.
Which reminds of something related: How many Pd users do you all think there are?
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
don't know i'll start counting :
me :1
next?
On Thu, 10 Mar 2005 20:54:14 +0100, Frank Barknecht fbar@footils.org wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
My impression is that when I started lurking on the Pd list, which was in mid-2002, the Pd crowd was already many times bigger than the jMax crowd -- say twenty times, and possibly a lot more.
Which reminds of something related: How many Pd users do you all think there are?
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
That's the thing. I have personally met one other person that uses PD. Otherwise, I know of you guys only via the list.
Another interesting demographic question would be what are the national/gender makeups. Is there a single female that, say, has a developer's account on the CVS?
There was a discussion on Ars Technica a while back about the prevalence of men in programming. Somewhere in there came up the fact that during the internet boom autism rates in Silicon Valley went up 200%. Autism effects men more than women for some reason that no one can figure out. Also, the profile of asperger's syndrome (high-functioning autism) is the same profile of a geek: anti-social, amazing ability to focus on details no one else can see.
Anyway. I count 2 Pd users and a bunch of emails that may be generated by bots.
-Ian
Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
My impression is that when I started lurking on the Pd list, which was in mid-2002, the Pd crowd was already many times bigger than the jMax crowd -- say twenty times, and possibly a lot more.
Which reminds of something related: How many Pd users do you all think there are?
Ciao
Hi Ian and all,
Ian Smith-Heisters wrote:
Anyway. I count 2 Pd users and a bunch of emails that may be generated by bots.
I am definitely a bot.
And I have taught about 90-100 other bots at least the opening stages of using PD, although I'm not sure they count as "users" yet in many cases. I tend to gravitate towards other PD bots at festivals, workshops and hackmeetings in Europe quite frequently, and there must be at least 40 that I see semi-regularly...
Seems like the main difference in people's experiences meeting other users is whether or not they live in Europe. I don't think there's less PDers in the States, but they are much farther apart, and there's simply no interesting venues for new media art in the States [festivals and the like] so they never have a chance to meet each other.
d.
derek holzer wrote:
Seems like the main difference in people's experiences meeting other users is whether or not they live in Europe. I don't think there's less PDers in the States, but they are much farther apart, and there's simply no interesting venues for new media art in the States [festivals and the like] so they never have a chance to meet each other.
This is what it seems to me. The only regular venue for stuff like this I know of in the whole US is ShareNYC, but I've never seen another PDer there, though I heard H.C.Steiner has been around. Of course NYC is a long shot if you live on the west coast, wheras from what I hear about Europe, you can live in London and be in Berlin 20EUR and an hour later. Hmmmm... anyone know of any jobs for a programmer with a specialty in realtime media in Europe ;) ?
Europe has higher population density, plus I think there really are more PDers in Europe. IEM is there. IRCAM is there.
-ish
d.
The last PD class I taught at Interaccess (Toronto, Canada) was 50% female. This class was the first in a series on pd, gem, audio, electronics and microcontrollers.
On top of that of all the workshops I've taught there have always been about 30% women and more.
I don't know how many of my students keep up with PD...
b.
Ian Smith-Heisters wrote:
That's the thing. I have personally met one other person that uses PD. Otherwise, I know of you guys only via the list.
Another interesting demographic question would be what are the national/gender makeups. Is there a single female that, say, has a developer's account on the CVS?
There was a discussion on Ars Technica a while back about the prevalence of men in programming. Somewhere in there came up the fact that during the internet boom autism rates in Silicon Valley went up 200%. Autism effects men more than women for some reason that no one can figure out. Also, the profile of asperger's syndrome (high-functioning autism) is the same profile of a geek: anti-social, amazing ability to focus on details no one else can see.
Anyway. I count 2 Pd users and a bunch of emails that may be generated by bots.
-Ian
Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
My impression is that when I started lurking on the Pd list, which was in mid-2002, the Pd crowd was already many times bigger than the jMax crowd -- say twenty times, and possibly a lot more.
Which reminds of something related: How many Pd users do you all think there are? Ciao
Its good to see more women getting involved. But it remains a sad fact
that out 40+ Pd devs, almost all are white males. I was just
discussing this with my girlfriend ideas, it seems to be a pretty
amorphic issue. I read an interesting article about this problem
regarding free software development in general. It seems many women
don't want to be openly female in such forums because it often leads to
obnoxious and/or harassing emails. So many women choose gender-neutral
online identities to avoid this. Then there was another interesting
point about how free software development tends to be kind of a macho
realm, with people trying to one-up each other. Many women (and men as
well) find this quite annoying.
Just my two bits...
.hc
On Mar 14, 2005, at 12:23 PM, B. Bogart wrote:
The last PD class I taught at Interaccess (Toronto, Canada) was 50% female. This class was the first in a series on pd, gem, audio, electronics and microcontrollers.
On top of that of all the workshops I've taught there have always been about 30% women and more.
I don't know how many of my students keep up with PD...
b.
Ian Smith-Heisters wrote:
That's the thing. I have personally met one other person that uses PD. Otherwise, I know of you guys only via the list.
Another interesting demographic question would be what are the national/gender makeups. Is there a single female that, say, has a developer's account on the CVS?
There was a discussion on Ars Technica a while back about the
prevalence of men in programming. Somewhere in there came up the fact that during the internet boom autism rates in Silicon Valley went up 200%. Autism effects men more than women for some reason that no one can figure
out. Also, the profile of asperger's syndrome (high-functioning autism) is the same profile of a geek: anti-social, amazing ability to focus on details no one else can see.Anyway. I count 2 Pd users and a bunch of emails that may be generated by bots.
-Ian
Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
My impression is that when I started lurking on the Pd list, which was in mid-2002, the Pd crowd was already many times bigger than the jMax
crowd -- say twenty times, and possibly a lot more.Which reminds of something related: How many Pd users do you all think there are? Ciao
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos Williams
I know of a few women PD users but I've never met a female developer of PD externals. Actually there is a place in Montreal called studioXX (http://www.studioxx.org/) whose mandate is to increase the exposure of female artists to technology. I heard they are about to start a pure-data workshop there. (oh and look its own own MiS teaching it!)
I think the problem is the old problem of privilege as much as anything. It's not a problem specific to women, but all "minorities". Actually I was thinking that open-source should/could be a very interesting thing in context of first peoples communities. I think communities like these would be very ideologically connected to the open-source concept. (from my white western "priviliged" perspective anyhow) Imagine if there was an open source OS (and there may be) that was centered around the ideology of a non-western community, a true fusion of spirituality and creative computing.
Interaccess was involved in something called the "Container Project" (http://www.container.access-it.org.uk/) that basically got funding to plunk a shipping container / computer lab into rural areas, in our case Jamaica, and taught workshops and so on there. Strangely there was little exposure to open-source software. People learned how to do HTML on old os9 macs and on windows98. I wonder if there is such a thing in the western world for first peoples communities.
I think it is in all of our benefit that the diversity of contributers to open-source (and PD & Linux in particular) increase and reflect the diversity of our (global) community.
I've always felt a little strange about starting these things, since in most cases those with the knowledge (white men) end up teaching the "minorities" (maybe marginalized groups is a better term). I hope one day a woman will teach PD at studioXX !
Sorry for the blabbing, the topic just captured my imagination.
B.
PS: out of 1000 potential users, how many visual artists are there among us? maybe 50?
Hans-Christoph Steiner wrote:
Its good to see more women getting involved. But it remains a sad fact that out 40+ Pd devs, almost all are white males. I was just discussing this with my girlfriend ideas, it seems to be a pretty amorphic issue. I read an interesting article about this problem regarding free software development in general. It seems many women don't want to be openly female in such forums because it often leads to obnoxious and/or harassing emails. So many women choose gender-neutral online identities to avoid this. Then there was another interesting point about how free software development tends to be kind of a macho realm, with people trying to one-up each other. Many women (and men as well) find this quite annoying.
Just my two bits...
.hc
On Mar 14, 2005, at 12:23 PM, B. Bogart wrote:
The last PD class I taught at Interaccess (Toronto, Canada) was 50% female. This class was the first in a series on pd, gem, audio, electronics and microcontrollers.
On top of that of all the workshops I've taught there have always been about 30% women and more.
I don't know how many of my students keep up with PD...
b.
Ian Smith-Heisters wrote:
That's the thing. I have personally met one other person that uses PD. Otherwise, I know of you guys only via the list.
Another interesting demographic question would be what are the national/gender makeups. Is there a single female that, say, has a developer's account on the CVS?
There was a discussion on Ars Technica a while back about the prevalence of men in programming. Somewhere in there came up the fact that during the internet boom autism rates in Silicon Valley went up 200%. Autism effects men more than women for some reason that no one can figure out. Also, the profile of asperger's syndrome (high-functioning autism) is the same profile of a geek: anti-social, amazing ability to focus on details no one else can see.
Anyway. I count 2 Pd users and a bunch of emails that may be generated by bots.
-Ian
Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
My impression is that when I started lurking on the Pd list, which was in mid-2002, the Pd crowd was already many times bigger than the jMax crowd -- say twenty times, and possibly a lot more.
Which reminds of something related: How many Pd users do you all think there are? Ciao
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hi guys,
I think the problem is the old problem of privilege as much as anything. It's not a problem specific to women, but all "minorities". Actually I was thinking that open-source should/could be a very interesting thing in context of first peoples communities. I think communities like these would be very ideologically connected to the open-source concept. (from my white western "priviliged" perspective anyhow) Imagine if there was an open source OS (and there may be) that was centered around the ideology of a non-western community, a true fusion of spirituality and creative computing.
Interaccess was involved in something called the "Container Project" (http://www.container.access-it.org.uk/) that basically got funding to plunk a shipping container / computer lab into rural areas, in our case Jamaica, and taught workshops and so on there. Strangely there was little exposure to open-source software. People learned how to do HTML on old os9 macs and on windows98. I wonder if there is such a thing in the western world for first peoples communities.
I didn't read back the whole thread (sorry), but maybe you will find http://www.nabuur.com an interesting iniative. Its an online community based effort to solve issues in (Mostly) third world countries. But with a twist, first of, people can offer their wisdom directly without some NGO coming in between, and 2nd, local communites can get in contact with each other directly. I suggest you check it out for yourselfs because im very lousy at explaining the concept.
Cheers Anton
On Sat, 5 Mar 2005, brendan asselstine wrote:
is jMax dead because the Java VM is too slow for DSP?
first, jMax is dead because IRCAM killed it. It wasn't dead enough so they killed it again. It looks as if it was created to compete with Pd and didn't quite succeed at it. I stopped using jMax in february 2004 and since then I strongly encourage any remaining jMax users/lurkers to definitely switch to Pd.
The DSP doesn't run in the JVM. The messagesystem doesn't run in the JVM either. The JVM/Java/Swing is only for the GUI, (almost) just like Pd uses Tcl/Tk for that.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
first, jMax is dead because IRCAM killed it. It wasn't dead enough so they killed it again.
It looks as if it was created to compete with Pd and didn't quite succeed at it.
-I don't th§ink that's the real reason why it was created. It was intended to be a platform independent foluw-up to the Max/FTS that ran on the Next machine with the DSP-boards. After Next stopped making hte Cube in 1993/94 IRCAM decided not to be stuck on one platform. Also because general CPU's became more capable of doing the kind of number-crunching that were normally associated with DSP, they revamped FTS and tried to do all te client stuff with a java gui. During the period of 1998 to approx. 2001 it was used for internal performances (so the IRCAM-people say...) and productions (so the IRCAM-people say...), strangely enough all their technical performance manuals all refer to Max/MSP. like in Jonathan Harvey's String Quartet N ° 4 with live electronics: http://www.ircam.fr/fileadmin/sites/WWW_Ircam/fichiers/Cahiers_exploitation/... ey-SQ4_en.pdf As far as the architecture of jMax itself, I quite like the idea of aclient/server in the way it was implemented. But the notion of need a separate machine to run the gui, is ridiculous.
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
On Fri, 11 Mar 2005, Arie van Schutterhoef wrote:
-I don't th§ink that's the real reason why it was created. It was intended to be a platform independent foluw-up to the Max/FTS that ran on the Next machine with the
[...]
was used for internal performances (so the IRCAM-people say...) and productions (so the IRCAM-people say...), strangely enough all their technical performance manuals all refer to Max/MSP.
So what you state as the real reason why it was created, is nothing but the official statement of the IRCAM, regardless of actual facts?
As far as the architecture of jMax itself, I quite like the idea of aclient/server in the way it was implemented.
This was the idea behind IMPD.
But the notion of need a separate machine to run the gui, is ridiculous.
I've never "needed" that, and have successfully run several gallery installations and one computer-assisted theatre performance without ever using a remote GUI.
(Nevertheless, it's been a year that we have switched away from jMax for all our shows)
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
So what you state as the real reason why it was created, is nothing but the official statement of the IRCAM,
-Well I know of people within IRCAM I spoke to, concerning particular pieces we wanted to perform with the Schreck Ensemble, that all the live electronics were done with jMax. So that what I know about that. If that is really the case I don't know.
regardless of actual facts?
-Could you elaborate... Has this something to do with the dismissal of François Déchelle from IRCAM?
This was the idea behind IMPD.
-I just saw it. Quite nice.
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
Mathieu Bouchard wrote:
On Sat, 5 Mar 2005, brendan asselstine wrote:
is jMax dead because the Java VM is too slow for DSP?
first, jMax is dead because IRCAM killed it. It wasn't dead enough so they killed it again. It looks as if it was created to compete with Pd and didn't quite succeed at it. I stopped using jMax in february 2004 and since then I strongly encourage any remaining jMax users/lurkers to definitely switch to Pd.
I guess there are mainly practical reasons for jMax's disparaitre. To keep track on two different but very similar platforms, in this case Max/MSP and jMax, is waste of skills. They decided to port the interesting parts of jMax to Max. Which is the ftm library, it uses the new java max objects. Porting was easy, there is no more need for jMax. The open source aspect could let jMax survive, but with a so much stronger Pd community its not very likely. I'd rather learn Pd than keep jMax alive.
Stefan
On Sat, 5 Mar 2005, Frank Barknecht wrote:
James Aldridge hat gesagt: // James Aldridge wrote:
More readable? Hah. That has to be some kind of crazy joke, good one Olaf. ;)
Whatever Olaf wrote (I didn't get his mail): Not having segmented patchcord forces the user to be clearer and more orgaized in the layout of the *objects* inside - which is most of what Max/Pd is about.
If the design of Pd is so concerned about the layout of the objects inside it should have an option to set the max-width of an objectbox, messagebox, or comment.
Plus, I already have explained several times why straight patch cords don't cut it. I have hundreds of patchcords striking through objects because I can't stand having to use hundreds of [s $0-hello] to circumvent the problem.
That said, i sort of got used to have a crummy badlooking patch editor, mostly because I had no other choice. I figured out that the other advantages of Pd (over jMax) outweighted the inconvenients.
I'd rather not hear the "it's for your own good" argument unless it has solid backing, and I don't recall reading any such thing.
Anyway, having these as an option would be nice, but apart from imPd they haven't arrived yet.
They are not in IMPD. I only made something that renders them as randomly-placed (within certain bounds) and made splines out of it. That was 20 lines of code. It would have been a damn lot more to also get the mouse working with them, add a patchcord menu, make them load and save, send a patch to miller to make "regular pd" at least keep the segmentation info while editing, etc...
The screenshots of IMPD are in
http://artengine.ca/matju/impd/gallery/
I dropped the project around last may because I had real work =) but I never quite resumed it. impd_0_37 is a good demo of what it will be when it grows up, but impd_0_37 as it is will stay that way forever, while a modified copy of it will enter devel_0_38's body. I can't tell the exact date when that will happen, because my fortune teller woke up at that point. ;-)
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 5 Mar 2005, Frank Barknecht wrote:
James Aldridge hat gesagt: // James Aldridge wrote:
More readable? Hah. That has to be some kind of crazy joke, good one Olaf. ;)
Whatever Olaf wrote (I didn't get his mail): Not having segmented patchcord forces the user to be clearer and more orgaized in the layout of the *objects* inside - which is most of what Max/Pd is about.
If the design of Pd is so concerned about the layout of the objects inside it should have an option to set the max-width of an objectbox, messagebox, or comment.
Plus, I already have explained several times why straight patch cords don't cut it. I have hundreds of patchcords striking through objects because I can't stand having to use hundreds of [s $0-hello] to circumvent the problem.
Well, to each his own. As I wrote, personally I never felt the need to use segments.
Sidestory: two days ago I used the diagram editor "dia" to do some ER-schemas for a database project. "dia" of course supports segmented "patch cords", it's a real graphics program, so I used them as well, because they look nicer and can carry different meanings if used in conjunction with straight ones.
(Apart from finding myself pressing Ctl-E constantly which just zooms in in dia) I found myself fiddling around with every segmented line *twice* as long as with the straight lines, because I also needed to constantly move around the segment points of each line.
With the straight lines in Pd, this kind of fiddling is not possible. The only way to move the lines is to move the objects. That's why I probably would stay with straight lines most of the time anyway.
To me segmented patch cords are a useful tool in certain applications, that is, maybe in demonstration patches for workshops, in printed patches for books, in heavily "recursive" patches etc. But in the daily patching business to me they are as useless as the automatic file backups in Vim or Emacs.
But some finde these useful, too. No problem with that.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
Frank Barknecht wrote:
But some finde these useful, too. No problem with that.
Ciao
I think the point is that it would be nice for everyone to be able to make their own choice. Given that the code to do it sounds trivial, and jMax is dead (whether or not that had any bearing on this), could we at least put this in devel_0_38? (I also really like the arrows Mathieu was showing in impd, though I'm not *needing* the ability to have a hot babe as my canvas background ;) ).
-Ian
Hallo, Ian Smith-Heisters hat gesagt: // Ian Smith-Heisters wrote:
Frank Barknecht wrote:
But some finde these useful, too. No problem with that.
I think the point is that it would be nice for everyone to be able to make their own choice. Given that the code to do it sounds trivial, and jMax is dead (whether or not that had any bearing on this), could we at least put this in devel_0_38? (I also really like the arrows Mathieu was showing in impd, though I'm not *needing* the ability to have a hot babe as my canvas background ;) ).
As I understood Matju, coding it is not trivial, that's why it's *not* even present in imPd. The screenshots are showing another feature. (Please correct me, if I'm wrong.) Anyway: I would not object to segmented patch cords. However I don't think the lack of them must stop anyone from using Pd.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
If the design of Pd is so concerned about the layout of the objects inside it should have an option to set the max-width of an objectbox, messagebox, or comment.
I forgot to add: I would rather like to see this happen before segmented patch cords.
Oh, and mouse-controlled GUI object resizing.
And state saving modelled somehow after Memento as builtin. And more powerful list processing. And so on. Segments come way down on this list.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
On Sun, 6 Mar 2005, Frank Barknecht wrote:
And state saving modelled somehow after Memento as builtin. And more powerful list processing. And so on. Segments come way down on this list.
I'm thinking about eventually adding reference-counted lists to devel_0_38, so I would like to survey what would be a good selector name for that kind of data.
I am thinking about listp where the final p means pointer. It could also be list* to be C-like. I think "listpointer" may be too long. The contents of the message would be only a pointer to the actual list, instead of a full copy of it.
This would finally allow for nested lists. This would use the two reserved characters { } and would allow for messages like this one:
listp {0 foo {1 2 {}} {a b c} {42 3.1416 2.718 1.618}}
I'm not sure whether those lists would be mutable/immutable though. If they are mutable they would fill the gap of having arrays that don't just allow floats, but also everything else.
Those pointers would not be compatible with (g)pointers, that are only "allowed" to point to point to pd objects, and that don't do reference-counting.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
hi Mathieu,
Mathieu Bouchard wrote: ...
listp {0 foo {1 2 {}} {a b c} {42 3.1416 2.718 1.618}}
not to replace your project, just btw --
with plustot one can bang this
[+tot list 0 foo .(1 2 .(.).) .(a b c.) .(list 42 3.1416 2.718 1.618.)]
or send this message
"list 0 foo .(1 2 .(.).) .(a b c.) .(list 42 3.1416 2.718 1.618.)"
to [+tot $in], etc.
What +tot objects pass around are reference-counted Tcl objects created in an interpreter running in the pd process (unlike plain tot, which uses the pd-gui interpreter).
This is still just an experiment. I have not yet done anything useful with +tot.
Krzysztof
On Thu, 10 Mar 2005, Krzysztof Czaja wrote:
not to replace your project, just btw -- with plustot one can bang this [+tot list 0 foo .(1 2 .(.).) .(a b c.) .(list 42 3.1416 2.718 1.618.)] or send this message "list 0 foo .(1 2 .(.).) .(a b c.) .(list 42 3.1416 2.718 1.618.)" to [+tot $in], etc.
yeah, and also with GridFlow you can do this:
[#inner ( 2 2 # 0 1 1 0 )]
where anything between parens is converted to a Ruby Array (and in this case, reconverted to a 2-by-2 matrix, but it depends on what the object wants to have: some other objects want Ruby Arrays so they get them)
However, GridFlow doesn't reconvert nested Ruby Arrays to this parenthese form: it just refuses them. Instead of implementing that feature in GridFlow, I thought Pd could be modified for that, and thus everyone could benefit from that feature without having to have +tot or GF.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
On Thu, 10 Mar 2005, Mathieu Bouchard wrote:
On Thu, 10 Mar 2005, Krzysztof Czaja wrote: However, GridFlow doesn't reconvert nested Ruby Arrays to this parenthese form: it just refuses them. Instead of implementing that feature in GridFlow, I thought Pd could be modified for that, and thus everyone could benefit from that feature without having to have +tot or GF.
I mean this: that what both +tot and GridFlow do is incomplete and potentially slow (because of a need to continually do post-parsing !) and that a complete, non-hack solution is much desirable.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
I think a list* data type is a really good idea. I've wanted a feature like this for some time, but don't like using externals in my patches unless I absolutely have to. I think this is definitely something that should be built into 'standard' PD, and not require an external.
Just my 2p!
Jamie
On Thu, 2005-03-10 at 16:37 -0500, Mathieu Bouchard wrote:
On Thu, 10 Mar 2005, Mathieu Bouchard wrote:
On Thu, 10 Mar 2005, Krzysztof Czaja wrote: However, GridFlow doesn't reconvert nested Ruby Arrays to this parenthese form: it just refuses them. Instead of implementing that feature in GridFlow, I thought Pd could be modified for that, and thus everyone could benefit from that feature without having to have +tot or GF.
I mean this: that what both +tot and GridFlow do is incomplete and potentially slow (because of a need to continually do post-parsing !) and that a complete, non-hack solution is much desirable.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Jamie Bullock wrote:
I think a list* data type is a really good idea. I've wanted a feature like this for some time, but don't like using externals in my patches unless I absolutely have to.
I think this is also an important issue. There should be a better way of packaging a patch with the required externals for better transferability. This would make it easier for us all to share. But for all I know you avoid externals for idealogical reasons rather than compatibility.
-ian
I think this is definitely something that
should be built into 'standard' PD, and not require an external.
Just my 2p!
Jamie
On Thu, 2005-03-10 at 16:37 -0500, Mathieu Bouchard wrote:
On Thu, 10 Mar 2005, Mathieu Bouchard wrote:
On Thu, 10 Mar 2005, Krzysztof Czaja wrote: However, GridFlow doesn't reconvert nested Ruby Arrays to this parenthese form: it just refuses them. Instead of implementing that feature in GridFlow, I thought Pd could be modified for that, and thus everyone could benefit from that feature without having to have +tot or GF.
I mean this: that what both +tot and GridFlow do is incomplete and potentially slow (because of a need to continually do post-parsing !) and that a complete, non-hack solution is much desirable.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
For me, listp means "list predicate", just because we're dealing with lists, and lists make me think in Lisp.
What about listptr? Or list* is good. Or ladr (list address)? But doesn't ladr mean something else somewhere else? Or what about just lp?
This functionality will be fan-frickin-tastic. Much better than segmented patch cords.
-Ian
Mathieu Bouchard wrote:
On Sun, 6 Mar 2005, Frank Barknecht wrote:
And state saving modelled somehow after Memento as builtin. And more powerful list processing. And so on. Segments come way down on this list.
I'm thinking about eventually adding reference-counted lists to devel_0_38, so I would like to survey what would be a good selector name for that kind of data.
I am thinking about listp where the final p means pointer. It could also be list* to be C-like. I think "listpointer" may be too long. The contents of the message would be only a pointer to the actual list, instead of a full copy of it.
This would finally allow for nested lists. This would use the two reserved characters { } and would allow for messages like this one:
listp {0 foo {1 2 {}} {a b c} {42 3.1416 2.718 1.618}}
I'm not sure whether those lists would be mutable/immutable though. If they are mutable they would fill the gap of having arrays that don't just allow floats, but also everything else.
Those pointers would not be compatible with (g)pointers, that are only "allowed" to point to point to pd objects, and that don't do reference-counting.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Thu, 10 Mar 2005, Ian Smith-Heisters wrote:
For me, listp means "list predicate", just because we're dealing with lists, and lists make me think in Lisp.
It's just a name. The existing Pd lists are not linked, are immutable, and are stack-allocated, so that's three reasons for which they don't have much to do with LISP lists.
Instead they are more like a function-call that has a variable number of arguments. That's the *-prefix in Python/Ruby, the "args" keyword in Tcl, the $* in Bash/jMax, and the &rest keyword in LISP.
What about listptr? Or list* is good. Or ladr (list address)?
Seem like good options... but * never means pointer in Pd. However the name "pointer" is used, whereas "address" is never used. "pointer" is always spelt out long, never abbreviated. There is precedent of using one letter followed by "pointer", i mean "gpointer", which would suggest using "lpointer". However it's not exactly the same kind of pointer (different deallocation semantics), and also, the name "pointer" is also used as an abbreviation of "gpointer", which may confuse matters...
But doesn't ladr mean something else somewhere else?
I don't know. It sounds like a ladder... or like LISP's "cadr" function which takes the second element of a list, but that's a bit obscure, and tends to be replaced by the "second" function, AFAIK. (??)
Or what about just lp?
Reminds of lineprinter, as in the default parallelport driver. It wouldn't disturb me much if it were called "lp" though.
Actually, a heap-allocated mutable resizable indexed list is called "Array" in Perl/Python/Ruby/Lisp, and "Vector" in C++/Java/Lisp. (In LISP, the former is multidimensional, and every "Vector" is also a 1-dimensional "Array" at the same time)
But "Array" already means something in PureData, in a way that is not compatible with the concept I'm trying to introduce. So I feel a bit stuck...
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
not really much i have to say on this but:ction, AFAIK. (??)
Or what about just lp?
Reminds of lineprinter, as in the default parallelport driver. It wouldn't disturb me much if it were called "lp" though.
there was an [lp] object in zexy, communicating with the parallelport. i have abandoned that name (in favour of [lpt]) since "lp" has its meaning in a musical signal-processing context: it is a LowPass.
i don't think we should interfere with these objects just for the sake of an abbreviation (this would make pd significantly less intuitive)
mfg.ads.oiq IOhannes
Anyway, having these as an option would be nice, but apart from imPd they haven't arrived yet.
They are not in IMPD. I only made something that renders them as randomly-placed (within certain bounds) and made splines out of it. That was 20 lines of code. It would have been a damn lot more to also get the mouse working with them, add a patchcord menu, make them load and save, send a patch to miller to make "regular pd" at least keep the segmentation info while editing, etc...
The screenshots of IMPD are in
i think this is the best example http://artengine.ca/matju/impd/gallery/segmented4.gif
would be nice to have "intelligent wires".
this is a feature like that in PCB software (tools for designing circuits). given a netlist (here, a collection of inlets) with a list of nodes that should be connected together, the program find the best path for each connection, i.e. by following a grid. (there are well known algorithms about this)... and avoiding crossing objects or other wires (useful when you connect many>one inlets or vice-versa).
then this path can be rendered with lines, bezier, exp, various f(n)'s.... and you don't have to store those segments information in the patch, because they are computed by a kinda of AI :)
what do you think about it?
On Mon, 7 Mar 2005, federico wrote:
would be nice to have "intelligent wires".
[...]
then this path can be rendered with lines, bezier, exp, various f(n)'s.... and you don't have to store those segments information in the patch, because they are computed by a kinda of AI :) what do you think about it?
Yes, it's a good idea, and I was thinking about that last year when I was about to implement the feature for real. I had decided that wires would have three possible drawing-modes:
- non-segmented
- auto-segmented
- manually-segmented
Those three modes are per-wire, so a same patcher could contain a mix of the three modes of wires.
I haven't really tried any auto-segmentation, but I predict that users will want to do some manual segmentation too.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
then this path can be rendered with lines, bezier, exp, various f(n)'s.... and you don't have to store those segments information in the patch, because they are computed by a kinda of AI :) what do you think about it?
Yes, it's a good idea, and I was thinking about that last year when I was about to implement the feature for real. I had decided that wires would have three possible drawing-modes:
- non-segmented
- auto-segmented
- manually-segmented
Those three modes are per-wire, so a same patcher could contain a mix of the three modes of wires.
I haven't really tried any auto-segmentation, but I predict that users will want to do some manual segmentation too.
i wanted to test some auto-segmentation algorithm. i built up this piece of code (attached) in about a hour. this demonstrates basilar working of this feature. i am open to any suggestions. for now it very very simple. it still miss some magnetic control to avoid crosing objects, and some more anchor point to allow loop outlet->inlet of the same object.
the code is intended only to show this method. the interesting code is
in the zap() function.
i'm not able to program in tcl/tk.. otherwise maybe i would sent
directly a patch to pd.. hehe :)
you need fltk-1.1 to build it.
you can build it so:
$ g++ sc.cpp fltk-config --cxxflags fltk-config --ldflags
bye!
Federico
-
Anton Woldhek -
Arie van Schutterhoef -
B. Bogart -
brendan asselstine -
clemos -
derek holzer -
federico -
Frank Barknecht -
Hans-Christoph Steiner -
Ian Smith-Heisters -
IOhannes m zmoelnig -
James Aldridge -
Jamie Bullock -
Krzysztof Czaja -
Mathieu Bouchard -
Stefan Tiedje -
Tim Blechmann