Hi,
what follows is a rant against the new automagic patching in 0.42 that I tried for some time now with the result that I'm looking for a way to switch it off completely as it makes Pd unusable for me as long as it is enforced for every operation.
But first some quick remarks about the latest pd-0.42.3, which I tried from SVN today:
It seems that the very useful feature of finishing object creation with the Return-key has been lost? At least now I cannot use it anymore.
Now comes the rant. ;)
All the automagic has made patching very slow for me. It made it impossible to quickly position an object with the mouse. The "workaround" against automagic with pressing Ctl-A twice is useless in my opinion, and it superfluous anyway as pressing Ctl-E twice had the same effect for years as far as editing is concerned.
I think my main gripe with the new automagic in Pd is that it clashes with the way, Pd has helped me to think about problems in the past.
I believe, that the choice of programming language is deeply connected to the way one likes to think about and contemplate a problem. At least that's why I always stick with the 2-dimensional Pd for "artistic problems" that in my way of thinking naturally fit in a 2-dimensional plane-layout. I prefer 1-dimensional text-languages for certain other problems of the linear "do A, then B" kind.
But now the automagic has made Pd pretty one-dimensional: It tries to enforce one-dimensional, top-to-bottom thinking, which clashes with my preferred free-form thinking and thus feels unnatural. Instead of helping me to think, Pd became an obstacle.
While it is true that most connections in patches go from top to bottom connecting first in/outlets, this doesn't mean that the connections and objects were created in this order. In fact, observing myself (including recording my patching behaviour with "recordmydesktop") I found that I quite often create objects bottom-to-top. You can see me patching here: http://rjdj.me/~fbar/screencast/
As a simple example say I want to build a timebase with a metro and a toggle. I always stupidly create the [metro] first, then the toggle to switch the metro on and off. This is my way of thinking about this problem: I think "Hey, I need some regular bangs so I make a metro" and then "I also need something to switch it on and off".
I do not think the other way around: "Hey, lets create a switch now." and then "Hm, what should I switch on with that new switch? A metro would be fine." The automagic only fits to this second kind of thinking but it is an obstacle to the first kind of thinking.
So now my question: Does anybody know how to get rid of the automagic or bind it to a special keycombo like Ctl-6?
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
monosemous markus
Frank Barknecht wrote:
Hi,
i agree wholeheartedly
fgamsdr IOhannes _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i think i already said these 'enhancements' were just a bad idea from the start ( see the status of desire data )
xiaooo, sevy
IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hi,
i agree wholeheartedly
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think there is a ton of potential to the ideas in desiredata and
things like the new editing tricks in pd-vanilla 0.42. But they also
have the large potential to cause harm to peoples' workflow. I hope
that this experience doesn't scare people off from experimenting with
ideas for improving the editing environment.
That said, I think it is crucial to approach this in an open-ended
manner with lots of people doing a wide range of experimentation.
This is a central reason why I am involved in rewriting the GUI from
scratch for pd-devel. I want to make Pd's GUI easy to modify and
extend. That way we each person can add their own tricks and over
time we'll figure out a grand scheme for how this should be
incorporated into the main distros.
So on that note, I would like to encourage people to get involved with
pd-devel. I just set up nightly builds, so it should be much easier
to try it out. There isn't a lot to see yet, unless you know the
codebase well (the GUI is pure Tcl now, but still rough). But soon
we'll be at the place were it'll be easy to build on top off. Right
now, the next big step that needs to happen is that the various panels
need to be tackled (Pd window, find, send message, preferences, etc.)
.hc
On Jan 27, 2009, at 9:52 AM, ydegoyon@gmail.com wrote:
i think i already said these 'enhancements' were just a bad idea from the start ( see the status of desire data )
xiaooo, sevy
IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hi,
i agree wholeheartedly
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
¡El pueblo unido jamás será vencido!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think there is a ton of potential to the ideas in desiredata and
things like the new editing tricks in pd-vanilla 0.42. But they also
have the large potential to cause harm to peoples' workflow. I hope
that this experience doesn't scare people off from experimenting with
ideas for improving the editing environment.
I agree a lot here. I think, the automagic in 0.42 is the first time, that something like that reached a wider audience. Desire Data was more something cool to look at, but I doubt that many people managed to actually install and use it a lot. Of course I wrote my comments not to get rid of the feature altogether, but to help improving it and pointing out some problems, that only came to my mind after acutally using it. And it's great that you, Chun and the others are working on that part.
Ciao
Frank
On Wed, 28 Jan 2009, Frank Barknecht wrote:
I agree a lot here. I think, the automagic in 0.42 is the first time, that something like that reached a wider audience. Desire Data was more something cool to look at, but I doubt that many people managed to actually install and use it a lot.
Please, please, please, don't make it look like that feature was in desiredata the way it is in vanilla.
And if DesireData ended up not going anywhere, it's my fault. I mean, there were lots of "interesting" hurdles that we had to face, and that slowed us down for sure, but the most "interesting" one by far is that I can't seem to be able to focus properly on the project anymore. After PdConv07 I just took a break and after that I wasn't able to put myself back on the track.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 28 Jan 2009, Frank Barknecht wrote:
I agree a lot here. I think, the automagic in 0.42 is the first time, that something like that reached a wider audience. Desire Data was more something cool to look at, but I doubt that many people managed to actually install and use it a lot.
Please, please, please, don't make it look like that feature was in desiredata the way it is in vanilla.
No, I didn't want to imply that at all, sorry if it sounded like that. Desire Data showed the way how GUI and usability improvements can actually work in Pd. The 0.42 automagic is inspired by that, but still has to learn quite a bit more. And I'm sure it will.
After PdConv07 I just took a break and after that I wasn't able to put myself back on the track.
I guess I know that feeling from my unfinished physics studies. ;) But now I understand more about the value of Fourier transforms than at that time ...
Ciao
Frank
Le 28 janv. 09 à 23:51, Frank Barknecht a écrit :
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 28 Jan 2009, Frank Barknecht wrote:
I agree a lot here. I think, the automagic in 0.42 is the first
time, that something like that reached a wider audience. Desire Data
was more something cool to look at, but I doubt that many people managed to actually install and use it a lot.Please, please, please, don't make it look like that feature was in desiredata the way it is in vanilla.
No, I didn't want to imply that at all, sorry if it sounded like that. Desire Data showed the way how GUI and usability improvements can actually work in Pd. The 0.42 automagic is inspired by that, but still has to learn quite a bit more. And I'm sure it will.
After PdConv07 I just took a break and after that I wasn't able to
put myself back on the track.I guess I know that feeling from my unfinished physics studies. ;) But now I understand more about the value of Fourier transforms than at
that time ...
Me too :) Fourier transform, Nyquist, Shannon, etc. Thanx to Pd world (and the network) that help me to understand that ! ++
Jack
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Wed, 28 Jan 2009, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
After PdConv07 I just took a break and after that I wasn't able to put myself back on the track.
I guess I know that feeling from my unfinished physics studies. ;) But now I understand more about the value of Fourier transforms than at that time ...
But it didn't make you want to go back to finish your degree, isn't it?
Somehow, even if I understand some things better since, it doesn't necessarily make me want to go back on the track. The motivator has to be something else.
"Strangely", at the time of your last mail, I was reading a book on physics. There are things like that, that are quite off-topic for my life as I'm not going to do anything with them. Well, that was one of them.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Tue, 27 Jan 2009, Hans-Christoph Steiner wrote:
I think there is a ton of potential to the ideas in desiredata and things like the new editing tricks in pd-vanilla 0.42. But they also have the large potential to cause harm to peoples' workflow.
In desiredata, the workflow is almost completely backwards-compatible and pretty much everything new is made of new keyboard shortcuts that don't exist in pd. It should be noted that the new automagic is Miller's innovation whereas desiredata put this feature on Ctrl+6 as a proof of concept.
This is a central reason why I am involved in rewriting the GUI from scratch for pd-devel. I want to make Pd's GUI easy to modify and extend.
The GUI is not solely u_main.tk ... even after removing t_tkcmd.c. Plenty of C code is part of the GUI... look at most of the sys_vgui commands: they don't let the client figure out things on its own; they make decisions about the appearance. After all, the g_*.c files are not called "g" for nothing: the "g" stands for graphical or gui.
And the problem with rewriting anything from scratch is that the bigger it is, the longer it is before you have something working properly again, and it's even worse when there's not even a list of features that can tell you what has to be still supported and what's just an artifact of how it's implemented. Pd users have come to depend on the strangest of features. I always thought that gui objects could be made opaque, but in the end, I can't even do that without breaking someone's patches, and then, I can't even change the priority of those gui objects: the object behind has to be the one receiving the clicks! if I change that, it also breaks someone's patches. This is just two examples out of 666.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
I remember you explaining this before Mathieu, and it was with great dismay that I realised DesireData was not to be an alternative to pd-gui, but a complete rewrite of the whole show.
It seems there is a necessary intermediate step by which Pd is properly separated into two truly independent GUI client and sound server code sets.
From this position, it opens the door to all kinds of
alternative GUIs, so long as clear protocols are established for exchange between pd and pd-gui.
On Wed, 28 Jan 2009 15:50:24 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 27 Jan 2009, Hans-Christoph Steiner wrote:
I think there is a ton of potential to the ideas in desiredata and things like the new editing tricks in pd-vanilla 0.42. But they also have the large potential to cause harm to peoples' workflow.
In desiredata, the workflow is almost completely backwards-compatible and pretty much everything new is made of new keyboard shortcuts that don't exist in pd. It should be noted that the new automagic is Miller's innovation whereas desiredata put this feature on Ctrl+6 as a proof of concept.
This is a central reason why I am involved in rewriting the GUI from scratch for pd-devel. I want to make Pd's GUI easy to modify and extend.
The GUI is not solely u_main.tk ... even after removing t_tkcmd.c. Plenty of C code is part of the GUI... look at most of the sys_vgui commands: they don't let the client figure out things on its own; they make decisions about the appearance. After all, the g_*.c files are not called "g" for nothing: the "g" stands for graphical or gui.
And the problem with rewriting anything from scratch is that the bigger it is, the longer it is before you have something working properly again, and it's even worse when there's not even a list of features that can tell you what has to be still supported and what's just an artifact of how it's implemented. Pd users have come to depend on the strangest of features. I always thought that gui objects could be made opaque, but in the end, I can't even do that without breaking someone's patches, and then, I can't even change the priority of those gui objects: the object behind has to be the one receiving the clicks! if I change that, it also breaks someone's patches. This is just two examples out of 666.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Wed, 28 Jan 2009, Andy Farnell wrote:
I remember you explaining this before Mathieu, and it was with great dismay that I realised DesireData was not to be an alternative to pd-gui, but a complete rewrite of the whole show.
Well it was way too late to realise that, I rewrote much of the C code of IEMGUI back in the spring of 2004. DesireData didn't really start in mid-2005, it was a revival of an older project.
It seems there is a necessary intermediate step by which Pd is properly separated into two truly independent GUI client and sound server code sets. From this position, it opens the door to all kinds of alternative GUIs, so long as clear protocols are established for exchange between pd and pd-gui.
Well, it may look like that when you don't mess with the code, but I ask you to ask yourself: what kind of protocol will that be between the client and the server? If you don't touch the server at all, you will have to have clients that accept to be told things in the words that the server is willing to feed them. Would all the clients have to accept Tcl commands from the server, and furthermore, would they all have to accept the same details that the server usually feeds to the client, such as how to draw each piece of each gui object on the canvas?... and that's just the display; the keyboard/mouse is similarly handled much more by the server than by the client.
And then, how many client programmes do you expect? I don't think that it'd take long before people realise that they don't even want two clients for the same server... and if it's the server that handles most of the things that people could be interested in making differently, then what does it buy you to have multiple client programmes?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Wed, 28 Jan 2009, Andy Farnell wrote:
I remember you explaining this before Mathieu, and it was with great dismay that I realised DesireData was not to be an alternative to pd-gui, but a complete rewrite of the whole show.
Well it was way too late to realise that, I rewrote much of the C code of IEMGUI back in the spring of 2004. DesireData didn't really start in mid-2005, it was a revival of an older project.
It seems there is a necessary intermediate step by which Pd is properly separated into two truly independent GUI client and sound server code sets. From this position, it opens the door to all kinds of alternative GUIs, so long as clear protocols are established for exchange between pd and pd-gui.
Well, it may look like that when you don't mess with the code, but I ask you to ask yourself: what kind of protocol will that be between the client and the server? If you don't touch the server at all, you will have to have clients that accept to be told things in the words that the server is willing to feed them. Would all the clients have to accept Tcl commands from the server, and furthermore, would they all have to accept the same details that the server usually feeds to the client, such as how to draw each piece of each gui object on the canvas?... and that's just the display; the keyboard/mouse is similarly handled much more by the server than by the client.
well i guess this is the main problem with how Pd does it right now. i am all in favour of using tcl/tk for drawing the GUI, but not using tcl/tk commands over the wire. i would rather have "Pd-ish" commands. it's gonna be a long road till miller might accept something like this.
that's the reason why i personally am not such a big fan of how the new pd-devel goes: i think it eventually progresses to fast and might end up very similar to desire-data. (being a cool project where people have invested tons of time, but which unfortunately never made it)
fgmadft IOhannes
IOhannes m zmoelnig wrote:
well i guess this is the main problem with how Pd does it right now.
which was not meant to be defeatist. i have no objection (so far :-)) basically on _what_ is communicated between Pd nd Pd-gui. e.g. i don't have any real problems with the server handling mouse-movements and keystrokes (this made peerdata work, after all).
what i would love is, if a simple move (using cursor-keys) of a slected objects would not result in:
pdtk_undomenu .x9f74bf0 motion no .x9f74bf0.c move .x9f74bf0.t9f79510 0 1 .x9f74bf0.c coords .x9f74bf0.t9f79510R 252 117 277 117 277 134 252
134 252 117
.x9f74bf0.c itemconfigure .x9f74bf0.t9f79510R -dash "" .x9f74bf0.c coords .x9f74bf0.t9f79510o0 252 133 259 134 .x9f74bf0.c coords .x9f74bf0.t9f79510i0 252 117 259 118 .x9f74bf0.c coords .x9f74bf0.t9f79510i1 270 117 277 118
but rather
pdtk_undomenu <winID> motion no; <objID> move 0 1;
(with winID being something like x9f74bf0, and objID being e.g. 9f79510)
nothing more is needed.
i just don't want to see _any_ tcl/tk code in _any_ C-file.
fmgasdr IOhannes
On Jan 29, 2009, at 3:56 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
well i guess this is the main problem with how Pd does it right now.
which was not meant to be defeatist. i have no objection (so far :-)) basically on _what_ is communicated
between Pd nd Pd-gui. e.g. i don't have any real problems with the
server handling mouse-movements and keystrokes (this made peerdata
work, after all).what i would love is, if a simple move (using cursor-keys) of a
slected objects would not result in:pdtk_undomenu .x9f74bf0 motion no .x9f74bf0.c move .x9f74bf0.t9f79510 0 1 .x9f74bf0.c coords .x9f74bf0.t9f79510R 252 117 277 117 277 134 252
134 252 117
.x9f74bf0.c itemconfigure .x9f74bf0.t9f79510R -dash "" .x9f74bf0.c coords .x9f74bf0.t9f79510o0 252 133 259 134 .x9f74bf0.c coords .x9f74bf0.t9f79510i0 252 117 259 118 .x9f74bf0.c coords .x9f74bf0.t9f79510i1 270 117 277 118
but rather
pdtk_undomenu <winID> motion no; <objID> move 0 1;
(with winID being something like x9f74bf0, and objID being e.g.
9f79510)nothing more is needed.
i just don't want to see _any_ tcl/tk code in _any_ C-file.
The current structure of pd-devel is as it is because I think the key
to success is to tackle this problem one step at a time. DesireData
is a huge leap away from the current structure. DD's structure is a
good idea, but it was too dramatic a change, perhaps.
Anyway, what I am currently working on, and have basically working, is
making the GUI 100% Tcl. It is now 100% Tcl, it is just not 100%
working yet ;). It is now (barely) usable and there are now nightly
builds of pd-devel-extended.
About your example, I think that we definitely should address things
like that. But part of the mandate that Miller, you and others have
laid out for pd-devel is that it should not change the C code or the
current API. That means your example is definitely not going to
happen in this stage of the development.
That said, it would not be hard to reduce the above commands to
succinct messages using Tk's tagging and the "move" command. Then the
selection would tag everything, then you only need a single move
command to apply to that tag. This then could easily be converted to
Pd messages. So it seems to be that this should be a two stage process
First things first, this pd-devel GUI needs to get included in
vanilla, so we need to stick to those guidelines laid out by Miller.
And Miller, any feedback that you can offer would be most appreciated.
.hc
fmgasdr IOhannes _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess himself
of it. - Thomas Jefferson
sorry if it is a stupid quetion... This complete Tcl GUI is complete since which Pd version? ze
Hans-Christoph Steiner escreveu:
Anyway, what I am currently working on, and have basically working, is
making the GUI 100% Tcl. It is now 100% Tcl, it is just not 100%
working yet ;). It is now (barely) usable and there are now nightly
builds of pd-devel-extended.About your example, I think that we definitely should address things
like that. But part of the mandate that Miller, you and others have
laid out for pd-devel is that it should not change the C code or the
current API. That means your example is definitely not going to
happen in this stage of the development.That said, it would not be hard to reduce the above commands to
succinct messages using Tk's tagging and the "move" command. Then the
selection would tag everything, then you only need a single move
command to apply to that tag. This then could easily be converted to
Pd messages. So it seems to be that this should be a two stage processFirst things first, this pd-devel GUI needs to get included in
vanilla, so we need to stick to those guidelines laid out by Miller.
And Miller, any feedback that you can offer would be most appreciated..hc
On Thu, 29 Jan 2009, padovani wrote:
sorry if it is a stupid quetion... This complete Tcl GUI is complete since which Pd version?
He doesn't mean the whole GUI, he just means the client-side.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
It is in the pd-devel 0.41.4. It is barely alpha quality, but its
developing fast.
.hc
On Jan 29, 2009, at 5:16 PM, padovani wrote:
sorry if it is a stupid quetion... This complete Tcl GUI is complete
since which Pd version? zeHans-Christoph Steiner escreveu:
Anyway, what I am currently working on, and have basically working,
is making the GUI 100% Tcl. It is now 100% Tcl, it is just not
100% working yet ;). It is now (barely) usable and there are now
nightly builds of pd-devel-extended.About your example, I think that we definitely should address
things like that. But part of the mandate that Miller, you and
others have laid out for pd-devel is that it should not change the
C code or the current API. That means your example is definitely
not going to happen in this stage of the development.That said, it would not be hard to reduce the above commands to
succinct messages using Tk's tagging and the "move" command. Then
the selection would tag everything, then you only need a single
move command to apply to that tag. This then could easily be
converted to Pd messages. So it seems to be that this should be a
two stage processFirst things first, this pd-devel GUI needs to get included in
vanilla, so we need to stick to those guidelines laid out by
Miller. And Miller, any feedback that you can offer would be most
appreciated..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 Tue, 27 Jan 2009 12:01:24 +0100 Frank Barknecht fbar@footils.org wrote:
I quite often create objects bottom-to-top.
This is the natural way to do it if you are working from an equation or functional representation, someting of the general form
f(t) = x + y * z
leads to an natural object placement ordering
output (first object, 1) = x term/last object of left branch (2) plus (3), y term/last object of middle branch (4), times (5), z term/last object of rightmost branch. You then factor up the x, y and z parts making a DSP tree from the root (output) towards terminal/leaf (signal source) nodes.
Automatic downwards connection must be easily toggled so beginner and advanced programming styles are accomodated.
i haven't tried this new version of pd yet, but i know that if i did, i would agree with the comments above.
Hallo, hard off hat gesagt: // hard off wrote:
i haven't tried this new version of pd yet, but i know that if i did, i would agree with the comments above.
Try it! It contains lots of useful new stuff like pow~ and bugfixes and I'm sure the automagic will evolve into a useful feature with a bit of reworking and added flexibilty.
To get rid of the automagic the hard way, change line 140 in g_text.c from
int connectme = (x->gl_editor->e_selection &&
to
int connectme = 0;
But first you should try it yourself, maybe you like it the way it is.
Ciao
Frank
-
Andy Farnell -
brandt＠subnet.at -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Jack -
Mathieu Bouchard -
padovani -
ydegoyon＠gmail.com