Hey PD gurus,
I used to use PD a lot but haven't much for the last year or more. Now I'm getting back in to it and finding that the UI is just really clunky and awkward and makes the workflow really painful. I build website UIs professionally in JavaScript (see http://www.zillow.com/search/RealEstateSearch.htm for an example of a UI I built, everything except the Flash). I also have on-the-job experience in design and usability, as well as coding skills in Python and some exposure to C, C++ and Java. I'd like to start pitching in specifically on GUI and chrome improvements in the trunk for the core PD UI. How would I go about getting started? I noticed the page at http://puredata.info/dev/GuiIdeashas some outstanding requests from the community, it seems like the best thing is to start there. I'd also like to integrate with the developer community to ensure that UI improvements (specifically, better keyboard support and smoothing out some glaring dialog/chrome issues) don't have a negative impact on realtime audio performance.
Best,
David
Hey,
Glad to hear you are interested in working on the GUI, there is a lot
that needs to be done, and a lot that can be done without too much
difficulty. The GuiIdeas page is a good place to start, I'll happily
give you pointers where I can. For me, I think the most burning
issue is the Path and Startup preferences panes. They are really
broken and cause lots of confusion. So if you are interested, you
could start by sketching up the UI for those in straight Tcl/Tk, and
then we can get it integrated into Pd itself.
I am not sure what you mean by 'chrome' though. Also, have you tried
a recent nightly build of Pd-extended? I have smoothed out most of
the keyboard issues, I think.
.hc
On May 3, 2008, at 6:04 AM, David Golightly wrote:
If you are not part of the solution, you are part of the problem.
I am not sure what you mean by 'chrome' though.
http://www.37signals.com/svn/archives2/lingo_chrome.php
to get OS chrome on Tk, it may be as simple as a 'require Tktile'
On Sat, 2008-05-03 at 05:16 -0400, cdr wrote:
http://www.catb.org/~esr/jargon/html/C/chrome.html
On Sat, 2008-05-03 at 05:16 -0400, cdr wrote:
and tile http://wiki.tcl.tk/13636 is now part of tk8.5 http://tcl.tk/software/tcltk/8.5.tml
hey david!
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
greetings, fabb
On Sat, May 3, 2008 at 6:04 AM, David Golightly davigoli@gmail.com wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Frank Barknecht _ ______footils.org__
I think it would be cool, if users had the possibility to decide themselves whether they want to use richer graphics display in their patches. to create an interface like in synthmaker, you need for example opengl features inside the patcher window. I know that people already do that and it seems to work well, but it is not supported by pure pd, one reason for which is that the tcl/tk patcher system is too much integrated in the pd core. what is so bad about, if you create [ADSR] that it comes as a nice little control gui with all the knobs already included? it is not true that words are "better" than images. and it is not true that more information in a patch means "better". I think you are right from the viewpoint of a programming user, but users that just want higher level usuability want better graphics at least the *possibility* to add graphical UI features. but this is quite a lot of work...
a good example for me are web-pages. you really don't want to read all the code behind. you want it to work and have a nice UI. with pd you also want a nice interface for the "performing" situation.
btw. we need to make pd run in a browser environment.
marius.
Frank Barknecht wrote:
Le 3 mai 08 à 15:41, marius schebella a écrit :
OK, here a small ADSL interface with knobs ;)
It works with Pd version 0.39.3-extended. I don't know why but
[image] doesn't work with pd-0.40.3-extended-20080315
Maybe some people would be interested to 'design' some abstractions.
Problem : the size. 9.9 Ko :)
++
Jack
Jack wrote:
there is also [iem_image] in the iemgui library, which I think has slightly more features. from a graphical UI viewpoint the knobs do not really look good. nor does the bang. but in general I like the idea of more abstractions like this. btw, I was surprised to see that images work on GOPs!
marius.
On May 3, 2008, at 6:03 PM, Jack wrote:
Nice GUI patch! The image is working for me on 0.40.3- extended-20080502 on mac os x/intel.
.hc
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hi List...
http://video.google.com/videoplay?docid=-2991739314359132538
Maybe a question to who ever used "ann", or maybe the two developers
Johannes Zmoelnig and Davide Morelli
I posted a link...
Do you think "ann" is powerful and fast enough to do something like
that ??
Would be nice to hear your opinion about that
Thanks Luigi
nice! in the description of the algorithm they talk about some pending patents... I guess they use more than simple ann comparison to get this working in realtime on a game console. for basic gestures it might work, but you have a 3d space (which means a lot of data) and no clear start and end trigger for your movements, so to me this looks like a challenging task... but if you manage to somehow calibrate your data before you send it to ann (maybe normalize x, y, z and time? or use statistic methods to get more meaningful values, also think how a gesture's start and end can be found) then ann hopefully does the rest. marius.
Luigi Rensinghoff wrote:
Hallo!
Yes, I also would not use a feedforward neural network (as implemented in ann) for this. You have to use a model which also incorporates time.
For example a hidden markov model or echo state network (= special kind of recurrent neural network) should work.
(The second is currently the topic of my thesis - so maybe I will make some similar examples in summer, when I have some time again ... ;)
LG Georg
Hi,
On Sun, 2008-05-04 at 08:37 +0200, Georg Holzmann wrote:
Hm. You can incorporate changes over time using a standard feedforward ANN by wrapping your time-ordered vectors over a given time period into a single input vector and increasing the number of inputs to the network accordingly. But of course this introduces latency and other problems (e.g. it could massively increase the number of training examples required).
Pd has the ann_td external, which provides a 'time delay' neural network which I believe incorporates time using a method similar to that described above.
For example a hidden markov model or echo state network (= special kind of recurrent neural network) should work.
I'm intrigued! Presumably these approaches avoid the latency problem by maintaining the network's state? Are there other advantages -- easier to train?
Jamie
Hallo!
Yes of course, one other possibility is to use time delayed neural networks ...
Hm ... I did not think about latency ... but if you do not process the data in blocks there should not be a significant latency (also for the time delay NN) ?
However, the advantage of the echo state network is that training is linear and you cannot get in a suboptimal solution as with feedforward neural networks (where the error surface has multiple local minimas) - see for example http://www.scholarpedia.org/article/Echo_state_network for a short introduction. And it is recurrent - so in general more powerful ... from the link above: "On a number of benchmark tasks, ESNs have starkly outperformed all other methods of nonlinear dynamical modelling"
If you are interested, I implemented ESNs (with various extensions) in a C++ library with python bindings: http://aureservoir.sourceforge.net/, a PD external will hopefully follow in summer ...
LG Georg
Hi all
very interesting, really..
yet it does take me away more and more from my inital question ;-)
And a practical solution to implement some simplicistic gesture
recognition in PD..
..and wait for the summer, when the PD bindings are ready...
I hope there will be some creative, artisitic examples then..
Best Regards
Luigi
Am 04.05.2008 um 13:59 schrieb Georg Holzmann:
---------------------------------------<
Luigi Rensinghoff luigi.rensinghoff@freenet.de skype:gigischinke ichat:gigicarlo
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Most of my patches only use a handful of Pd core objects, like maybe (guessing) 50 builtins and some externals. However on my disk there are hundreds of abstractions, that I use. If I would need to think of and design icons for each of these, I would not use abstractions and I would feel severly limited in what I could express with Pd. Concrete example: What icons should I use for the ~60 abstractions in the list-abs collection? It's no problem to express their functionality using words, but icons would be horribly confusing. Oh, and yes: I'm a programming user here, but I believe most Pd users are programming users, and the others rely on the work of programming users.
Frank Barknecht _ ______footils.org__
On May 5, 2008, at 10:07 PM, Frank Barknecht wrote:
Pd definitely needs text, text is a great, flexible symbol system for
representing a massive array of words. But I also think that some
iconic objects would be nice, like jMax's trigger or Max/MSP's gate.
.hc
There is no way to peace, peace is the way. -A.J. Muste
Am 06.05.2008 um 20:23 schrieb Hans-Christoph Steiner:
there is another vital thing missing in the core: a knob. http://footils.org/cms/show/20
we've got button (=bang), switch (=toggle), radio-button and slider
as representations of real life input methods on a synth, mixer or
whatever electronic instrument.
there is no reason why exactly the knob should be left out.
On Tue May 06, 2008 at 01:39:53PM +0200, brandt@subnet.at wrote:
knob is one of the best input 'device' for mouse
first you can do the limitlesss thing.
ive never seen a slider that 'wraps around'. it would look weird. not like a knob where spinning 360 makes sense
plus with different buttons or even combinations of buttons, wheels, scrolling regions, and gestures, you can get pretty expressive in the granularity of the dynamic changes
a proper x/y multitouch multi-param pad is essential as well..
hey franz!
left to right makes sense with the synthmaker environment, as each module (can) have hint texts for their in- and outputs: http://img517.imageshack.us/img517/581/smhelptexttu4.png i miss these little help texts in pd as i have to look for each module (when i found it) what each input means. sure, when you've been working with pd for years, you don't need this, but it's definately a help. hovering tips would be nice at least.
and you can, but you probably won't perform in this view. you can drag your interface together (from several subpatches levels) and just display this for the performance. like this http://www.synthmaker.co.uk/images/alieno/alieno%20M.png
and hey matt: at least some sort of bent links would make sense, as horizontal links in pd are the worst, overseeing prone. maybe something not user bendable, auto bending like in plogue bidule: http://img147.imageshack.us/img147/6782/ploguebidulexv5.png
greetings fabb
On Sat, May 3, 2008 at 12:21 PM, Frank Barknecht fbar@footils.org wrote:
On Sat, May 3, 2008 at 3:27 PM, Matt Barber brbrofsvl@gmail.com wrote:
When I see stuff like fancy icons etc, I'm always a bit afraid that those of us on low res machines (1024x768 in my case) would get really screwed in the end as one cool, large, fancy, chromey module would take up half the screen! IMO tiny pd boxes are always better as they save space and increase whitespace, increasing readability ... and a well named abstraction is more powerful then loads of graphics. Those signal inlet, outlet signs in SynthMaker are annoyingly large too, whereas in PD a thicker line is completely obvious enough.
I guess it all comes down to who PD is aimed at ... people who need a fancy interface or people who want to get some work done. (ohhh I went there!)
What I would like would be a unified set of common interface elements as already suggested. A better [knob] would be nice for instance
2 bits
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
Dan Wilcox robotcowboy.com
Hey folks,
My interest (at first) would not be to add anything or enhance the appearance of things; I'm more interested in helping to improve the PD workflow by making PD easier to use.
Something like an optional "snap to grid" feature for instance would be nice for auto-aligning and cleaning up patches. While I understand the argument that bending patch cords increases the visual noise of a patch, it's already noisy when patch cords cross at acute angles or when the data flows from bottom to top (which is necessary to do many things in PD). Perhaps creating some logic to bend patch cords at right angles only, tracing the aforementioned grid? I won't have time to work on this at first though, so it's worth thinking about for a while.
I agree that the startup paths dialog needs a lot of help - when you run PD-extended it's already full of paths for externals, leaving you nowhere to put your own paths!
I get really annoyed that there's no way to bulk-edit GUI elements (vsliders, etc.). For instance, if you draw a whole bunch of vsliders, then realize that you forgot to set "no init" to "init", you have to manually open each one and click the button. To make matters worse, they tile automatically, so after a number of the vslider properties dialogs have been open, the buttons to close the dialog are below the bottom of the screen!
I would also really like it if you could do all of your basic patching in PD without using the mouse. Perhaps some key bindings like (in edit mode):
<tab> to select an object, cycling through the objects/messages in the current patch (<shift-tab> to reverse) <enter> to type in the selected object/message <shift-arrow> to select one of the selected object's outlets <space> to create a new patch cord <tab> to cycle through the rest of the objects on the page (<shift-tab> to reverse, or <esc> to cancel the operation)
also, when typing in an object or message, pressing <esc> should "blur" (deselect) the object/message, restoring its previous value ("cancel"); <tab> should select the next object for editing, and <shift-enter> should "blur" the object, setting its value to what you just typed.
Does PD currently have any key bindings guidelines? I'd be interested in finding out what's already taken (though none of the combinations I mentioned above appear to be currently in use).
What do you all think about this? I'm starting to dive into the tk, it looks like however almost all of the GUI is in pd/src/u_main.tk, which at around 4300 lines is substantially larger than any of the C src files. It would be nice if we could organize this a little better by breaking up the large source file into smaller, more module files, though I haven't yet investigated how much work that would be, and anyways we can live with the current organization if it's too much trouble.
So, I'm interested in starting with fixing some of the messy dialogs, then working toward getting a mouse-less edit mode.
-David
On Sat, May 3, 2008 at 10:05 AM, Dan Wilcox danomatika@gmail.com wrote:
On May 3, 2008, at 8:06 PM, David Golightly wrote:
Hear, hear!
Something like an optional "snap to grid" feature for instance
would be nice for auto-aligning and cleaning up patches.
Sounds good.
The linearity of the patch cords makes it easier to trace the path of
them. You don't have to follow the cords with your eye, but instead
it is just readily apparent.
I think there should be a subwindow with a line for each path entry,
then + and - buttons for editing the entries. Then if there are lots
of entries, that subwindow would scroll. There is a Tk 'listbox"
which would work for this (seen in action in the Help Browser).
That would be quite useful.
There are quite a few that are taken. I think the key is to make
sure that none of the standards for each platform are overridden, and
that we use the standards on each platform.
u_main.tk is a mess. It needs to be cleaned up in a big way. I
think to start with, it is possible to tack more stuff on, then
reorganize it. I am planning on refactoring u_main.tk after I get
the 0.40.3-extended release out. I talked with Miller about it, it
sounds like he is willing to accept such changes.
So, I'm interested in starting with fixing some of the messy
dialogs, then working toward getting a mouse-less edit mode.
Sounds great, keep us posted on what you are working on, and post
questions when you have them!
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On 03/05/2008, at 20.06, David Golightly wrote:
So, I'm interested in starting with fixing some of the messy
dialogs, then working toward getting a mouse-less edit mode.
That sounds great. I especially like your focus on editing objects
prefs.
For the path/lib pref panel, the attached is what i got at when i
stalled.
actually do it while learning tcl/tk and getting into Pd src. This
sketching need no edits to Pd source code but tries to black-box test
first. Depending on the actual implementation one might need to patch
s_path.c, hence recompile Pd to do a full test (as opposed to just
swap main.tk). IOhannes recently got a patch for adding more path/
libs into Vanilla that gives more then 10 variables to work with in
the Tcl side of Pd. A better fix would be to use another format (not
assumed in my test) then pd_path0, pd_path1, ..., pd_pathN - like a
'pd_path' array.
On May 8, 2008, at 9:18 PM, Steffen Juul wrote:
This test looks like a great start. If it could have in-place
editing and the ability to change the order, it would be perfect!
The path/startup stuff should already be in place for this to plug
into, thanks to IOhannes' patch.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Ok, after a busy week this is what I've been able to come up with for the Path dialog. I'm thinking about adapting this UI for the Startup dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text. Still, have a look and let me know what you think - I've set up some various key bindings so I want to make sure it seems usable for everyone. So far I've only tested this on Mac OS X, so feedback on other platforms would be nice. I'll probably get a Windows build at some point as well.
-David
On Thu, May 8, 2008 at 4:12 PM, Hans-Christoph Steiner hans@eds.org wrote:
On 10/05/2008, at 19.48, David Golightly wrote:
Ok, after a busy week this is what I've been able to come up with
for the Path dialog.
Looking really good! The browse functionality is a fair idiom in a
such GUI as oppose to entering text, i think.
"One" comment: I have a beef with the functionality of the buttons.
Not the Cancel one. The others. 'Apply' does something. 'Ok' does
'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says
the list is only gonna work from next time Pd is lunched, why i don't
get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all
one wants, anit?
I haven't checked your code but i suppose most "proc's" can be reused?
I've set up some various key bindings so I want to make sure it
seems usable for everyone.
Nice. What are they?
So far I've only tested this on Mac OS X
OS X.4 here.
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul stffn@dibidut.dk wrote:
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".
Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit").
So far I've only tested this on Mac OS X
OS X.4 here.
And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk (make a backup first!) to try it out.
On Sat, May 10, 2008 at 12:48 PM, David Golightly davigoli@gmail.com wrote:
Well scratch that then, perhaps that will only work when you're building pd on your own machine. If you launch Pd from Terminal, you might see error output in that terminal window - that would be helpful to have.
On Sat, May 10, 2008 at 3:17 PM, marius schebella < marius.schebella@gmail.com> wrote:
Just verified against my own install of Pd-extended-0.40.3 on OS X 10.4 - enough differences exist otherwise in the nightlies that this version of the file will only work with 0.41.4.
Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly davigoli@gmail.com wrote:
On 11/05/2008, at 2.25, David Golightly wrote:
So... what's the procedure for checking in to svn :)?
(FWIW.) To make a patch and submit it to the patch-tracker as SF.
Then a few things can happen (and some combinations):
Miller doesn't accept it and it doesn't get into vanilla 3) Hans subs
the patch to SVN and use it for Pd-extended.
Wow, what an improvement! I like it a lot. I have some comments:
panel would be narrower?
where it is a common thing. On Mac OS X, it should just be OK and
Cancel. On Windows, there should be Apply. I think GNOME has moved
away from Apply, but I don't know anything about KDE.
things clearer, I think. Like maybe Up/Down on the right side, and
then Add..., Edit..., and Delete on the bottom? Or maybe just
changing Up and Down to arrows?
entering values should be embedded into the panel instead of a
popup. Also, it doesn't seem to work for me (I am using 0.41-4
vanilla). I can't add items to the list.
I think once this is worked out, the best plan would be to submit a
patch to the tracker and assign it to Miller. Then I'll also include
it in Pd-extended.
.hc
On May 11, 2008, at 2:25 AM, David Golightly wrote:
http://at.or.at/hans/
On Sun, May 11, 2008 1:29 pm, Hans-Christoph Steiner wrote:
KDE seam to have both Apply and OK (and Cancel). But i don't think the actual UI need be platform dependent. That is, i think it matters less then having multiple buttons with different names that hint much the same functionally but don't nessacarily supply that functionality. Apply, Ok and Save in this case - as explained earlier.
One easy solution is to remove the Save button and add the save functionality to the Ok button. And then either remove also the Apply button or add the save functionality to that also. So where
Save:= Saves changes to file ready for next startup of Pd Cancel:= Cancels i.e. quit the dialog
we have:
Case i: Cancel Apply:= Save Ok:= Apply + Cancel
Case ii: Cancel Ok:= Save + Cancel
That said, I'd like to underline that i think the improvements already done are much more impotent then this clearing of confusion of the UI. I shall rest my case now (or submit a patch).
I just thought of one other thing: I think it would be very useful
if Path, Startup, Audio Settings, and MIDI settings where all tabs in
one panel, instead of four separate panels.
.hc
On May 11, 2008, at 1:29 PM, Hans-Christoph Steiner wrote:
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hans-Christoph Steiner wrote:
Thanks Hans, for bringing that up, I second that. I think it is better organized, if there is one preferences or settings menu, that will let you change all different things. I also think that the audio settings should not be split, like it is now (in extended?) preferences - audio midi and the media - portaudio/jack settings. I think these could be unified, too.
marius.
Oops, one other detail with the "encode" proc. While namespaces are
probably the current way to handle function names, they are not used
for any other functions in u_main.tk So for this function, I think
it should be called something like pdtk_encodelist without the
namespace, then grouped with pdtk_encode. Something like this:
proc pdtk_encodelist {listdata} { set outlist {} foreach this_path $listdata { if {0==[string match "" $this_path]} { lappend outlist [pdtk_encodedialog $this_path] } } return $outlist }
Then perhaps namespaces can be introduced later as a more systematic
approach.
.hc
On May 11, 2008, at 3:15 PM, Hans-Christoph Steiner wrote:
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
This is all great feedback, guys - keep it coming. Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work - I also work full-time and make music too - so I think prioritizing some of these ideas into subsequent releases is probably the best way to get them into Pd.
Some points:
each list item, and also tried to look for a way to edit list items in place, but couldn't figure out how to make that work in Tcl/Tk, so I settled on the popup box. The bug you saw with that not working, Hans, I've since fixed.
wasn't wholly satisfied with it and found that it introduced more problems than it solved. For example, what if you select multiple Paths and then click "Edit"? What is that supposed to do?
really cool, but it seems like it's a lot more work to do that, since Tk's default listbox widget only wants to deal with arrays of strings.
removed everywhere and folded into "Apply" ("OK" does "Apply" + "Cancel"). I think what it originally was supposed to do was give you an opportunity to test settings without saving them, but for that, I think it's best to have something like a "Revert settings" button instead. Also, I think this functionality is so marginal that we can remove it altogether.
MIDI) should all be different tabs in the same dialog. However, that seems like a feature that can be added at a later time; for now, I'd like to focus on finishing up the improvements that we already have, so we can try & get them into Vanilla, then perhaps go through the menu system at some point and re-evaluate how that's structured, maybe do some further improvements with some of the other menus too. Plus I'm itching to get on to improving the UI widget settings boxes.
having everything keyboard-accessible, which includes stuff like tab order, so I think it's probably best to keep around the buttons for list editing commands for now, although we can certainly investigate ways to reduce the size they take up on the screen.
I'm going to spend some spare time over the next few days working out some of the remaining kinks, then I'll re-post the patch for review before submitting it to the tracker. Thanks again to everyone who has taken time to look at the proposed changes!
If anyone has specific ideas to improve the layout of these dialogs, it would be amazing to see some sort of low-fi sketch of what you have in mind, just black outlines with text on a white background would be fine. Also, if anyone has some more advanced Tk wizardry they'd like to impart, or could point me to some better resources, I'd be most grateful - Google has been a lot less helpful than I've experienced with other languages/platforms.
Thanks, David
On Sun, May 11, 2008 at 7:57 AM, Hans-Christoph Steiner hans@eds.org wrote:
David Golightly wrote:
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started. marius.
On 14/05/2008, at 0.16, marius schebella wrote:
Especially since the names in Tk are to my experience somewhat
different to what one put in the search bar, ie. of my/your(?)/normal
vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
A note on the latest changes: I removed all the list manipulation buttons and added the following bindings:
"Enter" to change the selected item.
I kept around the "New..." button, since it may not be immediately obvious to newbies how to add new things to the list.
I also removed the "Save all settings" button and folded its action in to the "Apply" command (and, by extension, the OK command). I played around with trying to get an in-place editable listbox control for the Startup dialog, but to no avail - it's apparently no trivial task in Tcl/Tk. Perhaps for a future revision. However, the popup dialog functions effective the same, as "Enter" will submit your edit and "Esc" will cancel; once you get used to it it shouldn't be much different.
I'm also now centering the dialog windows on the screen. I'd like to do this also (especially) for the "Properties" dialogs that are used to edit GUI controls. Tk like to try and "cascade" new dialogs as they appear; this is too clever by half, and really annoying once if you do a lot of editing. But I've only tested this centering behavior on my own Macbook 15" screen, so it would be great if others could verify it's still usable on other screen sizes.
One other thing: these dialogs can now be resized, but they appear at their minimum size, so you can't shrink them any further (you can only expand them).
Please let me know what you think and as always let me know if you run into any trouble!
Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly davigoli@gmail.com wrote:
Very nice! The mouse/keyboard interactive is well done, I only worry
that the buttons are now too sparse. I think delete and edit buttons
would still be useful, maybe people don't use keyboard shortcuts at all.
Also, on Mac OS X, Delete is not commonly used, so it would be good
to also have BackSpace work for deleting. Or maybe Cmd-BackSpace
since that is what is used for deleting in the Finder.
.hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
As requested, I've put back the "Edit" and "Delete" buttons and added BackSpace as a Delete event for Mac OS X. I couldn't get Cmd-BackSpace to fire effectively, but perhaps someone knows something I don't about getting that to work.
On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner hans@eds.org wrote:
Looks good to me. This is already a massive improvement over what is
there. I don't know if you are sick of working on it, but I thought
I'd throw a couple of minor ideas:
stretch with the resizing window. Then you could see more of those
flags.
center of the screen? I think you can get that info using [winfo
rootx .] and [winfo rooty .]
.hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
i admit that i haven't looked at it, but what you describe reminds me awfully of Micro$oft's VisualStudio 6, which would give you a popup with a 20 character wide text-field to add include-paths,... think of all the fun i had when adding my 5th include-path in this field (i even had a hard time remembering whether i already had added a certain path as i would have to navigate within this field) from my pov, it was one of the major improvements in newer releases of this software to add expandable multi-line fields for this.
so yes, i think this is a good proposal
fgmasdr IOhannes
Oops, found a little bug: double-clicking on an empty cell through
up an error dialog.
Also, an idea: if you just draw that popup entry box just below the
listbox with the OK button, add a Cancel button, then use "pack
forget" when the user hits OK or Cancel. Just a thought. That mini-
popup window is the only thing about these panels that is weird, I
guess that why I still am thinking about how to ditch it.
.hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Here's a revised copy with a few minor changes (the "startup flags" field now expands to fill the window, you can resize the startup command popup arbitrarily).
I'm wondering about the protocol of introducing dependencies in PD. It seems that BWidget gives us a widget that we can use for the listbox ( http://tcllib.sourceforge.net/BWman/ListBox.html), however, it's perhaps not distributed with older distributions of Tcl/Tk. BWidget is distributed with Tcllib, which is apparently a default library packaged with most installs of Tcl, http://wiki.tcl.tk/12099 says that it comes by default with the ActiveState distro, with .deb and .rpm packages, and it was installed by default on my Mac OS X 10.4 distribution. But it's not guaranteed to be installed with ALL distributions of Tcl/Tk - I just have no idea exactly how many users might lack it.
Failing that, the popup should behave exactly as inline editing does, even though it looks a little strange. You can still use the keyboard to navigate: down, down, enter, type, enter, up, enter, esc... Just think of it as inline listbox editing with extra window chrome :)
On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner hans@eds.org wrote:
PS I was unable to reproduce that issue where you saw an error message from clicking on an empty cell. For me, clicking on empty cells just brought up the "Add new item" dialog. Could this be a difference of platform/TclTk version? I'm running 8.5 on OS X 10.4. I'd also like to get the specific error message if you can get it.
Thanks,
David
On Mon, May 19, 2008 at 10:07 PM, David Golightly davigoli@gmail.com wrote:
Just tried your new version, very nice, I think it's sorted, except
one tiny bug with the resizing of "Add new startup command". I think
you'll want to set a minimum window width, since you can resize it
smaller and make the OK button disappear.
You might look into the Tile/ttk widgets, they are now included in
Tcl/Tk 8.5. I'd like to use 8.5 for Pd-extended 0.41, so they would
be there. For example, a ttk::notebook could be used to host all of
the pref panes into a single window.
About the error, I just dropped your u_main.tk into Pd-vanilla
0.41-4, so that uses the version of Tcl/Tk included with Mac OS X,
8.4.7. I have Tcl/Tk 8.4.18 installed, it might be using that. But
I definitely don't have 8.5 Here's the error:
Startup panel:
can't use empty string as operand of "+"
can't use empty string as operand of "+"
while executing
"expr {$height + $top}"
(procedure "ScrollBox::dbl_click" line 8)
invoked from within
"ScrollBox::dbl_click .gfxstub5b1230 dlg_Startup::edit
dlg_Startup::add 65 45"
(command bound to event)
Path pane:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1930 dlg_Path::edit dlg_Path::add 81 42" (command bound to event)
.hc
On May 20, 2008, at 8:32 AM, David Golightly wrote:
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
Ok, how does this look?
I was still unable to reproduce the clicking bug, but I changed the code to avoid the scenario that your stack trace seems to indicate as the problem, hopefully you won't see it any more.
Turns out I also have Tcl/Tk 8.4.7. Don't know where I got the idea I had 8.5 installed. So it seems either the tcllib or the Tile/ttk widgets might be a good bet for the next revision to these dialogs. One goal here also I think is to eventually provide a good basis for further customization of the Pd environment and UI, which will of course require someone to delve in the C for some of it, although perhaps to the extent that some customization can be done in pure Tcl/Tk, C work can be avoided.
Thanks again,
David
On Tue, May 20, 2008 at 3:00 AM, Hans-Christoph Steiner hans@eds.org wrote:
Since it's been a few days since my last update, and I haven't received any responses, I submitted patch #1971585 to SourceForge, including the updates to the Path and Startup dialogs. Any further suggestions are still welcome; I will be investigating consolidation of the 4 preferences dialogs into a tabbed dialog of some sort (a la Tk notebook). However, perhaps an earlier priority for me will be figuring out some improvements to GUI control dialogs; perhaps bulk-editing/updates modeled (I think) on the iTunes UI for editing the metadata on multiple songs.
Anyways, thank you to everyone who offered feedback and code reviews to my efforts! Much appreciated. I'm grateful to be able to contribute code to a piece of software that has been so useful to me in the past.
Best, David
On Wed, May 21, 2008 at 8:50 PM, David Golightly davigoli@gmail.com wrote:
Everything is working quite well. My only issue with it is what I
mentioned before, the popup text entry box for editing. But it is
definitely usable as it is now.
Thanks for taking this on!
.hc
On May 25, 2008, at 2:22 AM, David Golightly wrote:
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
I think we can do this incrementally. I'll try including what you
have in Pd-extended when you are ready.
As for help, I find that #tcl on freenode IRC is quite helpful. Some
of the devs hang out there and often help out.
.hc
On May 13, 2008, at 9:44 PM, David Golightly wrote:
There is no way to peace, peace is the way. -A.J. Muste
Hi, I have a suggestion for interface design changes, probably not simple to impliment though;
I would like a debug mode where there was realtime visual feedback in the patching window of where signal and data are flowing (rather than having to attach numbers, toggles and bangs to outputs to see the information move and diagnose a mis-patching) kind of half the point of a visual programing language I had thought.
-joseph
2008/5/14 Hans-Christoph Steiner hans@eds.org:
Hi list, i'm looking for an hex2rgb converter abstraction? someone can help me or i should use php (or python) scripting for it?
thanks Husk
What form is your hex in? A symbol or a list?
On Thu, 15 May 2008 09:52:34 +0800 husk husk00@gmail.com wrote:
Hallo, husk hat gesagt: // husk wrote:
i'm looking for an hex2rgb converter abstraction? someone can help me or i should use php (or python) scripting for it?
Maybe this: http://lists.puredata.info/pipermail/pd-list/2006-03/036005.html
Frank
Le Thu, 15 May 2008 09:52:34 +0800, husk husk00@gmail.com a écrit :
you can use the PDMTL [convert.hex2dec] abstraction then [pack f f f] the value for RGB
bye
O.
Hi,
I haven't been following the thread, but I wanted to leave a couple of
sugestions that I had here:
I gues it would be nice that while typing an object (any kind of object)
text editor
would make a line break that really remains there.
A couple of weeks ago we also taked about the possibility of having
user-defined color themes. I think that could be quite interesting,
because you could have a brighter theme to work at home, a darker for
concert/performance, etc. etc. Hans told us where to find the color
scheme, but I didn't find the Tk color codes yet (ok, I tried a bit, but
not too much). A small applet to define the pd-colors would be great, but
that's already too much to ask, there are probably more important stuff
first.
Best,
João Pais
On May 14, 2008, at 4:56 PM, João Pais wrote:
I added Home/End to Pd-extended and submitted a patch to the
tracker. Ctrl-A would be tricky on Windows and GNU/Linux since that
is also select-all, but I added it on Mac OS X, since that is a
default binding on Mac OS X text apps.
http://sourceforge.net/tracker/index.php? func=detail&aid=1964023&group_id=55736&atid=478072
This change is all in pd.tk/u_main.tk so you could easily add your
own bindings, no compiling necessary.
Hmm, good idea, maybe I'll do it another time..
Sounds useful, patches welcome!
.hc
Best,
João Pais
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
actually, if these settings could be controlled by pd itself, it would be
quite easy to make a patch to manage these issues. or then just implement
it on the interface's menus, maybe it makes more sense with the current pd
structure.
great. I can do a pd patch with a GUI to set up these parameters (I just
can't say yet when it will be finished).
But I still think that it would be better if these settings would be read
by pd itself, and loaded through a patch by the user. For example, the
patch I c(w)ould write would output a text file with the pd-theme, and pd
would access this file on startup (then an extra parameter would be added
to pd).
I also think that the settings should at a later point be done in Tcl/Tk
menus, but for now I guess the xxx.pd-theme text file would be enough. An
even more mature option would be a tcl/tk dynamic window/menu with all the
themes stored on the path, and it would only be necessary to click on one
to make it work.
but first things first: if anyone wants really to work in it and has no
hurry, I can start up the "pd theme chooser".
On May 15, 2008, at 1:39 PM, João Pais wrote:
I am thinking of creating 'startup.pd', which would be a pd patch
that is autmoatically loaded by Pd when it is started. Then people
could configure their own settings in the form of a Pd patch, for
things that are more complicated than the preferences allow.
.hc
kill your television
Hans-Christoph Steiner wrote:
I am not sure, if this is really a good solution, it could conflict with the -open statement or patches that people already use on startup. what you want to achieve is really more a settings issue, that has to be set once, but you don't want an annoying startup patch everytime. I am thinking of other programs, where you want to set your own environment, and how that is handled. some programs open up a default new canvas (word, blender...), some show up an "assistant" that asks you what you want to do (?...), but none opens up a document just for settings. maybe your startup.pd should be a patch, called settings.pd and will open when you chose it from the menu - "workspace settings". but write to a settings file. maybe people want different settings for different patches, then the individual settings should be loadable with a [patchsettings theme1] abstraction that you throw into your patch and the argument refers to a "pd style sheet". marius.
On May 15, 2008, at 5:10 PM, marius schebella wrote:
startup.pd would just a way to load/save settings like any other. It
could be easily optional, so if there was no startup.pd, it wouldn't
do anything. I would make it load invisibly, or perhaps it would be
embedded in the Pd window... just ideas at the this point.D
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
simon wise wrote:
don't know what you mean. the settings for vim are in ~/.vimrc and when you type vim, there is what I would call an assistant.
~ VIM - Vi IMproved
~
~ version 7.0.234
~ by Bram Moolenaar et al.
~ Vim is open source and freely distributable
~
~ Become a registered Vim user!
~ type :help register<Enter> for information
~ ~ type :q<Enter> to exit
~ type :help<Enter> or <F1> for on-line help
~ type :help version7<Enter> for version info
marius.
I would expect to be able to send a message like:
[; pd canvas_fill red(
and have it change the patch background instead of manually editing pd.tk, but I get:
pd: unknown message canvas_fill red
on version 0.40.3--extended-20071212. Is/will it be possible?
Martin
This is what is possible now:
http://lists.puredata.info/pipermail/pd-list/2008-05/062202.html
Your message idea sounds worth implementing, if you want to take a
crack at it.
.hc
On May 15, 2008, at 5:12 PM, Martin Peach wrote:
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
nice, I was just looking at it. sys_gui is just fresh, right?
isn't it really possible to make the changes apply automatically? if not,
it's a step in the good direction, but it's still not really great.
Ah, a couple more issues I had somewhere (well, more like details, not
really important): [or was there a feature request link somewhere? I only
know the bug report one]
as before. but if using a dual screen, windows that were saved on the
other screen always appear in the main screen once they're reopened (but
the coordinates match). (I'm on xp, and my main screen on the right side,
if that makes a difference)
that's just a detail, but I get used to divide the screen in a certain way
(also to make sure I'm always controling the console while having my
patches + hdsp mixer open). everytime I open pd I have to drag the window
to the corner of the screen
On May 15, 2008, at 2:22 PM, João Pais wrote:
Please submit a bug report.
Try this:
.hc
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
very nice, thanks.
this and what you just sent before could then be the first stones of the
"startup.pd" patch you mentioned, that would set up the working
environment theme.
would it be possible for startup.pd to be loaded "hidden"? it doesn't
bother me, but some people might find it too complicated when too much
material opens up. for example, another tick box named "xXx" could make
that window appear/disappear.
actually when I start pd I have a patch with my working environment
already popping up - but that's only to list the patches that I'm working
on at the moment, so that they're only a click away. but maybe that's also
interesting to other people as well? so the working features so far could
be pd window position, color theme, favorite files list.
apparently the color scheme gets renewed when Tk "grabs" a window. if I
change the scheme, and also something in the patch, when I try to close
and pd asks to discard changes the color scheme gets updated (but only in
the window that was "activated"). I guess it might be possible to include
a message in sys_gui to bang the windows after a colorscheme message? or
maybe to all open windows?
João
Hmm, I can't reproduce this on Mac OS X 10.4.11/Intel with Pd- extended 0.40.3-20080517
.hc
On May 20, 2008, at 5:47 PM, João Pais wrote:
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
Hmm, I can't reproduce this on Mac OS X 10.4.11/Intel with Pd-extended
0.40.3-20080517
I was playing a bit with it - it also works if a patch/subpatch window is
closed and reopened. but anyway, if possible, an instant implementation
would be the most desirable. only that way it would be possible to make a
psychadelic canvas, yeah!
2 details:
then they'll have the canvas color. if possible, it would make sense to
use the object box color, I guess. but there was no gop parameter, is it
possbile to make one?
just wanted to give notice.
Ah, by the way, on your original patch the msg_nlet parameter was misnamed.
(still on 0.40.3-extended-20080515 XP)
ah, one other thing:
when pasting something that is outside the visible window, the window
arrows don't show up automatically anymore. that is, you get the arrows
only after doing something with the window size (and maybe making it
redraw).
here's a patch to demonstrate this. this happens in both windows and
ubuntu, afair.
it also happens with data structures, when some created graphics are too
big for the window.
João Pais
That bug is fixed on Pd-extended 0.40.3-20080515 on Mac OS X/Intel, I
think it should be fixed on the other platforms as well. I am not
sure whether Miller has accepted that patch yet, but it should be in
the tracker.
.hc
On May 15, 2008, at 1:10 PM, João Pais wrote:
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
David Golightly wrote:
ok, I first tested with 0.40, that did not work, I now tried with 0.41-4 and think your patch is is already a great improvement compared to the current situation. here are some things that you may consider. up down buttons should be beside each other, maybe it is also possible to align buttons, please try to get rid of as many buttons as possible, reduce whatever is not needed. for example, the edit button is not necessary, if you can double click on the path, everybody will understand that. even better would be, if you could edit inside the list without the popup edit line. maybe it is also possible to drag the lines around with the mouse (without up/down buttons). and also click after the last line to add a new path. maybe the add/new could be the last line. or below the last line, or there is an empty line, that you can double click to add a new path. delete could also be a small button beside each line, so that you don't have to select and then click on a button on the right side. (what about multiple select?). add could also be named "new". I immediately tried to resize the window to make it bigger, but resize is not enabled, of course drag and drop from the file manager would be nice. I like that the mouse wheel is working, the scrollbar only changes, if I move the mouse with a certain speed. when I move it slowly, the scrollbar is stuck. also, when I use up / down buttons, then it would be nice it the scrollbar would move according to the position of the selection. since I am on osx, I don't know how to add paths inside the application, which is a bundle. when I click on cancel I get an error in the console: NavGetReply failed, -128 but, it seems to cancel without problems. when I click on the red X to close the window instead of cancel I get an error in a tcl/tk popup: invalid command name "path_cancel" invalid command name "path_cancel" while executing "path_cancel .gfxstub33a690" (command for "WM_DELETE_WINDOW" window manager protocol)
"apply" button and save all settings seem redundant. OK should save. apply might make sense if you want to save, but continue editing (=save, but don't close window). but usually you don't work that long in the path editor to need that functionality. not sure what verbose and "use standard extension are for? after some time I had problems with the mouse focus. maybe because of to much dragging. but a click would select another line as the one the mouse was over. and of course after delete ctrl z for undo would be nice... still, after all I like the improvements so far, and any small improvement is already a lot of work, so thanks!!! marius.
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
I agree.
However, I'm quite warming to chord-less patching a la circle:
http://www.futureaudioworkshop.com/
IMO, this looks like a really nice and well-thought-through UI. Although I am definitely not suggesting Pd should go down that route -- Pd and Circle are two very different beasts!
Jamie