http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
Anyone interested by that kind of change to Pd?
I mean optional, configurable themability.
Mathieu Bouchard http://artengine.ca/matju
On Sunday 15 February 2004 16:17, Mathieu Bouchard wrote:
http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
Anyone interested by that kind of change to Pd?
I mean optional, configurable themability.
Yes! Me likes it :-)
Larry Troxler
isn't max/jmax look&feel copyrighted in any way? oh yep, this time we should say ircam contributed to pd.
Larry Troxler wrote:
On Sunday 15 February 2004 16:17, Mathieu Bouchard wrote:
http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
Anyone interested by that kind of change to Pd?
I mean optional, configurable themability.
Yes! Me likes it :-)
Larry Troxler
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Sun, 15 Feb 2004, Yves Degoyon wrote:
isn't max/jmax look&feel copyrighted in any way?
Well, by making the look+feel pluggable, I intend to make it so that the jMax look isn't really _in_ Pd, but that Pd has all hooks necessary to make it so.
That is just in case IRCAM claims rights on it, but I doubt they would, and then jMax is _free software_, no matter how in your eyes IRCAM is not a real « contributor to free software ».
I don't know why you even mention MAX here, which has a different look altogether.
Mathieu Bouchard http://artengine.ca/matju
Mathieu Bouchard wrote:
On Sun, 15 Feb 2004, Yves Degoyon wrote:
isn't max/jmax look&feel copyrighted in any way?
Well, by making the look+feel pluggable, I intend to make it so that the jMax look isn't really _in_ Pd, but that Pd has all hooks necessary to make it so.
That is just in case IRCAM claims rights on it, but I doubt they would, and then jMax is _free software_, no matter how in your eyes IRCAM is not a real « contributor to free software ».
i only mentionned this as long as there is a private club with a membership admission to get certain jmax extensions. but, in that case ( making pd a clone of jmax ), mm, i think any free software developper wouldn't like that ( except if you clearly state you're into plagiarism )...
I don't know why you even mention MAX here, which has a different look altogether.
well, the tool bars really looks like MAX one's, no?
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Sun, 15 Feb 2004, Yves Degoyon wrote:
i only mentionned this as long as there is a private club with a membership admission to get certain jmax extensions. but, in that case ( making pd a clone of jmax ), mm, i think any free software developper wouldn't like that
And so what? What I'm asking is whether they'd get mad and act upon it.
I don't know why you even mention MAX here, which has a different look altogether.
well, the tool bars really looks like MAX one's, no?
Well, GNOME and KDE really look like Microsoft Windows, no?
Just how much my toolbar should not look like MAX's ??
Mathieu Bouchard http://artengine.ca/matju
On Sun, Feb 15, 2004 at 10:22:13PM -0500, Yves Degoyon wrote:
isn't max/jmax look&feel copyrighted in any way?
Does IRCAM have some sort of patent on it's 3D look, like Apple for it's trash can? Like jMax itself, it's probably copylefted, but it's unclear if there could be legal issues with importing specific graphical features from a GPL software (jMax) to a BSD software (PD). Of course, it would fair to mention that those graphics comes from jMax, and the jMax team might even like that PD promotes the jMax look'n'feel.
What's really important is that the look and feel of PD can be "improved", even themable, which is the holly grail of coolness on the XJ scenes.
:-)
Marc
On Sun, 15 Feb 2004, Marc Lavallée wrote:
On Sun, Feb 15, 2004 at 10:22:13PM -0500, Yves Degoyon wrote:
isn't max/jmax look&feel copyrighted in any way?
Does IRCAM have some sort of patent on it's 3D look, like Apple for it's trash can? Like jMax itself, it's probably copylefted, but it's unclear if there could be legal issues with importing specific graphical features from a GPL software (jMax) to a BSD software (PD).
Actually, an update, it seems it's not GPL anymore, it's now LGPL. Possibly since version 4.x, not sure... I think it's since jMax/fts became embeddable in other software, as libfts.so ... (btw, can Pd do this?)
Anyhow, I got permission (by email) to use the icons, from François Déchelle, lead developer of jMax.
Mathieu Bouchard http://artengine.ca/matju
am 17.02.2004 21:59 Uhr schrieb Mathieu Bouchard unter matju@sympatico.ca:
On Sun, 15 Feb 2004, Marc Lavallée wrote:
On Sun, Feb 15, 2004 at 10:22:13PM -0500, Yves Degoyon wrote:
isn't max/jmax look&feel copyrighted in any way?
Does IRCAM have some sort of patent on it's 3D look, like Apple for it's trash can? Like jMax itself, it's probably copylefted, but it's unclear if there could be legal issues with importing specific graphical features from a GPL software (jMax) to a BSD software (PD).
Actually, an update, it seems it's not GPL anymore, it's now LGPL. Possibly since version 4.x, not sure... I think it's since jMax/fts became embeddable in other software, as libfts.so ... (btw, can Pd do this?)
Anyhow, I got permission (by email) to use the icons, from François Déchelle, lead developer of jMax. Mathieu Bouchard http://artengine.ca/matju
Please, do not use the icons in any case, i think they should look different. I agree with guenther who wrote:
A big NO! to the icons you used, I take it as "an example - that will be changed for the real thing" :) I mean, there should be enough creativity potential to design our own.
max
On Tue, 17 Feb 2004, Max Neupert wrote:
Anyhow, I got permission (by email) to use the icons, from François Déchelle, lead developer of jMax.
Please, do not use the icons in any case, i think they should look different. I agree with guenther who wrote:
A big NO! to the icons you used, I take it as "an example - that will be changed for the real thing" :) I mean, there should be enough creativity potential to design our own.
hahaha, can't believe it, is it jmaxophobia !?
or fear of not having a distinctive look ?
anyhow, icons are going to be very easily replaceable, like GIFs in a directory, which is also how jMax has it. Yes, you can make jMax load another icon set, be it pictures of your cats, of cars, or of bdsm... So why not the same in Pd ? (Especially since it's more difficult to make it nonconfigurable!)
And some people at Ottawa U are designing a new icon set already (or several? I don't know).
But people like you actually deserve a bunch of stark-looking monochrome icons. :-}
Or even, just the names of the objects written in plain text. (Oh wait, that's the Put menu!) :-}
Mathieu Bouchard http://artengine.ca/matju
Have you already implemented these sgwiggy patch chords? ("sgwiggy" should go down as the 'Pd-list' word of the week btw!). Anyway I'm of the opinion that even if only a few people out there would appreciate this, it is worth doing for them alone? No? It appears that it would be at least nice to have the option, I can see it now, going to Pd workshops and seeing all the 'old-schoolders' still using the straight patch lines, subpatches and GOP's while the young whippersnappers(me btw!) will all be amazed that they can't get their segmented patches to look so good! Good times ahead guys!!
Ciao, Rory.
-- Mathieu Bouchard matju@sympatico.ca wrote: >
On Tue, 17 Feb 2004, Max Neupert wrote:
Anyhow, I got permission (by email) to use the
icons, from François
Déchelle, lead developer of jMax.
Please, do not use the icons in any case, i think
they should look
different. I agree with guenther who wrote:
A big NO! to the icons you used, I take it as
"an example - that will be
changed for the real thing" :) I mean, there should be enough creativity
potential to design our own.
hahaha, can't believe it, is it jmaxophobia !?
or fear of not having a distinctive look ?
anyhow, icons are going to be very easily replaceable, like GIFs
in a
directory, which is also how jMax has it. Yes, you can make jMax load another icon set, be it pictures of your cats, of cars, or of bdsm... So why not the same in Pd ? (Especially since it's more difficult to make it nonconfigurable!)
And some people at Ottawa U are designing a new icon set already (or several? I don't know).
But people like you actually deserve a bunch of stark-looking monochrome icons. :-}
Or even, just the names of the objects written in plain text. (Oh wait, that's the Put menu!) :-}
Mathieu Bouchard
http://artengine.ca/matju
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
___________________________________________________________ BT Yahoo! Broadband - Free modem offer, sign up online today and save £80 http://btyahoo.yahoo.co.uk
On Wed, 18 Feb 2004, Rory Walsh wrote:
Have you already implemented these sgwiggy patch chords? ("sgwiggy" should go down as the 'Pd-list' word of the week btw!).
I prefer the more traditional spelling "squiggly".
I can see it now, going to Pd workshops and seeing all the 'old-schoolders' still using the straight patch lines, subpatches and GOP's while the young whippersnappers(me btw!) will all be amazed that they can't get their segmented patches to look so good!
So what does that make me? an oldschooler or a whippersnapper?
On Wed, 18 Feb 2004, Martin Peach wrote:
Alexandre Castonguay wrote:
Curved or segmented patch cords can also help the readability of a patch when it is inevitable to have lines crossing objects.
Maybe if the patch cords were uniquely coloured and also passed behind objects (or became slightly transparent) it would be better.
Such transparency is not supported by Tk. I want to have options like "pass all patchcords behind objects" and "hide patchcords in run mode" etc... I don't think I'll do the coloring though...
On Wed, 18 Feb 2004, tom wrote:
I think beginners like segmented patch cords. Taking a few minutes to make a patch "pretty" gives them a breather from the "difficult" programming experience and it is something everyone can be good at. I LOVE the curved patch cords! I think the interface should be part of the artwork.
Agreed.
That is why I would still support the making of an OPENGL interface for PD. People like to look over your shoulder when you are giving a performance, why not give them something to look at.
Well, *I* will not go that far myself, but there are plenty of ways to entertain your spectators even with a Tk GUI (!)
See you at PureData Montréal #3...
Mathieu Bouchard http://artengine.ca/matju
So what does that make me? an oldschooler or a whippersnapper?
Like they say, your only as old-'schooler' as you feel!
Anyway I'm lloking forward to seeing it all when its done, good luck!
Rory.
___________________________________________________________ How much mail storage do you get for free? Yahoo! Mail gives you 6MB! Get Yahoo! Mail http://uk.mail.yahoo.com
Mathieu Bouchard wrote:
Such transparency is not supported by Tk. I want to have options like "pass all patchcords behind objects" and "hide patchcords in run mode" etc... I don't think I'll do the coloring though...
tcl.tk is only beginning to drip into my consciousness, but from what I have seen so far, it is possible to open a Tk canvas and have openGL or some other graphics package draw on it. See http://burks.brighton.ac.uk/burks/language/tcl/tclcook/chap6.htm
Martin
Max Neupert wrote:
Please, do not use the icons in any case, i think they should look different. I agree with guenther who wrote:
A big NO! to the icons you used, I take it as "an example - that will be changed for the real thing" :) I mean, there should be enough creativity potential to design our own.
It's usual to see free software projects with non-free graphics, go figure... In this case it's not a critical issue since the jMax leader gave its consent. So appart from the desire to invent a specific PD "look'n'feel" (which PD already have), there's no reason to hurry; "potentially creative design" is still unpatented. ;-)
-- Marc
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
Anyone interested by that kind of change to Pd?
I mean optional, configurable themability.
With emphasis on "optional" and "configurable" I'd say: yes, this is nice. I sometimes thought about this toolbar idea, too. Personally I don't even use the menu much anymore, but neverthless a toolbar is great to have. I'm not sure about the graphics, though, and not just, because I don't like drop or standout shadows. If it is just for the eye candy factor, than I wouldn't care much. It also might make patches even less portable than they are now, for example in regard to different font size rendering on Windows and Linux.
ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
Anyone interested by that kind of change to Pd?
Oh, I missed the Ruby and Tcl consoles until now. That's very cool. Could you do Python as well? ;)
ciao
Frank Barknecht _ ______footils.org__
On Mon, 16 Feb 2004, Frank Barknecht wrote:
I'm not sure about the graphics, though, and not just, because I don't like drop or standout shadows. If it is just for the eye candy factor, than I wouldn't care much. It also might make patches even less portable than they are now, for example in regard to different font size rendering on Windows and Linux.
Could you please elaborate on portability issues? because I don't see them. The bevels I added are inside the boxes; I didn't change the size of the boxes, except accidentally, and I would reverify everything before actually submitting a diff.
On Mon, 16 Feb 2004, Frank Barknecht wrote:
Oh, I missed the Ruby and Tcl consoles until now. That's very cool. Could you do Python as well? ;)
Well, I didn't add the Tcl one in PureData, but in GridFlow. It can be moved very easily from gridflow/bridge/puredata.rb to pd/src/u_main.tk, by simple copy+paste.
However the Ruby one cannot be moved, as it depends very much on GridFlow. If you want a Python one then that should be added to Pyext, and likewise for Scheme and such.
Mathieu Bouchard http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 16 Feb 2004, Frank Barknecht wrote:
I'm not sure about the graphics, though, and not just, because I don't like drop or standout shadows. If it is just for the eye candy factor, than I wouldn't care much. It also might make patches even less portable than they are now, for example in regard to different font size rendering on Windows and Linux.
Could you please elaborate on portability issues? because I don't see them. The bevels I added are inside the boxes; I didn't change the size of the boxes, except accidentally, and I would reverify everything before actually submitting a diff.
Windows and XFree use different default dpi. So many of the patches created on Windows use a 12 font, while many Linux users prefer font size 10. 10 looks tiny on Windows, whereas 12 looks rather large on Linux. The problem is, that tighly spaced objects will overlap on Linux, but might look nice on Windows. Actually your changes probably won't collide with this particular problem.
Did you do some performance tests?
ciao
Frank Barknecht _ ______footils.org__
On Mon, 16 Feb 2004, Frank Barknecht wrote:
On Mon, 16 Feb 2004, Frank Barknecht wrote:
Windows and XFree use different default dpi. So many of the patches created on Windows use a 12 font, while many Linux users prefer font size 10. 10 looks tiny on Windows, whereas 12 looks rather large on Linux. The problem is, that tighly spaced objects will overlap on Linux, but might look nice on Windows. Actually your changes probably won't collide with this particular problem.
Ok, I'll keep that in mind...
Did you do some performance tests?
No, haven't yet, and prolly will try that only much later, inserting a piece of code in both versions of Pd (i mean devel_0_37 and mine) and measuring things like number of dropouts and client-server bandwidth and such. I am confident that my version will eventually become faster than devel_0_37, at least when configured with the classic Pd layout. I am rewriting a bunch of code in Tcl/Tk, which may seem slower, except that the way I do it it reduces the client-server bandwidth being used, which is good, especially wrt dropouts.
On Wed, 18 Feb 2004, Frank Barknecht wrote:
I'd prefer it the other way around and strongly would vote for manual segmenting instead of automatic. No algorithm would be able to tell, which patch cords *I* would like to be segmented,
I very well understand that, and my segmentation algorithms prolly will be crappy at first, so a manual mode is a must =)
and which ones I would like straight. Also I wonder: How would an algorithm look like that deals with ambiguities created by segmenting? Would it just not allow cords to run on top of each other? Running on top could be cleaner in some cases, but it also would be hazardous for reading a patch in a lot of other cases.
It would use a particle system such that the nodes of the cords repulse each other into nonambiguous positions. (Just kidding.)
Seriously, if anyone wants to try writing that algorithm, it would be nice... =)
Mathieu Bouchard http://artengine.ca/matju
Mathieu Bouchard wrote:
http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
makeup is good but I vote for it only when it improves usability. What really is needed are segmented cords to render patches more readible. I dont like the direct lines and soon end up to put all in subpatches and subpatches.
With friendly greetings,
Malte
Hallo, Malte Steiner hat gesagt: // Malte Steiner wrote:
makeup is good but I vote for it only when it improves usability. What really is needed are segmented cords to render patches more readible. I dont like the direct lines and soon end up to put all in subpatches and subpatches.
... which promotes modularity and reusability! ;)
ciao
Frank Barknecht _ ______footils.org__
On Mon, 16 Feb 2004, Malte Steiner wrote:
http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
makeup is good but I vote for it only when it improves usability. What really is needed are segmented cords to render patches more readible. I dont like the direct lines and soon end up to put all in subpatches and subpatches.
Oh, but they _are_ segmented now. I hope you'll have enough indirect lines with this to be fully satisfied. Witness by yourself at:
http://artengine.ca/gridflow/gallery/segmented.gif
Mathieu Bouchard http://artengine.ca/matju
On Tue, Feb 17, 2004 at 05:29:49PM -0500, Mathieu Bouchard wrote:
Oh, but they _are_ segmented now. I hope you'll have enough indirect lines with this to be fully satisfied. Witness by yourself at:
Would it possible to move and rearrange the lines at any angles? Most "segmented lines" freaks won't like your messy example...
-- Marc
On Tue, 17 Feb 2004, Marc Lavallée wrote:
On Tue, Feb 17, 2004 at 05:29:49PM -0500, Mathieu Bouchard wrote:
Oh, but they _are_ segmented now. I hope you'll have enough indirect lines with this to be fully satisfied. Witness by yourself at: http://artengine.ca/gridflow/gallery/segmented.gif
Would it possible to move and rearrange the lines at any angles? Most "segmented lines" freaks won't like your messy example...
Most humourless freaks won't get the joke... :-}
No, they are not movable, it's made from randomly generated positions, and they change positions every time you reopen the patch, or even just unminimize it. (!!!)
Which brings the question whether the segmentation should be automatic or manual. If it's manual, it has to be saveable, So I guess it would look like:
#X connect 2 0 5 0 <x> <y>;
or:
#X connect 2 0 5 0 <x1> <y1> <x2> <y2> ... <xn-1> <yn-1>;
(for a n-segment line)
or other similar schemes. OTOH I have a penchant towards automatic placement. My friend Xavier suggested what is IMHO the Right thing, that is, automatic placement is default, and then you can override with manual placement on a wire-by-wire basis. What I haven't decided yet is whether the drawing algorithm would take manually-placed wires into account when computing the other wires (I can vaguely imagine some frustrating situations if it actually did, but I'd have to try it).
In either case, Pd can have a menu-option like "show segmentation" on/off.
Btw, in my version (let's call it Impure Data), the patchcords are being drawn by a Tcl procedure, which allows one to customize patchcord style without recompiling.
Who wants animated patchcords? 8-]
Mathieu Bouchard http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Which brings the question whether the segmentation should be automatic or manual. If it's manual, it has to be saveable, So I guess it would look like:
#X connect 2 0 5 0 <x> <y>;
or:
#X connect 2 0 5 0 <x1> <y1> <x2> <y2> ... <xn-1> <yn-1>;
(for a n-segment line)
or other similar schemes. OTOH I have a penchant towards automatic placement. My friend Xavier suggested what is IMHO the Right thing, that is, automatic placement is default, and then you can override with manual placement on a wire-by-wire basis.
I'd prefer it the other way around and strongly would vote for manual segmenting instead of automatic. No algorithm would be able to tell, which patch cords *I* would like to be segmented, and which ones I would like straight. Also I wonder: How would an algorithm look like that deals with ambiguities created by segmenting? Would it just not allow cords to run on top of each other? Running on top could be cleaner in some cases, but it also would be hazardous for reading a patch in a lot of other cases.
ciao
Frank Barknecht _ ______footils.org__
On Sun, 15 Feb 2004, Mathieu Bouchard wrote:
http://artengine.ca/gridflow/gallery/pd_console_4.gif http://artengine.ca/gridflow/gallery/cellular_1d_themed.gif
Anyone interested by that kind of change to Pd?
I mean optional, configurable themability.
Theamability would be nice, but AFAIK it is not implemented yet in tcl/tk (although a proposal in this direction got accepted by the developers).
An optional toolbar would improve usability a lot.
A big NO! to the icons you used, I take it as "an example - that will be changed for the real thing" :) I mean, there should be enough creativity potential to design our own.
Guenter
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
Frank Barknecht -
guenter geiger -
Larry Troxler -
Malte Steiner -
Marc Lavallée -
Martin Peach -
Mathieu Bouchard -
Max Neupert -
Rory Walsh -
Yves Degoyon