here's some info because Tim prefers to have this stuff on the list, as we're talking about making nontrivial changes to devel_0_39.
---------- Forwarded message (ABRIDGED) ---------- Date: Mon, 8 Aug 2005 20:08:46 +0200 From: Tim Blechmann TimBlechmann@gmx.de To: Mathieu Bouchard matju@artengine.ca Subject: Re: pure devil
Mathieu Bouchard wrote: BTW In PureData Montréal #3 I made a joke that in devel_0_37, "devel" was merely two bits away from "devil", and that radioactive cats have 18 halflives, and 18*37 = 666. ;-) For extra names I have "DesireData" and "SchemaData", both of which are wordplays on words in latin (respectively, "desiderata" and "schemata"). I have more names but I don't think they're as good as the two above.
well, i disagree with knuth ... we should get some code done before renaming it ;-)
Two weeks after writing the above I've had Chun Lee sending me some of his work on a new GUI. We have decided to call it DesireData, and I've teached him how to commit to cvs, so now there is pd/src/desire.tk in devel_0_39.
His stuff doesn't work, but is the basis of a GUI separated from Pd in a way that IMPD was supposed to be and never was.
i had a brief look an the file ... seemed to be some fancy kind of pd's gui ... but i missed some kind of introduction ... he did not post anything to the lists. if we work on a project we should try to make sure that everyone knows, what the other ones are doing ... and that we agree on something ...
[...]
Yup. When would you like to have that meeting?
maybe we should announce an informal pure dev[ei]l meeting
What about next Friday, the 12th ?
if we do it a week later it's better for me ... i'm probably moving next week to a place with internet connection ...
Ok, but I still should start adding my changes to devel_0_39 ASAP, right ?
yes ...
Still not done... and I have to work on alx's big project for the museum (the exhibition opens up in six weeks from now). That won't be full time work though, so I will be able to work on devel_0_39 too.
well, as you know, i'm a fan of communication, so we should try to discuss on the lists when doing non-trivial changes ;-)
On Mon, 8 Aug 2005, Tim Blechmann wrote:
Mathieu Bouchard wrote:
For extra names I have "DesireData" and "SchemaData", both of which are wordplays on words in latin (respectively, "desiderata" and "schemata"). I have more names but I don't think they're as good as the two above.
well, i disagree with knuth ... we should get some code done before renaming it ;-)
Well, it depends on how much "done" you want it to be... and then we better have a filename before committing to CVS... so that's exactly when we decided on a name.
i had a brief look an the file ... seemed to be some fancy kind of pd's gui ... but i missed some kind of introduction ...
Ok, his project is to make something that is suitable as a Pd GUI but runs independently from Pd. My project is to connect his work to Pd with these goals in decreasing priority order:
1. disable all C code that refers directly to Tk 2. disable almost all C code that refers directly to Tcl 3. do that by adding the least amount of code possible
he did not post anything to the lists.
His project is an outgrowth of impd_0_37 and I've often threatened to move that code over to devel_0_39, so you've been warned quite a few times. However I could have written about the changes in the design of impd/desire that have occurred in my head since PdConvention04...
if we work on a project we should try to make sure that everyone knows, what the other ones are doing ... and that we agree on something ...
I agree, and acting upon that idea, I just posted those mails to devel_0_39 for all to see.
if we do it a week later it's better for me ... i'm probably moving next week to a place with internet connection ...
Oh =) Sure.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo!
here's some info because Tim prefers to have this stuff on the list, as we're talking about making nontrivial changes to devel_0_39.
thanks for sharing the interesting discussion ... :)
oh ... btw, what do you think of _completely_ separating dsp core and gui? basically kicking out all of pd's gui ...
yes, yes... just started to do the same thing (but didn't post to the list yet, because have not much time at the moment - but I will continue in september or so ...)
i'm suggesting this, since georg holzmann from graz wants to start with a qt gui, you're going to work on a tcl gui, thomas grill is working on an opengl gui ... so i'm thinking of a libpd, that can work with all different guis ...
I want to allow multiple GUI engine, and even, several GUIs at the same time... as long as no-one wants to use the old GUI, that we keep for compatibility with anything that happens to not work with the desire.tk GUI. My idea of it is like this:
In devel_0_39, you can pick between (1) old Pd GUI (2) new Pd GUI, in which the server gets started first, and then zero-or-more clients get started, in: (2.1) DesireData (2.2) Georg's Qt GUI (2.3) Mamalala's Qt GUI (2.4) Thomas Grill's OpenGL GUI (2.5) Carmen's Tcl/TkZinc/OpenGL GUI
Those are separate processes, so they don't need to be linked to Pd, and anyway in all of situation (2), the GUI code of the server side gets replaced by just a stub that can accept anything.
sounds great ...
good to hear that we can combine all the efforts ...
some notes to the Qt GUI:
it will be based on Christian Klippel's (Mamalala) karma GUI - ported to Qt4 and some more features ... We also discussed about maybe an embedded (rewritten) Qt-Designer in the patch-editor - where you should be able to build custom guis (and interpret the .ui files - or "compile" GUI-libraries for better performance) ... ... and of course additional features like a property-editor for all objects, alpha-blending, zooming in patches, layers for the GUI-objects (like in graphic-programs), qt undo/redo framework, maybe buildin state saving of all object with interpolation beween states, a lot of custom canvas items (polygons, ellipse, images, ... - to maybe build 2D-games;), ...
We already did some discussions on how to interface with pd ... propably with a proxy object, which catches all the signal&slot stuff from Qt and communicates with the "pd engine" ...
Anyway, the important thing is, i think, to seperate the "pd engine" (or libpd) from the GUI part - indepedent of which Qt, OpenGl, Tcl ... GUI we might use in future ... and it's good to hear that there are some people interested in that ... :)
LG Georg
Hi,
Just some notes about GUI stuff...
QT designer built into the patch-editor so that one draws GUIs in the patcher just like one draws the patch itself? wow. I'm not familar with QT does the designer allow you to create more abstract items other than the usual widgets? (for example drawing something like Yves grid without using buttons or anything? I think there is something to be said for the vector style of PD that I don't see often used in "normal" GUI design.)
What would alpha-blending be for? (except for some visual parameter for user-feedback or as an element in a custom gui object. I wonder what a transparent object or patch would represent in the patcher?
I'm not sold on the Zoomer idea. If anyone has used eyeweb what they have done is removed all nesting (abstractions and subpatches) and replaced with with the ability to zoom into a big mess. I've never had a case where I needed to see better what is happening up-close. Maybe when I was connecting many patch cords to many inlets, but that was the fastest way to do it once. What is the rational behind zooming in the patch? (other than the ability to have the choice to make one giant web of mess and be able to zoom into different regions of it.
Layers is also though for me. Are we thinking of arranging objects/connections on multiple planes as another method of not using nesting well as creating a multi-dimentional web-o-mess? Perhaps if this idea was made so restrictive that a performance (run) mode hides the patch and the edit mode hides the gui.. but this causes all kinds of trouble, not to mention making the performance process seperate from the patching process (and I'm sure we almost all swap back in forth in many performances). How could the layers be connected to one and other using connections?
To put it another way, I don't see the difference between nesting (abstraction/subpatch) and using layers or zooming. Creating a new layer, making it visible and adding objects, then hiding it again and working somwhere else is analagous to opening a abstraction/subpatch working in it and closing it. Zooming is just the same except there are no inlet/outlet objects to broker the communication to the outside patch.
State-saving for parameters is a great idea. I wonder how to make it as patch like as possible. That is to have the ability to hack the most diversity of interpolation algos, from lop~ to line, line~, line2, line3, pmpd and even a circular line. State-saving sounds great. :)
Clearly I would put state-saving and possibly interpolation way ahead of layers and zooming, but thats me.
B.
Georg Holzmann wrote:
it will be based on Christian Klippel's (Mamalala) karma GUI - ported to Qt4 and some more features ... We also discussed about maybe an embedded (rewritten) Qt-Designer in the patch-editor - where you should be able to build custom guis (and interpret the .ui files - or "compile" GUI-libraries for better performance) ... ... and of course additional features like a property-editor for all objects, alpha-blending, zooming in patches, layers for the GUI-objects (like in graphic-programs), qt undo/redo framework, maybe buildin state saving of all object with interpolation beween states, a lot of custom canvas items (polygons, ellipse, images, ... - to maybe build 2D-games;), ...
Hallo!
QT designer built into the patch-editor so that one draws GUIs in the patcher just like one draws the patch itself? wow. I'm not familar with QT does the designer allow you to create more abstract items other than the usual widgets? (for example drawing something like Yves grid without using buttons or anything? I think there is something to be said for the vector style of PD that I don't see often used in "normal" GUI design.)
yes of course - you can't use the PD designer as it is ... (o.k. you can use it for dialogs etc...) - it was just a thought I discussed with Christian and this would need of course a lot of plugins for the designer - or a reimplementation of parts of the designer ...
What would alpha-blending be for? (except for some visual parameter for user-feedback or as an element in a custom gui object. I wonder what a transparent object or patch would represent in the patcher?
it's only a visual parameter - I encountered that it can be handy if e.g. a slider is transparent (in a specific state) and e.g. if the slider becomes important you can increase the alpha value ... (so just for visual feedback ...)
fastest way to do it once. What is the rational behind zooming in the patch? (other than the ability to have the choice to make one giant web of mess and be able to zoom into different regions of it.
maybe if you have a group of objects and you want them to be smaller ... (because they are not so important for now ...)
but anyway, every property (like alpha, rgb, Layer, size=zooming, position, font, ...) can be handled with the Qt-Property system - so it is independet of the representation of the object in the "pd engine" ...
performances). How could the layers be connected to one and other using connections?
okay - I meant it much more simple ... (maybe layer is the wrong word for it ?) on a Qt Canvas you can give each item a property (I think an integer) if it is in front or in back - so e.g. if you want a red rectangle in front of a black rectangle ... (now you need to create the read rectangle after the black one ...)
State-saving for parameters is a great idea. I wonder how to make it as patch like as possible. That is to have the ability to hack the most diversity of interpolation algos, from lop~ to line, line~, line2,
yes - it should be as patch like as possible ... but this could be made (again) with the Qt property system: if you have a pd object to get and set all the properties of an object you can make state saving and interpolation etc. in PD itself ... (of course this is also now the case with the iem guis ...) But you need a lot of messages (if you e.g. work with rradical) - so we could of course also make the state saving/interpolation directly in Qt - this would mean that the "pd engine" wouldn't be involved - but I don't know if that is a good idea ...
LG Georg
Hi Georg,
Thanks for clarifying things.
Transparency is indeed valuable for visual feedback. (Actually I'm wishing we can have nice real-time blurring one day so that that could also be used for visual feedback.
I understand what you mean by layers now. Actually in tk the canvas widget is the same, each object has a stacking order. I guess what your saying is the ability to add things like "raise" and "lower" to change the stacking? Damn this could be handy for putting a canvas in the background "send to back" actually this is totally doable in tcl/tk, I never thought of it. Is this worth pursuing even for Miller's gui?
Interesting to do the interpolation state-saving in the GUI part only. I suppose this would lead to some lack of flexibilty if we wanted to change the type of interpolation from the PD engine side.. based on midi controllers or something... hmmm
Talking to Matieu and Chrisian on IRC I was thinking it would be great to have a human readable interface between the GUI and PD. Rather some middle ware that would convert the fast internal format to something that would be useful for dynamic scripting (ala dyn, pd messages) but also odd stuff like HC's serindipidy, converting webforms directly to a patch creation, all that magic glue.. making custom (installation specific) interfaces to PD easier and as powerful as the GUI itself.
B.
Georg Holzmann wrote:
Hallo!
QT designer built into the patch-editor so that one draws GUIs in the patcher just like one draws the patch itself? wow. I'm not familar with QT does the designer allow you to create more abstract items other than the usual widgets? (for example drawing something like Yves grid without using buttons or anything? I think there is something to be said for the vector style of PD that I don't see often used in "normal" GUI design.)
yes of course - you can't use the PD designer as it is ... (o.k. you can use it for dialogs etc...) - it was just a thought I discussed with Christian and this would need of course a lot of plugins for the designer - or a reimplementation of parts of the designer ...
What would alpha-blending be for? (except for some visual parameter for user-feedback or as an element in a custom gui object. I wonder what a transparent object or patch would represent in the patcher?
it's only a visual parameter - I encountered that it can be handy if e.g. a slider is transparent (in a specific state) and e.g. if the slider becomes important you can increase the alpha value ... (so just for visual feedback ...)
fastest way to do it once. What is the rational behind zooming in the patch? (other than the ability to have the choice to make one giant web of mess and be able to zoom into different regions of it.
maybe if you have a group of objects and you want them to be smaller ... (because they are not so important for now ...)
but anyway, every property (like alpha, rgb, Layer, size=zooming, position, font, ...) can be handled with the Qt-Property system - so it is independet of the representation of the object in the "pd engine" ...
performances). How could the layers be connected to one and other using connections?
okay - I meant it much more simple ... (maybe layer is the wrong word for it ?) on a Qt Canvas you can give each item a property (I think an integer) if it is in front or in back - so e.g. if you want a red rectangle in front of a black rectangle ... (now you need to create the read rectangle after the black one ...)
State-saving for parameters is a great idea. I wonder how to make it as patch like as possible. That is to have the ability to hack the most diversity of interpolation algos, from lop~ to line, line~, line2,
yes - it should be as patch like as possible ... but this could be made (again) with the Qt property system: if you have a pd object to get and set all the properties of an object you can make state saving and interpolation etc. in PD itself ... (of course this is also now the case with the iem guis ...) But you need a lot of messages (if you e.g. work with rradical) - so we could of course also make the state saving/interpolation directly in Qt
- this would mean that the "pd engine" wouldn't be involved - but I
don't know if that is a good idea ...
LG Georg
Hallo!
Transparency is indeed valuable for visual feedback. (Actually I'm wishing we can have nice real-time blurring one day so that that could also be used for visual feedback.
what do you mean with real-time blurring ?
widget is the same, each object has a stacking order. I guess what your saying is the ability to add things like "raise" and "lower" to change the stacking? Damn this could be handy for putting a canvas in the
yes ...
background "send to back" actually this is totally doable in tcl/tk, I never thought of it. Is this worth pursuing even for Miller's gui?
yes - at least I need it quite often ...
Interesting to do the interpolation state-saving in the GUI part only. I suppose this would lead to some lack of flexibilty if we wanted to change the type of interpolation from the PD engine side.. based on midi controllers or something... hmmm
yes - I also don't know if it's a good idea ...
Talking to Matieu and Chrisian on IRC I was thinking it would be great to have a human readable interface between the GUI and PD. Rather some middle ware that would convert the fast internal format to something that would be useful for dynamic scripting (ala dyn, pd messages) but also odd stuff like HC's serindipidy, converting webforms directly to a patch creation, all that magic glue.. making custom (installation specific) interfaces to PD easier and as powerful as the GUI itself.
good idea - this would require something like a scripting language between the GUI and PD ? (I think I can remember a similar discussion some time ago ... and I think tim said this would be too slow ... )
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Ben:
Interesting to do the interpolation state-saving in the GUI part only. I suppose this would lead to some lack of flexibilty if we wanted to change the type of interpolation from the PD engine side.. based on midi controllers or something... hmmm
yes - I also don't know if it's a good idea ...
Generally I think, that binding or limiting states to GUI objects is not a good thing. At least that was one of the design goals with rradical: It should be possible to "save everything", not just the state of a slider or a numberbox or a canvas color. However a way to *query* a GUI object or any object for its state would be very useful to have, so that the collection of a part of a state's data could be made easier.
The latest Max version has this interesting "pattr" object collection (see http://www.synthesisters.com/download/Max45ReferenceManual.pdf) which is remarkably similar in some areas to Memento. It also includes "autopattr" which automatically collects every variable in a patcher's objects. Something like this could be useful to have in Pd, too.
Ciao
On Wed, 10 Aug 2005, Georg Holzmann wrote:
good idea - this would require something like a scripting language between the GUI and PD ?
you mean like TCL ?
(I think I can remember a similar discussion some time ago ... and I think tim said this would be too slow ... )
TCL is currently not too slow. What's slowest is TK's canvas itself, and that the server sends too many updates to the client.
I think I said that when Tim said this would be too slow, if he said that.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
TCL is currently not too slow. What's slowest is TK's canvas itself, and that the server sends too many updates to the client.
I think I said that when Tim said this would be too slow, if he said that.
well, the big problem is not the speed of the gui, but the speed of the communication between dsp core and gui ...
i don't care, if the gui takes 5 minutes to update the display of a 5 minutes buffer, unless i have a 5 minutes audio dropout ;-)
of course, if we would have a single process, multi-threaded pd without any socket communication, we wouldn't have to send data over a socket connection, that kills latency ... inter-thread communication is _much_ faster than inter-process communication using a network socket ...
but i'm not a gui programmer ...
cheers ... tim
On Wed, 10 Aug 2005, Georg Holzmann wrote:
okay - I meant it much more simple ... (maybe layer is the wrong word for it ?) on a Qt Canvas you can give each item a property (I think an integer) if it is in front or in back - so e.g. if you want a red rectangle in front of a black rectangle ... (now you need to create the read rectangle after the black one ...)
The way it is in Tk is that every canvas-element is either at the front or back or another one, such that if both are made to overlap, it is certain which one will be on the top of the other. I think that feature of Qt Canvas is equivalent to that one of the Tk Canvas.
I would like to make this more directly configurable by the user but I don't know of a good UI for doing this. jMax had "raise/lower" contextual-menu options but I never really knew what those were doing. Maybe I'm a detail-obsessed control-freak but when I raise an object I wonder up to which level it gets raised: on top of everything else in the patch? just on top of every object it was overlapping with ? How can I see that ordering ? (short of opening the .pd file in a text editor) And how can I set the ordering myself in an explicit way in a way not too hard to handle ?
Despite the plain raise/lower commands being less than ideal, I advocate adding them to Pd. It sure is better than the Cut+Paste hacks that we're forced to do to put the [cnv] objects under other objects.
BTW, did I say that I hate that [cnv] gets confused with the other canvas object, and how it gets used for purely æsthetical reasons? It should be called another name, like [dumb_rectangle], but it seems like it's too late.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
hello,
Am Dienstag 16 August 2005 22:31 schrieb Mathieu Bouchard:
On Wed, 10 Aug 2005, Georg Holzmann wrote:
okay - I meant it much more simple ... (maybe layer is the wrong word for it ?) on a Qt Canvas you can give each item a property (I think an integer) if it is in front or in back - so e.g. if you want a red rectangle in front of a black rectangle ... (now you need to create the read rectangle after the black one ...)
The way it is in Tk is that every canvas-element is either at the front or back or another one, such that if both are made to overlap, it is certain which one will be on the top of the other. I think that feature of Qt Canvas is equivalent to that one of the Tk Canvas.
yes, it does. and its not an integer, but a double that is used for this in qt. thats what i use to draw the in/outlets _above_ the object they belong to: when the object is, lets say, z=5, the in/outlets are at z=5.1
I would like to make this more directly configurable by the user but I don't know of a good UI for doing this. jMax had "raise/lower" contextual-menu options but I never really knew what those were doing. Maybe I'm a detail-obsessed control-freak but when I raise an object I wonder up to which level it gets raised: on top of everything else in the patch? just on top of every object it was overlapping with ? How can I see that ordering ? (short of opening the .pd file in a text editor) And how can I set the ordering myself in an explicit way in a way not too hard to handle ?
usually raise/lower should do that for only one step. if z=5, after raise, it should be z=6. then there should be "bring to front / send to back" to put them on the topmost/bottom-most z-coordinate.
having that setable in the properties is of course a good idea.
Despite the plain raise/lower commands being less than ideal, I advocate adding them to Pd. It sure is better than the Cut+Paste hacks that we're forced to do to put the [cnv] objects under other objects.
there could be also the function that a raise, for example, when applied to a group of selected objects, the objects will be raised above the top-leftmost one. lets say we have 3 objects selected, with z= 5, 1, and 9, whereas the top-left selected is the z=5, they should be z=5,6,7. same for lower, but just in the other direction, of course.
on a side-note: i found the functionality to arrange/line-up objects in jmax pretty handy: you select a bunc of objects, ctrl-left would them all move to the left to have the left sides lined up with the left side of the leftmost object.
in addition to that, something like "spread" would be cool to, so that you have a bunch of randomly placed objects, and can "spread" them in a way that they are all in-line, with a given space between each object.
greetings,
chris
BTW, did I say that I hate that [cnv] gets confused with the other canvas object, and how it gets used for purely ?sthetical reasons? It should be called another name, like [dumb_rectangle], but it seems like it's too late.
ok... added a 'dumb' attribute...just select some rects and change dumb to 1, in the inspector: http://whats-your.name/pd/dumb.PNG
Hallo, ix@replic.net hat gesagt: // ix@replic.net wrote:
called another name, like [dumb_rectangle], but it seems like it's too late.
ok... added a 'dumb' attribute...just select some rects and change dumb to 1, in the inspector: http://whats-your.name/pd/dumb.PNG
Maybe I'm spoiled by the hordes of Catholics that currently besiege my house (I live in Cologne 12 meters from the second largest church in town) but I think this is hilarious! ;-)
Ciao
On Tue, 9 Aug 2005, B. Bogart wrote:
the usual widgets? (for example drawing something like Yves grid without using buttons or anything? I think there is something to be said for the vector style of PD that I don't see often used in "normal" GUI design.)
Since a long time it struck me as strange that in so many (almost all) GUI toolkits there are essentially two different systems that don't mix that well: what's inside the canvas vs what's outside of the canvas... I mean when there's even a canvas class worth something (e.g. in Tk).
But there *are* GUI toolkits in which everything is built on top of vector graphics: Fresco (aka Berlin), Genera (the old LISP OS), Squeak (a brand of Smalltalk)... well, that's off the top of my mind anyway.
Maybe it's just the long heritage of MacOS 1 which wasn't as much designed to be flexible as to be able to run within 1/8th of a meg of RAM including the apps. Then the inertia caught on somewhere, and then all the cross-platform craze froze GUI design solid because cross-platform means you have to build your design around the weakest of your target platform, or even worse ("least common denominator").
I'm not sold on the Zoomer idea. If anyone has used eyeweb what they have done is removed all nesting (abstractions and subpatches) and replaced with with the ability to zoom into a big mess.
Technically, PureData could do very well without subpatches, but without abstractions it would just not be PureData. However I don't even recommend removing the subpatch concept, and I don't think that the zooming stuff implies any of that, nor that its main use would even be to make larger patches without having to use scrollbars.
I've never had a case where I needed to see better what is happening up-close.
1. When the pointer device you are using is imprecise, you can't even hit an inlet 90% of the time. For example, ever tried patching on a touchscreen?
2. When the display is small or far away and the resolution makes pixels appear too small, I often can't even read what's on the screen. Not all versions of Linux make it quick to switch resolutions, and sometimes it's even just better to not mess with resolutions (e.g. most non-CRT displays, like on laptops and projectors)
3. When an object has been designed too small. Sometimes you just don't want to use Properties to reconfigure it as bigger, e.g. because it's inside a GOP abstraction that you don't want to mess with. Instead of resizing it you can now just zoom it instead.
Maybe when I was connecting many patch cords to many inlets, but that was the fastest way to do it once.
Even for one patch cord to one inlet it's faster because the target you are dragging to is bigger. And the target you are dragging from, the outlet, is bigger as well. Bigger targets are faster to click on because they're easier to reach.
other than the ability to have the choice to make one giant web of mess and be able to zoom into different regions of it.
Some people already make huge patches using scrollbars because of some assumed notion that the existence of scrollbars justifies their use - any use of them... and even that because scrollbars exist, then more space must be put between objects so that patches take more space so that one more feature of PureData gets used. It's like consumer society: we have a duty to eat bread in order to justify the baking of the bread. It's for the Economy. Except that, to make matters worse, the scrollbar feature of PureData doesn't have a market value. Whip me.
So I think we should abolish scrollbars. Or should we? (I'm kidding, but just because I am doesn't mean I'm not making a point.)
not to mention making the performance process seperate from the patching process (and I'm sure we almost all swap back in forth in many performances).
In performances I already have my left hand resting on Ctrl+E most of the time, just in case I need it, and that's because I need it often.
IIRC, Carmen advocates the abolition of the Run/Edit mode. I say that if this becomes a reality, then other things have to change. There prolly aren't enough keyboard shortcuts and key modifiers that we can rely on being available all of the time (laptop keyboards are small)... and then, dragging a numberbox without holding modifiers should do what exactly? The same as current Run-Mode, or the same as current Edit-Mode ?
I suggested other things, like adding a different, more accessible shortcut for Edit/Run toggling -- e.g. Escape or even CapsLock. The Ctrl+E powerchord is more complex for the hand and doing too quick often leads to Ctrl+W instead (been there done that).
diversity of interpolation algos, from lop~ to line, line~, line2, line3, pmpd and even a circular line.
"A circle is a round straight line with a hole in the middle." -- unknown author (presumably after too much topology)
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
I'm not sold on the Zoomer idea. If anyone has used eyeweb what they
removing the subpatch concept, and I don't think that the zooming stuff implies any of that, nor that its main use would even be to make larger
like creating a duplicate view of a canvas, shrinking it to a fraction of the original size, locking 'zoom to fit' and using it as an overview. or zooming the selected objects (associated with data-structs) for instant timestretch. or displaying a subpatch/abstraction as GOP but mouseover + press the 'tab' key, and it zooms to fill the window, obliterating the need for a window manager entirely..
"Zoom"...dont knock it till youve tried it..
- When the pointer device you are using is imprecise, you can't even hit an inlet 90% of the time. For example, ever tried patching on a touchscreen?
or a trackpoint, ball mouse, vnc/rdesktop. do you have any suggestions... auto-zoom the objects on mouseover, a la the MacOSX "Dock" ?
more feature of PureData gets used. It's like consumer society: we have a duty to eat bread in order to justify the baking of the bread.
eh..you mean starvin would 'really show that consumer society' ?
So I think we should abolish scrollbars. Or should we? (I'm kidding, but just because I am doesn't mean I'm not making a point.)
well, i abolished scrollbars in my PD GUI, as documented at http://whats-your.name/pd/
IIRC, Carmen advocates the abolition of the Run/Edit mode. I say that if this becomes a reality, then other things have to change. There prolly aren't enough keyboard shortcuts and key modifiers that we can rely on being available all of the time (laptop keyboards are small)... and then, dragging a numberbox without holding modifiers should do what exactly? The same as current Run-Mode, or the same as current Edit-Mode ?
gave in and added a 'performance mode' toggle (Esc key), but for objects that just interpret a single input type (say button-1) it shouldnt be necessary. which is what, all of the originals+iemgui? id maybe prefer 'normally click moves, unless the object interprets mouse input' but that would be inconsistent: hold shift to move a slider, but don't when moving an objbox or rect..so i guess user-settable pref is on order here..
I suggested other things, like adding a different, more accessible shortcut for Edit/Run toggling -- e.g. Escape or even CapsLock. The Ctrl+E powerchord is more complex for the hand and doing too quick often leads to Ctrl+W instead (been there done that).
yep, my PD GUI uses Esc... but i should stop calling it a PD GUI, since it can only be used via netsend right now (HINT HINT!! ;) c
On Mon, 15 Aug 2005 ix@replic.net wrote:
- When the pointer device you are using is imprecise, you can't even hit an inlet 90% of the time. For example, ever tried patching on a touchscreen?
or a trackpoint, ball mouse, vnc/rdesktop. do you have any suggestions... auto-zoom the objects on mouseover, a la the MacOSX "Dock" ?
Fisheye view: the centre of the patch looks bigger than the periphery... And by centre I mean centre of attention, which the user gets to pick.
more feature of PureData gets used. It's like consumer society: we have a duty to eat bread in order to justify the baking of the bread.
eh..you mean starvin would 'really show that consumer society' ?
heh. No, I was paraphrasing Bertrand Russell who was writing about that in the 1920's. He meant (I believe) that in a society of abundance, needs have to be invented in order to keep a high level of employment. If people slow down on spending then the economy enters a recession.
well, i abolished scrollbars in my PD GUI, as documented at http://whats-your.name/pd/
I see. You are replacing them by exclusive usage of the scrollwheel?
that would be inconsistent: hold shift to move a slider,
Hey. The shift key is reserved for adding to a selection. Well, I see that you have changed that as well, but I think that the use of the shift key for doing that is pretty standard. I'd prefer not to touch that.
so i guess user-settable pref is on order here..
Right.
yep, my PD GUI uses Esc... but i should stop calling it a PD GUI, since it can only be used via netsend right now (HINT HINT!! ;)
mea culpa.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
hi,
now i also need to add my grain of salt to this thread.
- When the pointer device you are using is imprecise, you can't
even hit an inlet 90% of the time. For example, ever tried patching on a touchscreen?
or a trackpoint, ball mouse, vnc/rdesktop. do you have any suggestions... auto-zoom the objects on mouseover, a la the MacOSX "Dock" ?
Fisheye view: the centre of the patch looks bigger than the periphery... And by centre I mean centre of attention, which the user gets to pick.
the problem with fisheye view: it never works. basically you can try it out in the dock. the reason why it does not work lies in the fact that the area that gets bigger _always_ moves away from the curser when it does so. thus, the user clicks at the icon beside the highlighted. try it out. it sucks.
well, i abolished scrollbars in my PD GUI, as documented at http:// whats-your.name/pd/
I see. You are replacing them by exclusive usage of the scrollwheel?
one more solution would be to implement a "hand" as in quark xpress. i like scrollbars more.
so i guess user-settable pref is on order here..
Right.
user settable prefs are shifting the responsibility to the user. most users will not set them thus a reasonable default has to be chosen. they are an addition more than a solution.
lg martin
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
I suggested other things, like adding a different, more accessible shortcut for Edit/Run toggling -- e.g. Escape or even CapsLock. The Ctrl+E powerchord is more complex for the hand and doing too quick often leads to Ctrl+W instead (been there done that).
Because my new laptop has this nasty "Fn" key where normally the "Ctrl" key belongs, I have made CapsLock an additional Ctrl-key, which I think is much more comfortable to use. Only problem is, that at work we use Windows and instead of saving a Word document I now SHOUT TOO MUCH IN MY TEXTS until I recognize my mistake ...
To those who want to try this at home: Apart from xmodmap tricks, you can also use this in XF86Config/xorg.conf:
Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" # ... # Make CapsLock an additional Control Option "XKbOptions" "ctrl:nocaps" EndSection
Regarding quicker and more ergonomic editing: I have seen people who really have problems hitting inlets or outlets with the mouse pointer. *Real* problems. One partial solution to this would be to allow more ways to create connections. One way is the way I use in my msd-editor to create mass/spring structures. It works like this (translated to Pd editing):
User selects two objects and then hits a keyboard shortcut like Ctrl-C or a menu entry, which automatically connects the two objects' first out/inlets. Also one-to-many-connections could be made very fast this way.
However I didn't yet find a good way to make connecting other xlets than the first ones easier. Maybe selecting xlets instead of selecting object?
More ideas:
Select many objects and use a menu entry: "Convert selection to subpatch". Max has this now and it sounds like quite a cool idea.
Of course mouse driven editing of GUI objects' sizes etc. would be great.
Macros: Some common way to record and replay often celebrated editing actions into user defined macros would be very handy.
More keyboard driven editing: In edit mode, press TAB to jump to the next object and edit its contents. (What is "the next object"? I'd say top-bottom, then left-right.)
Just my 2ct collection.
Ciao
hi,
Am Montag 15 August 2005 19:41 schrieb Frank Barknecht:
Hallo,
[...snip...]
User selects two objects and then hits a keyboard shortcut like Ctrl-C or a menu entry, which automatically connects the two objects' first out/inlets. Also one-to-many-connections could be made very fast this way.
However I didn't yet find a good way to make connecting other xlets than the first ones easier. Maybe selecting xlets instead of selecting object?
maybe some combination of ctrl-number ? like ctrl-1 to connect in/outlet#1? or like: ctrl-number to select the source outlet, release ctrl, and enter the number of the receiving inlet?
More ideas:
Select many objects and use a menu entry: "Convert selection to subpatch". Max has this now and it sounds like quite a cool idea.
funny, i had this idea for karma also, since months ..... there are even (dysfunctional) menu entries: collapse/explode (to make a subpatch out of a selection, and the opposite: to explode a subpatch into its objects)
[...snip...]
Just my 2ct collection.
Ciao
greets,
chris
Hallo, Christian Klippel hat gesagt: // Christian Klippel wrote:
maybe some combination of ctrl-number ? like ctrl-1 to connect in/outlet#1? or like: ctrl-number to select the source outlet, release ctrl, and enter the number of the receiving inlet?
Well, Ctrl-1,2,3,4,5 are taken already.
I just got an alternatve idea: How about moving the connection using e.g. the cursor keys? When only a connection is selected, LEFT would move the inlet-connection one inlet left, Shift-LEFT would move the outlet connection left.
Probably this should not be done using the cursor keys as they are also used to move objects.
Oh, and selecting connections by moving over them with the mouse would also make work more comfortable.
Ciao
Oops.. Frank already had this idea, sorry...
I just got an alternatve idea: How about moving the connection using e.g. the cursor keys? When only a connection is selected, LEFT would move the inlet-connection one inlet left, Shift-LEFT would move the outlet connection left.
Probably this should not be done using the cursor keys as they are also used to move objects.
why not? You can't select objects and connections simultaneously anyhow.
Oh, and selecting connections by moving over them with the mouse would also make work more comfortable.
Gotta think about that one...
Ciao
Frank Barknecht _ ______footils.org__
hello,
about selecting multiple out/inlets:
there could be something like a "continue connecting" mode:
you make one connection, and after that you have a new "loose wire" comming from the same outlet, waiting to be clicked on the next inlet .... or vice versa depending of the direction where connections are made. if you connect from an outlet to an inlet, its a new wire from the outlet, if you connect from an inlet to an outlet, it will be a new one from that inlet.....
also, there could be a bigger "snap to" area around the in/outlets. that way it would be enough to move near the in/outlet to "snap" to it....
and yes, beeing able to select wires (either single by just having the mouse over it, or multiple by dragging and/or shift-click on them) is a good idea, imho.
greetings,
chris
Hallo, Christian Klippel hat gesagt: // Christian Klippel wrote:
there could be something like a "continue connecting" mode:
I'm not too sure about this one for stylistic reasons: I think it encourages a "fanning" style of patching, whereas we all now, that (for message connections) fanning cords from one outlet is often not The Right Thing - while using triggers is.
Ciao
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Oops.. Frank already had this idea, sorry...
I just got an alternatve idea: How about moving the connection using e.g. the cursor keys? When only a connection is selected, LEFT would move the inlet-connection one inlet left, Shift-LEFT would move the outlet connection left.
Probably this should not be done using the cursor keys as they are also used to move objects.
why not? You can't select objects and connections simultaneously anyhow.
Indeed, I didn't think about this.
Another open question could be how to handle moving a patch cord so that it would result in an "illegal" connection like trying to connect a signal cord to a message inlet. I'd say the patch cord should just jump over illegal connections.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Miller Puckette hat gesagt: // Miller Puckette wrote:
why not? You can't select objects and connections simultaneously anyhow.
Indeed, I didn't think about this.
Okay, now I remembered why I didn't like using the cursor keys at first:
If a user selects two objects and presses a future connect key to create a connection it could be nice, if she could directly move the patch cord to the correct inlets using some keyboard shortcut. However as currently the two objects are still selected, she could not use the cursor keys for this, as they would move the objects instead of the cord.
Ciao
On Mon, 15 Aug 2005, Frank Barknecht wrote:
I just got an alternatve idea: How about moving the connection using e.g. the cursor keys? When only a connection is selected, LEFT would move the inlet-connection one inlet left, Shift-LEFT would move the outlet connection left. Probably this should not be done using the cursor keys as they are also used to move objects.
Well, I don't think we should shy away from modal interfaces when they make sense.
What I propose is that the interface should:
* stay mostly non-modal for the mouse (just the Edit/Run duality, if that doesn't go away)
* become modal for the keyboard's arrows. Modes could be: 1. travelling around 2. moving selection 3. editing objectbox text 4. selecting an outlet or inlet for making connections or following existing connections 5. making a new connection
That would be because we don't have (m)any extra modifiers, as:
* Shift is already used for moving by larger amounts (i think it's by bunch of 8 pixels) * Ctrl is already used for instant-run-mode * Alt with arrows is often reserved by the window manager * Cmd is OSX-only and its PC equivalent is Alt or Ctrl depending on various whims * Meta is often the same as Alt and/or Escape * AltGr (or OSX Alt) is reserved for accented letters * And there's pretty much nothing else left (ScrollLock? haha).
Oh, and selecting connections by moving over them with the mouse would also make work more comfortable.
do you really mean selecting them, or just highlighting them?
also the in/outlet selection mouse-cursor is very bad on recent KDE desktops i've seen. This is why IMPD introduced highlighting of inlets/outlets.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Oh, and selecting connections by moving over them with the mouse would also make work more comfortable.
do you really mean selecting them, or just highlighting them?
I think, I meant highlighting but I don't really get the difference between both. What is the difference?
also the in/outlet selection mouse-cursor is very bad on recent KDE desktops i've seen. This is why IMPD introduced highlighting of inlets/outlets.
I like that. Using a different mouse cursor for active xlets doesn't make sense anymore as soon as the mouse isn't involved when making connections, e.g. when using keyboard shortcuts, so highlighting is the way to go.
Ciao
...
However I didn't yet find a good way to make connecting other xlets than the first ones easier. Maybe selecting xlets instead of selecting object?
How about selecting a connection and hitting left or right arrow to shift it over (either the inlet or the outlet depending on whether you hold the shift key).
For multiple connections, maybe it's even more useful to have a version of "duplicate" (control-shift-D?) that duplicates connections into and out of the selection too.
Another idea I've had for years: hit "enter" in an object box to make a new, empty one just below and connect the two.
I'm going to collect all these ideas on one place in my dolist and see what they look like together... I'd better not try this for 0.39 though; I'm just cleaning up bugs now.
cheers Miller
hi miller and all,
Am Dienstag 16 August 2005 19:50 schrieb Miller Puckette:
...
However I didn't yet find a good way to make connecting other xlets than the first ones easier. Maybe selecting xlets instead of selecting object?
[...snip...]
Another idea I've had for years: hit "enter" in an object box to make a new, empty one just below and connect the two.
hmm, thats doesnt sound right .... i mean, if im in an object box, i would believe that hitting enter means that entering text into it is finished ...
using the enter key that way would be at least confusing ......
for that i would prefer something like the insert-key (or shift-insert) ...... which is at least a bit more logical to me ....
I'm going to collect all these ideas on one place in my dolist and see what they look like together... I'd better not try this for 0.39 though; I'm just cleaning up bugs now.
cheers Miller
greets,
chris
Good ideas I'm hearing.
As for <insert> I think <shift-enter> would work better. insert implies inserting a the current position, so if we're already on an object insert is not so clear. <enter> implied that a new visual "line" would be created underneath what is currently active.
What about you click on a connection and then press <insert> to insert an object between the two and make the reconnections.
The left and right arrow shifting for a connection would be handy. How about you select a connection, and then you can move around either end with the arrow keys.
Another neat twist would be to auto connect many inlets on the same object, say you select two objects and hit connect - all or something, then from left to right all the outlets of the first object get connected from left to right to all the available inlets in the second object.
A friend of mine actually made a MAX patch that required about 1000 connections to be made from one object to another. blech! bad style, yes but anyhow.
for the record I would very strongly advocate exchanging the idea of the "font bomb" for the zoomer idea. :)
B.
Christian Klippel wrote:
hi miller and all,
Am Dienstag 16 August 2005 19:50 schrieb Miller Puckette:
...
However I didn't yet find a good way to make connecting other xlets than the first ones easier. Maybe selecting xlets instead of selecting object?
[...snip...]
Another idea I've had for years: hit "enter" in an object box to make a new, empty one just below and connect the two.
hmm, thats doesnt sound right .... i mean, if im in an object box, i would believe that hitting enter means that entering text into it is finished ...
using the enter key that way would be at least confusing ......
for that i would prefer something like the insert-key (or shift-insert) ...... which is at least a bit more logical to me ....
I'm going to collect all these ideas on one place in my dolist and see what they look like together... I'd better not try this for 0.39 though; I'm just cleaning up bugs now.
cheers Miller
greets,
chris
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 16 Aug 2005, Miller Puckette wrote:
Another idea I've had for years: hit "enter" in an object box to make a new, empty one just below and connect the two.
Another idea I've had for years is a way to insert an object at any given patchcord, so that the patchcord gets split into two parts, one which goes into inlet 0 of the inserted object and one that goes out of outlet 0 of the inserted object.
Another idea I've just had is that while dragging a connection out of an outlet, pressing Ctrl+1 would create a new object _and_ connect it at the end of the new patchcord.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Anyway, the important thing is, i think, to seperate the "pd engine" (or libpd) from the GUI part - indepedent of which Qt, OpenGl, Tcl ... GUI we might use in future ... and it's good to hear that there are some people interested in that ... :)
hm ... although i'm not really fan of cathedral building, maybe it would be a good idea to write down some kind of language specification and a list of requests. basically i'm thinking of splitting up pd's messaging and dsp core from the rest ... still thinking about how ... and what's part of pd's language and what of pd's library ...
t
hm ... although i'm not really fan of cathedral building, maybe it would be a good idea to write down some kind of language specification and a list of requests.
my request is a generic 'gui' object which caches model state in the kernel and message based access to update it via inlet or remote (tcp/shm/etc) client connection and a subsequent echoing of state changes to the outlet and subscribed clients.
for example my client caches a copy of the model to avoid roundtrips when redrawing, stored as a nested-list/multidimensional-array/dictionary/wotdoucallit, say an EQ curve generator something liek this:
in tcl: id1145 {band1 {gain 0.0 freq 11646.0 q 0.71 bqp {-0.223 0.2222 1.20000 0.3332}}..} or python: id1145 : {'band1' : {'gain' : 0.04, 'freq': 47.0..}}
a message like 'id234234 band1 gain 6.0' might come over from the gui, which would update that element of the model and echo the message to the outlet, making it possible to [list remap] all x's to y's and cable in a second view with the axes flipped..
how does the gui object know to set 'band1 gain' to 6.0, and not band1 to 'gain 6.0'? in PDContainer this requires 2 inlets(one for each key+value), i'd prefer one cable but that would require pd support nested lists (which i am requesting as well, of course)..
about the subscribers, some sort of masking to say 'subscribe to all' or 'just send me /patch1/subpatch2/twirly/23' and finally a way to query a list of all subscribable gui objects and the array keys, so that if one wants to use a panda3D gui that only handles an object at a time, or if tom's gui called an attribute 'juiciness' and mine expects 'juice', its simply a matter of some quick drag'n'drop remapping on the client side..
and thats all. pretty simple. :)
basically i'm thinking of splitting up pd's messaging and dsp core from the rest ... still thinking about how ... and what's part of pd's language and what of pd's library ...
Hallo!
basically i'm thinking of splitting up pd's messaging and dsp core from the rest ... still thinking about how ... and what's part of pd's language and what of pd's library ...
on other thing: did you also already think about how the split the datastructures in such a way ?
LG Georg
t
On Wed, 10 Aug 2005, Tim Blechmann wrote:
hm ... although i'm not really fan of cathedral building, maybe it would be a good idea to write down some kind of language specification and a list of requests.
I'd warn about taking "The Cathedral and the Buzzword" too seriously.
I think it's important to distinguish between libertarian wishful-thinking and what is required to get people organised.
I'm really not against more organisation than what we have now: it's just I haven't gotten to that point yet.
basically i'm thinking of splitting up pd's messaging and dsp core from the rest ... still thinking about how ...
This part is easy. Make every patcher-related feature scriptable in a way that you'd find comfortable to use for making self-modifying patches (or other forms of patches-generating-patches).
Then all those features would be available from the GUI through a [netsend]/[netreceive] pair from a process that we call the client.
and what's part of pd's language and what of pd's library ...
Yeah... and if I were you I'd also look at ways to make more non-object things become objects or classes: for example, Jack support could be a library containing [adc~] and [dac~], and so would OSS support and ALSA support. As with the above canvas stuff, the big advantage of making something a real Pd object is that you can talk to it using Pd messages and atoms through its inlets, which is the *only* requirement for enabling that thing to be used from a patch.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
B. Bogart -
Christian Klippel -
Frank Barknecht -
Georg Holzmann -
ix＠replic.net -
martin pichlmair -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann