Hi All,

I wonder if any of you use 'graphic tables' interfaces to write pathes or simply interact with Pd and how. i.e. a pen table, palm pal for drawing, touch pad mouse, pen wee-keyboards. Last year in Bordeaux a saw some people form the scrime using them.

Best wishes,

Ricardo

hi marco,

Am Dienstag, 23. April 2002 20:04 schrieb marco:

I would be quite interested in interfacing the pressure and tilt info into the actual event creation. Has this been done? a wacom~ or gtk-event-interface~

you might want to take a look at the usb objects i made for jmax. there is one generic event object, and one for tablets (but currently only decodes my hyperpen, with pressure ...) which should be easy to extend for other tablets too. of course it needs to be a usb tablet ;-D adoption to a pd object shouldnt be that hard, i think ...

greets,

chris

As far as I can tell, PD and Tcl/Tk are married, and will be for the forseeable future. If you tried to replace tcl/tk with java or something, you would have replace all of the gui externs as well. I used to feel that tcl/tk was icky and had to go, but in actually learning it, I stopped caring. Any programmer who would be able to add segmentation to the connectors in a java based gui can learn to use tcl/tk well enough in a few afternoons, it really isnt that complicated. Further, if you feel really die hard about your opinion that Java is the way, why are you not using jMax? It'd gui is "prettier" and written in Java right now.

On Tue, 2002-04-23 at 10:19, joge . wrote:

its not really about decorations it about helpful graphical content . useless decorations are not what java would be used for . in my mind , java is a nice programming language in the same vien of pd , simple to program [alot simpler then tcl/tk] and its object oriented which resembles pd's paradigm of objects. then again i have never worked with tcl/tk to any extent but from what i see it looks very mangaled and not very "friendly" . this is what i mean by helpful graphical content : a language like python or java , is graphically helpful when you see the text its some what more intuitive for a person who has programmed in c/c++ to follow the code and then to take there hand at modifing it as they see fit . Also i think the tcl/tk windowing graphics can be a bit *raw* for new comers to pd to get into it right off the bat . i know lots of peoplt who buy apple computers to run Max/MSP [well that and the documentation helps too] . i mean most people that use a program like pd are not hardcore programmers , they are artists that have a strong background in computers and wish to do some cool/interesting/playful project with computers that perhaps they couldnt do any other way .

any how , i would like to hear more about what you and every one else thinks about tcl/tk and why its the way to go for pd's gui editor . i personally would like to try my hand at implementing a java alternative for pd with extensive class stuctures that can be easily documented [javadoc] , maintained and modified by any one with experience in OO programming .

joge .

----- Original Message ----- From: Yves Degoyon To: pd-list@iem.kug.ac.at Cc: 'Pure Data' Sent: Tuesday, April 23, 2002 11:47 AM Subject: Re: [PD] pd-gui wishlist

Frank Barknecht wrote:

Hi,mark hat gesagt: // mark wrote: I know its boring but the main thing I would like from the GUI is for it to look nicer - Jmax despite not doing half the things I want it to looks fantastic and is nice to use. Yes, but as it's wishing time ;) I would also like the PD gui to befaster. Some patches, especially those with lots of number boxes, runa lot faster when pd is started with -noguiciao, speaking of light-speed interfaces, java is certainly not the way. and if you like a lot of decorations ( which i don't, i'd rather a pure interface ), you're not going in that way neither.

about decorations, Tcl/Tk is not a limitation for that, latest relesases includes transparency, it doesn't do 3D-accelerated graohics, ok .... but do we use it outside of Gem ? ? ?

about tool tips poping up, i hope it was only meant for edition mode, in performance mode, it would be an impediment.

you might be surprised i dislike useless decorations, knowing i did some graphical externs, but heavy graphic operations for these objects are launched at patch loading time or in the background.

i'm not sure it's useful to update numbers or sliders each 1/1000 second.

yvotchka.
Unauthorized pd

On Tue, 2002-04-23 at 13:16, joge . wrote:

i am not die hard java by any means . its just the language that i have alot of experince with and though i would through it you there to the group for discussion . i am new to pd so i dont know to much about its base code structure . so i was curious if it was even possible to attempted a gui in java .

I* understand, I love Java myself, and it took me a long time to settle into the idea that the future of pd IS in tcl/tk ... which as a language on its own holds no candle to Java, but works great within the needs of PD. In learning it, i've come to even (gasp) like it some :)

as for jmax , i tried to use it for a while but it is still well in it infance it appeared to me . i guess mostly in the sense that there is not to much of a use group as far as i am aware . i am subcribed to the jmax list and the activite is mostly about the software development and compilation of jMax .

yeah, I am keeping the corner of my eye on jmax, but the pd community is just bar none.

thanks for the info though , i didnt mean to sound like java is the way to do every thing and that tcl/tk is evil . hehe .. with this information i think i will looked further into tcl\tk . is there a particularly good resource any one can recommend ?

I found this (ammusingly titled) tutorial to be quick and good, if you are comfotable enough in other programming/scripting languages:

"Tcl for Web Nerds"

http://www.arsdigita.com/books/tcl/index

and of course, the most appropriate domain name EVER http://tcl.tk has lots of good links.

good luck!

-Josh

Whoa, thats a fantastic idea, a display of the tree of the patch... I'd certainly get a lot of use for that.

Ben

On Tue, 23 Apr 2002, intent wrote:

Another idea: An "Explorer" like interface

At the left you see the arborescence of your patches, at the right the patch you select.

That way you can reach an abstraction easily without having to open/close all the intermediary levels.

Linium

B. Bogart

it would be not bad to have a possibility to group objects -> Ctrl+G

i agree with Mark: nice to have a subpatch manager.

Also I`d like to add one more idea about object managment in pd. I mean a customizable external manager where user can add, subtract, navigate and comment himself his externals. We have very many objects and libs for pd already, but we have to keep all of them in our head now.

And one more little suggestion: is it possible to create a small dimension object (it could be look like a toggle obj) wich will graphicaly replace send and recieve objects? r and s objs have very big nonfunctional dimension, and size of object depends on size of name of message.

thank you

best regards, Andrei Savitsky www.hhtp.org

----- Original Message ----- From: "mark" mark@junklight.com To: "Ben Bogart - FMPM/F1999" bbogart@acs.ryerson.ca; "intent" intent@club-internet.fr Cc: "Pure Data" pd-list@iem.kug.ac.at Sent: Wednesday, April 24, 2002 12:05 AM Subject: RE: [PD] pd-gui wishlist

Actually - that is an excellent idea. It would be nice to have it in a separate window so you could traverse (and may be alter) subpatchs without opening windows "all the way down".

Good call..

cheers

mark

-----Original Message----- From: Ben Bogart - FMPM/F1999 [mailto:bbogart@acs.ryerson.ca] Sent: 23 April 2002 22:41 To: intent Cc: Pure Data Subject: Re: [PD] pd-gui wishlist

Whoa, thats a fantastic idea, a display of the tree of the patch... I'd certainly get a lot of use for that.

Ben

On Tue, 23 Apr 2002, intent wrote:

...

Another idea: An "Explorer" like interface

At the left you see the arborescence of your patches, at the right the

patch

...

you select.

That way you can reach an abstraction easily without having to

open/close

all

...

the intermediary levels.

Linium

B. Bogart

i agree on the point that pd need some gui improvments, but for the functionnality only not the way it should look... pd DOES look nice as it is now, it's meant to be a workplace and not a showroom ! I really don't see the point to add 3d like interfaces and heavy design, if someone wants this, well you will have to make some kind of stuff just like ircam has done with the macromedia xtra plugin to control jmax...

things that would help:

• speed :)
• magnetic grid
• to be able to hide/gray/freeze some parts of the patch
• to be able to "color" some parts of the patch (this group of boxes

are red and belongs to blabla ... this is green and is meant for blabla...)

• undo :)

stm

Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:

I've been following this thread but haven't responded yet because it's a bit overwhelming... My own priorities for 0.36 are probably:

1. undo

This would be my first, as well. Living without undo must stop ;)

2. better interface for cutting patch cords (although this might not

be so important once "undo" works!)

yes, with undo, the occasional deleting of a patch cord would not be very harmful anymore.

3. throttling number box updates to save CPU time

votes++

At the moment I'm still trying to get the OSX code integrated correctly; once I get that working robustly I'll declare 0.35 "stable"...

Although I'm on Linux, I'm starting a project where I will need PD on Mac, so I would be very thankful if the Mac Port comes along well.

ciao,

Frank Barknecht _ _______footils__

Funny, I've been working on something similar- the answer to your question is no, but it _is_ possible to stream pd's output with yves' shoutcast~ (in no-gui mode if you like) then use a flash animation to control pd via osc (http://www.benchun.net/flosc/ ). Which makes me wonder if flash would be capable of receiving and playing back a ice/shoutcast audio stream, thus creating the effect of an "embedded" pd patch in the browser. Any Flash wizards out there know the answer to this?

On the subject of gui-goodness, has anyone had the opportunity to play with the sodaconstructor/osc controller? http://www.soda.co.uk/explore/osc.htm

thanks

Bill

on 4/24/02 5:00 AM, Ricardo Climent at r.climent@qub.ac.uk wrote:

Sorry if it sounds like quite a disoriented question but would it be possible to run Pd online as an embedded application within a browser? To say something, like actionscript does within flash to create new objects. It can create classes, instance of the classes, methods etc. I do not know much about the tcl interpreter and tk although.

Here is the idea (flash plugin needed) > http://www.acusmatica.com/php/pdtest.swf

Ricardo

If I follow you correctly, I love the idea, it hadnt occured to me. What I take you to mean is to put a tree view in a sidebar of sorts that you can visually see how all the subpatches ([pd blah]) relate. This is a great idea.

On Tue, 2002-04-23 at 14:32, intent wrote:

Another idea: An "Explorer" like interface

At the left you see the arborescence of your patches, at the right the patch you select.

That way you can reach an abstraction easily without having to open/close all the intermediary levels.

Linium

ah, i actually mis-read the first mail. "surfing" the structure of your patches would be cool.. so thesaurus doesnt fit here.

best, g

At 23:56 Uhr +0200 23.04.2002, V93r wrote:

this is like the "new object" list in max, i dont know if it isn't a little bit annoying..

interesting would be to have an object/externals thesaurus. this may not be a gui feature, but someone might have nice frontend ideas for it. it also might require an standardized way of writing help patches, and/or also categorizing objects. dont know how to get this started, but it would be really helpful. i have the vision that each new external i install adds to the tree, telling me what i can use it for.. and of course -selecting it in the tree would automagically write it in my object-box in the patch.

g

At 23:32 Uhr +0200 23.04.2002, intent wrote:

...

Another idea: An "Explorer" like interface

At the left you see the arborescence of your patches, at the right the patch you select.

That way you can reach an abstraction easily without having to open/close all the intermediary levels.

Linium

Well here I am going out on a limb.

I do not find tcl/tk ugly or difficult or innefficient. I am aware that large patches do take forever to load in PD. (or they can) I am not a programmer, a scripter at best. I use Tcl/tk because it is portable, has strong string tools, and is easiest, which I have used, to build GUIs in. Bulding a GUI in tcl/tk is more like building an HTML page than coding (good enough reason for most of you to hate it!) Its also slow (ugly intreptive language) but I could GREP though a 14,000 element list in a few seconds)

tcl/tk used the be the scripting counterpart to JAVA, they were developed side by side at SUN. Just aimed at different needs. I know someone wrote an entire webserver in tcl/tk (it ran the old scriptics.com) and handled thousands of hits a day.

point of the story, Tcl/Tk is not that bad, crap looking at Lisp and Scheme, Java, C++ etc at least tcl code is in english...

my 2 cents.

Ben

On Tue, 23 Apr 2002, joge . wrote:

...

As far as I can tell, PD and Tcl/Tk are married, and will be for the forseeable future. If you tried to replace tcl/tk with java or something, you would have replace all of the gui externs as well. I used to feel that tcl/tk was icky and had to go, but in actually learning it, I stopped caring. Any programmer who would be able to add segmentation to the connectors in a java based gui can learn to use tcl/tk well enough in a few afternoons, it really isnt that complicated. Further, if you feel really die hard about your opinion that Java is the way, why are you not using jMax? It'd gui is "prettier" and written in Java right now.

i am not die hard java by any means . its just the language that i have alot of experince with and though i would through it you there to the group for discussion . i am new to pd so i dont know to much about its base code structure . so i was curious if it was even possible to attempted a gui in java .

as for jmax , i tried to use it for a while but it is still well in it infance it appeared to me . i guess mostly in the sense that there is not to much of a use group as far as i am aware . i am subcribed to the jmax list and the activite is mostly about the software development and compilation of jMax .

thanks for the info though , i didnt mean to sound like java is the way to do every thing and that tcl/tk is evil . hehe .. with this information i think i will looked further into tcl\tk . is there a particularly good resource any one can recommend ?

thanks

joge .

B. Bogart

graphics in Java has always been the weak point, and i don't find it particularly pretty in any of its skins. .. i did a lot of projects with JSP, Servlets, J2EE...but no graphics.

• java will hardly allow client/server structure

between PD and PD-GUI, if you use RMI, you'll also get troubles with performances.

client/server structure is a real good feature in PD.

why is this so ? that is how does tcl\tk differ from java in the client/server structure between PD and PD-GUI ?

this is what i mean by helpful graphical content : a language like

python or java , is graphically helpful when you see the text its some what more intuitive for a person who has programmed in c/c++ to follow the code and then to take there hand at modifing it as they see fit .

Also i think the tcl/tk windowing graphics can be a bit *raw* for new

comers to pd to get into it right off the bat . i know lots of peoplt who buy apple computers to run Max/MSP [well that and the documentation helps too] . i mean most people that use a program like pd are not hardcore programmers , they are artists that have a strong background in computers and wish to do some cool/interesting/playful project with computers that perhaps they couldnt do any other way .

i also know some artists who like the aesthetic of PD's appearance . . .

its not about the appearence of PD that i think is ugly .. i rather like it now that i am used to it . for my self personally i think there are jsut a few features which other people have mentioned in this thread [inlet outlet naming/description] patch cord coloration for signal and number lines . the feature i guess i was interested but not sure if any one else was interested in is segmented patch cords [*bendable* patch cords] . But i am going to look into tcl\tk a bit more because it seems to be the way to go to further pd . any good resource to tcl\tk would be greatly apprietiated .

lot of work ahead !!! but, if you loose client/server structure then you'll get to a less flexible tool. . . good luck . . .

thanks again .

joge .

     Although I kind of cringe when I say this...

     Hide-on-lock would be nice.

     GUI aside... an "undo" feature would be nice. My left hand is 

itching for CTRL-z...

. . David McCallum . Queen's University Electronic Music Studio Manager . and Noise Maker . html://mentalfloss.ca/sintheta/ .

Yes, but as it's wishing time ;) I would also like the PD gui to be faster. Some patches, especially those with lots of number boxes, run a lot faster when pd is started with -nogui

this should not be on a wishlist, it should be a high priority! at first i thought that Xwindows was to blame but it's the same under windows. i don't know if it's pd or tcl/tk that's causing the problem, but it's appalling to see a few spinning number boxes eat 25-40% on a 1.4ghz cpu!!! especially when i have pathetic old macs doing the same thing in max without breaking a sweat.

can somebody look into this??

also, the array object is particularly bad when it comes to cpu use. is there a non graphic version?

thanks, cgc

Hello!

On Tue, 23 Apr 2002 15:10:03 -0700 Joschi joschi@eds.org wrote:

I have never seen "a few spinning number boxes" eat up more than 1-2% on my athlon 1.4ghz ... If you honestly see such thing, you should submit a patch demonstrating this problem to the list. Miller is terrific about fixes problems, but noone can fix a problem if they dont have a specific test case.

How about this one...

Load on my Celeron 450 is over 2.0. Debian GNU/Linux, Pd 0.35t17.

Miha...

• Miha Tomšiè --- C. na postajo 55 -- SI-1351 Brezovica pri Lj. --- SLOVENIA -

On Wed, 24 Apr 2002 21:05:42 +0200 IOhannes m zmoelnig zmoelnig@iem.kug.ac.at wrote:> > Load on my Celeron 450 is over 2.0. Debian GNU/Linux, Pd 0.35t17.

cool: it's over 2% ??

I wish... :) Load is over 2.0, pd-gui CPU usage is between 20% and 40%.

PIII-800; Debian(woody)-2.4.17:::

Nice system...

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 22763 zmoelnig 16 0 1456 1452 1008 S 8.1 0.5 0:01 pd 22775 zmoelnig 18 0 3108 3108 1956 S 7.5 1.2 0:01 pd-gui

10:31:55 up 1:13, 4 users, load average: 2.27, 1.83, 1.11

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 1612 mike 16 0 3272 3272 1996 S 21.3 0.8 4:05 pd-gui 1611 mike 9 0 1660 1656 1176 S 8.3 0.4 0:21 pd

Take care,

Miha...

• Miha Tomšiè --- C. na postajo 55 -- SI-1351 Brezovica pri Lj. --- SLOVENIA -

How about this one...

not surprised by this one, but Miller answered this with the item "Throttle for number boxes" in his TODO list, i would add "Throttle for sliders" ??? if it's still Xmas time and that you can make all your wishes for next PD . . :-)

yves.

I agree that aesthetics is definitely important to an interface, many people (most notable "artists") feel stress when having to interact with an ugly or messy program (like an old version of cakewalk or logic platinum) and more at ease with pretty and functional programs (like ableton live or reason) ... it definitely isn't the most important consideration, but it matters.

For clarity, I'm not trying to call PD ugly or messy, I actually am quite fond of its clean look. I do think that little subtleties of design go a long way though.

-Josh