I just ran into a bug which I quite common in Pd, and thought of a simple, graphical way to show status which would make such bugs trivial to spot. Basically, I had a [+ 17] which I had mistakenly input data on the right inlet. I then was debugging the logic since I thought the [+ 17] was adding 17.
So I was thinking that whenever an argument is overridden by data on an inlet, the argument should change color to clearly display that that argument is no longer in effect.
Right now Pd is very black-and-white, and I support not adding extraneous colors. But I think that we should be using color to show things, and this is a simple example where I think it makes sense.
.hc
------------------------------------------------------------------------
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
I second that - I think it would be a very useful feature. However, I think the colour should be quite subtle so as to not look too much like an error (red) or another alert message. Perhaps it should also be an option, so that people can turn 'colour mode' off if they really do just want black and white (or perhaps slightly better performance).
Jamie
On Sun, 18 Jun 2006 12:11:49 -0400 Hans-Christoph Steiner hans@eds.org wrote:
I just ran into a bug which I quite common in Pd, and thought of a simple, graphical way to show status which would make such bugs trivial to spot. Basically, I had a [+ 17] which I had mistakenly input data on the right inlet. I then was debugging the logic since I thought the [+ 17] was adding 17.
So I was thinking that whenever an argument is overridden by data on an inlet, the argument should change color to clearly display that that argument is no longer in effect.
Right now Pd is very black-and-white, and I support not adding extraneous colors. But I think that we should be using color to show things, and this is a simple example where I think it makes sense.
.hc
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Mon Jun 19, 2006 at 07:31:36PM +0100, Jamie Bullock wrote:
I second that - I think it would be a very useful feature. However, I think the colour should be quite subtle so as to not look too much like an error (red) or another alert message. Perhaps it should also be an option, so that people can turn 'colour mode' off if they really do just want black and white (or perhaps slightly better performance).
what about just showing the new value? i think this should also apply to anything that accepts a 'set' message.. a lot of guesswork is involved when backtracing a patch visually, in the current GUI..
On Jun 22, 2006, at 7:51 PM, carmen wrote:
On Mon Jun 19, 2006 at 07:31:36PM +0100, Jamie Bullock wrote:
I second that - I think it would be a very useful feature. However, I think the colour should be quite subtle so as to not look too much like an error (red) or another alert message. Perhaps it should also be an option, so that people can turn 'colour mode' off if they really do just want black and white (or perhaps slightly better performance).
what about just showing the new value? i think this should also apply to anything that accepts a 'set' message.. a lot of guesswork is involved when backtracing a patch visually, in the current GUI..
Arguments are often used as defaults, so you wouldn't want them to be changed by data coming on the inlet. But yes, perhaps red isn't the best color. How about a nice mauve or teal perhaps... ;)
.hc
------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
Hallo!
I second that - I think it would be a very useful feature. However, I think the colour should be quite subtle so as to not look too much like an error (red) or another alert message. Perhaps it should also be an option, so that people can turn 'colour mode' off if they really do just want black and white (or perhaps slightly better performance).
yes, maybe this could be something like a debug-mode ...
LG Georg
On Fri, 23 Jun 2006, Georg Holzmann wrote:
I second that - I think it would be a very useful feature. However, I think the colour should be quite subtle so as to not look too much like an error (red) or another alert message. Perhaps it should also be an option, so that people can turn 'colour mode' off if they really do just want black and white (or perhaps slightly better performance).
yes, maybe this could be something like a debug-mode ...
a real debug mode would also include the ability to record all the message-passing done during a certain period of time, and then replay it slowly with arrows showing execution order and perhaps also seeing the messages travel along the wires.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Jamie Bullock hat gesagt: // Jamie Bullock wrote:
I second that - I think it would be a very useful feature. However, I think the colour should be quite subtle so as to not look too much like an error (red) or another alert message. Perhaps it should also be an option, so that people can turn 'colour mode' off if they really do just want black and white (or perhaps slightly better performance).
I would prefer something like a tooltip. IIRC I never ran into the problem of taking an argument to still be valid so a different color would just distract me. I mean, *a lot* of objects get a different value from the initialized one soon after a patch was loaded, for example every [f 0]X[+ 1] counter or many [osc~ 440]. And they might even be at their default value again for some time later, so a different color sounds a little bit useless.
Additionally I think, that there is no natural connection between the graphical signal: "object colored differently" and the information to be transported: "default value is overwritten". A tooltip however would directly display the needed information, so the connection between the graphical event and the information displayed is very close.
And last: When printed - I know Hans doesn't do that, but ... ;) - when printed, all objects should look the same, regardless what value they hold currently.
Ciao
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote:
Hallo, Jamie Bullock hat gesagt: // Jamie Bullock wrote:
I second that - I think it would be a very useful feature. However, I think the colour should be quite subtle so as to not look too much like an error (red) or another alert message. Perhaps it should also be an option, so that people can turn 'colour mode' off if they really do just want black and white (or perhaps slightly better performance).
I would prefer something like a tooltip. IIRC I never ran into the problem of taking an argument to still be valid so a different color would just distract me. I mean, *a lot* of objects get a different value from the initialized one soon after a patch was loaded, for example every [f 0]X[+ 1] counter or many [osc~ 440]. And they might even be at their default value again for some time later, so a different color sounds a little bit useless.
Additionally I think, that there is no natural connection between the graphical signal: "object colored differently" and the information to be transported: "default value is overwritten". A tooltip however would directly display the needed information, so the connection between the graphical event and the information displayed is very close.
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen. Only very important things should cause popups on the screen, not just status information. The "loudness" of the interruption should be proportional to the urgency of what is being communicated. As you well described, this is often not urgent info.
And last: When printed - I know Hans doesn't do that, but ... ;) - when printed, all objects should look the same, regardless what value they hold currently.
I only print when someone else makes me ;). On that topic, I did create my NIME poster in Pd, which was printed on A1 paper:
.hc
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
under your scheme, if the patch is even remotely alive, much of it is going to turn red right after opening
what about displaying the init value in black, and the current value in red or green, depending on whether its rising or falling
eg _=___=___ | osc~ 440| | 557| | (hz)| -=---------
or something (i even forget if osc~ has one outlet its been so long since i touched pd) clicking on 440 would reset it (so you dont need to cluter the patch with an extra [440(
cc
Zitat von carmen _@whats-your.name:
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
under your scheme, if the patch is even remotely alive, much of it is going to turn red right after opening
what about displaying the init value in black, and the current value in red or green, depending on whether its rising or falling
eg _=___=___ | osc~ 440| | 557| | (hz)| -=---------
hmm, that is a good example: [osc~]s inlet is basically a signal inlet: if you send a message [float 557( to it, it actually receives a signal with all samples set to 557.0f. should we display all values for the entire sample block or just the first value?
or something (i even forget if osc~ has one outlet its been so long since i touched pd) clicking on 440 would reset it (so you dont need to cluter the patch with an extra [440(
do i understand you correctly, that you want to replace a clickeable area which is 100% controllable by the user by another clickable area which is predefined in order to make things less cluttered?
you can do a lot of things with gop objects. for a (non-working) example see the attachment; this example brings to my mind, that it would be far more important to make abstractions equal to externals and vice versa (e.g. the "default signal" is missing in abstractions)
in understand the need for an "inspector" of the current value. personally i would prefer to inspect things on demand over a permanent notice of what goes on in my patch (in the best of worlds i know what is going on)
mfga.sdr IOhannes
On Sat, 24 Jun 2006 zmoelnig@iem.at wrote:
example see the attachment; this example brings to my mind, that it would be far more important to make abstractions equal to externals and vice versa (e.g. the "default signal" is missing in abstractions)
I don't know it you mean this (see attached test.pd), but to a certain extend I think it works.
Günter
geiger wrote:
On Sat, 24 Jun 2006 zmoelnig@iem.at wrote:
example see the attachment; this example brings to my mind, that it would be far more important to make abstractions equal to externals and vice versa (e.g. the "default signal" is missing in abstractions)
I don't know it you mean this (see attached test.pd), but to a certain extend I think it works.
i was unclear here. your patch works as expected. i tried to articulate the need for a way to set this default signal from within the patch....(i really don't know how to say it...)
ok, an example with [osc~]: [osc~] takes an argument (initial frequency), which can be overridden by sending a float-message to the [osc~] object) if you connect a signal to the object, it will override both the initial argument and the float-message.
in C-code this is done by manipulating a float-variable specified at CLASS_MAINSIGNALIN() (in the [osc~] code at d_osc.c this is the variable x_f)
in the pd-patch i have no way to do something similar: an abstraction can (as you have shown) accept pseudo-signals, but there is really no way to set such a signal from within the abstraction.
i guess such a feature could be done with arguments to the [inlet~] object (despite the fact that this solution conflicts with the upsampling/downsampling argument as well as tooltips)
mfga,.sdr. IOhannes
All great ideas. This really needs a separate mode, kinda "debug" mode as Georg mentioned. Problem with updating values in the object is they might be extrememly large or small. How to display that is a problem, we don't want objects shrinking and growing in length, yet truncating values might be misleading.
An couple of ideas I had for debug are:
to have a "sniff" cursor. When you hold it on a connection or outlet it displays a small box with the type and values of data flowing in the pipe in a time ordered list. When you release the mouse it freezes and the box remains until you do something to dispose of it.
[object that does something] | | | | | | | | X<-[ type: float value 1.3425e-11 ] [ type: bang value: null ] [ type: symbol value: "clicked"]
Extending this principle, I quite often want to sniff audio signals as I work down a flow, a cursor mode that just grabs what is there straight to the DAC (or video window for you GEM freaks) would be mighty useful. Actually having it route to a named send~/receive~ would be best so I could decide how to handle it with a compressor or pop it up on an attenuated desk channel. Right now I find the only way to debug is to make and break lots of temporary connections.
Another idea is taken straight from standard fare code debugging, to have a single step or breakpoint. Right now I do this with a conditional that bangs a [;dsp 0] but for obvious reasons it's less than ideal.
Just crazy thoughts... Andy
On Sat, 24 Jun 2006 02:09:01 +0000 carmen _@whats-your.name wrote:
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
under your scheme, if the patch is even remotely alive, much of it is going to turn red right after opening
what about displaying the init value in black, and the current value in red or green, depending on whether its rising or falling
eg _=___=___ | osc~ 440| | 557| | (hz)| -=---------
or something (i even forget if osc~ has one outlet its been so long since i touched pd) clicking on 440 would reset it (so you dont need to cluter the patch with an extra [440(
cc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
In response to Frank's last message (I went to dinner and haven't read the rest yet): Argument accepted. It would also cause trouble for saving patches, as it would introduce the assumption that the last value received would be saved.
Alternately though it might be nice to at least "bracket" the defaults somehow to separate them from the object name a little more. And I also agree with Hans that color is always neglected in many applications, and could be used to great utility in Pd. As an example, coloring the patch cords when data is being sent would reduce the necessity of attaching bangs to monitor activity.
On 6/24/06, padawan12 padawan12@obiwannabe.co.uk wrote:
All great ideas. This really needs a separate mode, kinda "debug" mode as Georg mentioned. Problem with updating values in the object is they might be extrememly large or small. How to display that is a problem, we don't want objects shrinking and growing in length, yet truncating values might be misleading.
An couple of ideas I had for debug are:
to have a "sniff" cursor. When you hold it on a connection or outlet it displays a small box with the type and values of data flowing in the pipe in a time ordered list. When you release the mouse it freezes and the box remains until you do something to dispose of it.
[object that does something] | | | | | | | | X<-[ type: float value 1.3425e-11 ] [ type: bang value: null ] [ type: symbol value: "clicked"]
Extending this principle, I quite often want to sniff audio signals as I work down a flow, a cursor mode that just grabs what is there straight to the DAC (or video window for you GEM freaks) would be mighty useful. Actually having it route to a named send~/receive~ would be best so I could decide how to handle it with a compressor or pop it up on an attenuated desk channel. Right now I find the only way to debug is to make and break lots of temporary connections.
Another idea is taken straight from standard fare code debugging, to have a single step or breakpoint. Right now I do this with a conditional that bangs a [;dsp 0] but for obvious reasons it's less than ideal.
Just crazy thoughts... Andy
On Sat, 24 Jun 2006 02:09:01 +0000 carmen _@whats-your.name wrote:
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
under your scheme, if the patch is even remotely alive, much of it is going to turn red right after opening
what about displaying the init value in black, and the current value in red or green, depending on whether its rising or falling
eg _=___=___ | osc~ 440| | 557| | (hz)| -=---------
or something (i even forget if osc~ has one outlet its been so long since i touched pd) clicking on 440 would reset it (so you dont need to cluter the patch with an extra [440(
cc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sat, 24 Jun 2006, carmen wrote:
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
under your scheme, if the patch is even remotely alive, much of it is going to turn red right after opening what about displaying the init value in black, and the current value in red or green, depending on whether its rising or falling eg _=___=___ | osc~ 440| | 557| | (hz)| -=---------
Screen space is too precious. You need to print each in a different colour channel of the same area. Then you use 3-D glasses in a non-3-D way to read whichever value you want at the moment.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote:
I would prefer something like a tooltip. IIRC I never ran into the
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
If the tooltips have a longer delay until they show up, may that's endurable?
Ciao
On Sat, 24 Jun 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote:
I would prefer something like a tooltip. IIRC I never ran into the
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
If the tooltips have a longer delay until they show up, may that's endurable?
What if the edit menu has a checkbox to enable canvas-based tooltips?
and a box to set the tooltip delay (?) which might not be needed.
Usually, when someone doesn't want tooltips, the delay has better be high, very high, and when someone wants tooltips, the delay has better be low, very low. Which makes me think that there should be a toggle between infinite delay and zero delay, at least.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sat, 24 Jun 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote:
I would prefer something like a tooltip. IIRC I never ran into the
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
If the tooltips have a longer delay until they show up, may that's endurable?
What if the edit menu has a checkbox to enable canvas-based tooltips?
and a box to set the tooltip delay (?) which might not be needed.
Usually, when someone doesn't want tooltips, the delay has better be high, very high, and when someone wants tooltips, the delay has better be low, very low. Which makes me think that there should be a toggle between infinite delay and zero delay, at least.
A lot of applications use something like a control key combo or a right-click to display extra info, instantaneously, so, e.g., right-clicking on a wire would show a tooltip. It's faster than toggling checkboxes on the main window or in a menu.
I have this recurring idea though that if pd had a GUI API that wasn't tied to tcl/tk then openGL could be used to represent patches in 3D, and the user could zoom _inside_ objects to set their parameters and check on their status.
Martin
..on Sat, Jun 24, 2006 at 02:47:18PM -0400, Martin Peach wrote:
Mathieu Bouchard wrote:
On Sat, 24 Jun 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote:
I would prefer something like a tooltip. IIRC I never ran into the
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
If the tooltips have a longer delay until they show up, may that's endurable?
What if the edit menu has a checkbox to enable canvas-based tooltips?
and a box to set the tooltip delay (?) which might not be needed.
Usually, when someone doesn't want tooltips, the delay has better be high, very high, and when someone wants tooltips, the delay has better be low, very low. Which makes me think that there should be a toggle between infinite delay and zero delay, at least.
A lot of applications use something like a control key combo or a right-click to display extra info, instantaneously, so, e.g., right-clicking on a wire would show a tooltip. It's faster than toggling checkboxes on the main window or in a menu.
I have this recurring idea though that if pd had a GUI API that wasn't tied to tcl/tk then openGL could be used to represent patches in 3D, and the user could zoom _inside_ objects to set their parameters and check on their status.
jeezz.. me and many others have been saying this for years ;)
i even reiterated it a few posts back!
this would be a very smart move IMO - OpenGL makes a very good, GPU managed fast 2D library, leaving the CPU to do the real work, like crunching numbers.
julian
On Jun 24, 2006, at 12:44 PM, Julian Oliver wrote:
..on Sat, Jun 24, 2006 at 02:47:18PM -0400, Martin Peach wrote:
Mathieu Bouchard wrote:
On Sat, 24 Jun 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote:
I would prefer something like a tooltip. IIRC I never ran into the
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
If the tooltips have a longer delay until they show up, may that's endurable?
What if the edit menu has a checkbox to enable canvas-based tooltips?
and a box to set the tooltip delay (?) which might not be needed.
Usually, when someone doesn't want tooltips, the delay has better be high, very high, and when someone wants tooltips, the delay has better be low, very low. Which makes me think that there should be a toggle between infinite delay and zero delay, at least.
A lot of applications use something like a control key combo or a right-click to display extra info, instantaneously, so, e.g., right-clicking on a wire would show a tooltip. It's faster than toggling checkboxes on the main window or in a menu.
I have this recurring idea though that if pd had a GUI API that wasn't tied to tcl/tk then openGL could be used to represent patches in 3D, and the user could zoom _inside_ objects to set their parameters and check on their status.
jeezz.. me and many others have been saying this for years ;)
i even reiterated it a few posts back!
this would be a very smart move IMO - OpenGL makes a very good, GPU managed fast 2D library, leaving the CPU to do the real work, like crunching numbers.
I think it would be quite nice to get Pd to the point where it would be relatively straightforward for people to write their own GUIs for it. DesireData is that idea, but unfortunately, its more like a fork, so its very unlikely that those changes will be incorporated by Miller. I suppose it would be possible if the DD devs started submitted patches to the patch tracker. Miller accepts the majority of them these days.
So there has been much talk over the years about doing this, I think there needs to be more action. Any volunteers?
.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.
Hans-Christoph Steiner wrote:
On Jun 24, 2006, at 12:44 PM, Julian Oliver wrote:
..on Sat, Jun 24, 2006 at 02:47:18PM -0400, Martin Peach wrote:
Mathieu Bouchard wrote:
On Sat, 24 Jun 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote: > I would prefer something like a tooltip. IIRC I never ran into the Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
If the tooltips have a longer delay until they show up, may that's endurable?
What if the edit menu has a checkbox to enable canvas-based tooltips?
and a box to set the tooltip delay (?) which might not be needed.
Usually, when someone doesn't want tooltips, the delay has better be high, very high, and when someone wants tooltips, the delay has better be low, very low. Which makes me think that there should be a toggle between infinite delay and zero delay, at least.
A lot of applications use something like a control key combo or a right-click to display extra info, instantaneously, so, e.g., right-clicking on a wire would show a tooltip. It's faster than toggling checkboxes on the main window or in a menu.
I have this recurring idea though that if pd had a GUI API that wasn't tied to tcl/tk then openGL could be used to represent patches in 3D, and the user could zoom _inside_ objects to set their parameters and check on their status.
jeezz.. me and many others have been saying this for years ;)
i even reiterated it a few posts back!
this would be a very smart move IMO - OpenGL makes a very good, GPU managed fast 2D library, leaving the CPU to do the real work, like crunching numbers.
I think it would be quite nice to get Pd to the point where it would be relatively straightforward for people to write their own GUIs for it. DesireData is that idea, but unfortunately, its more like a fork, so its very unlikely that those changes will be incorporated by Miller. I suppose it would be possible if the DD devs started submitted patches to the patch tracker. Miller accepts the majority of them these days.
So there has been much talk over the years about doing this, I think there needs to be more action. Any volunteers?
Well sure, I can work on this. I think probably the existing pd-tcl/tk interface needs to be documented first. I've started a bit on this. I guess it needs a wiki page someplace. Then there is the question: do we take the existing socket connection and hook it to a tcl/tk-openGL translator (the easy but slow way) or redo the whole thing to get rid of the special characters and unreadable command strings that cause so much grief (harder but in the long term more robust)?
Martin
..on Sat, Jun 24, 2006 at 06:29:19PM -0400, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Jun 24, 2006, at 12:44 PM, Julian Oliver wrote:
..on Sat, Jun 24, 2006 at 02:47:18PM -0400, Martin Peach wrote:
Mathieu Bouchard wrote:
On Sat, 24 Jun 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: >On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote: >>I would prefer something like a tooltip. IIRC I never ran into the >Personally, I find tooltips far more distracting that just a tiny >bit >of color on the screen. If the tooltips have a longer delay until they show up, may that's endurable?
What if the edit menu has a checkbox to enable canvas-based tooltips?
and a box to set the tooltip delay (?) which might not be needed.
Usually, when someone doesn't want tooltips, the delay has better be high, very high, and when someone wants tooltips, the delay has better be low, very low. Which makes me think that there should be a toggle between infinite delay and zero delay, at least.
A lot of applications use something like a control key combo or a right-click to display extra info, instantaneously, so, e.g., right-clicking on a wire would show a tooltip. It's faster than toggling checkboxes on the main window or in a menu.
I have this recurring idea though that if pd had a GUI API that wasn't tied to tcl/tk then openGL could be used to represent patches in 3D, and the user could zoom _inside_ objects to set their parameters and check on their status.
jeezz.. me and many others have been saying this for years ;)
i even reiterated it a few posts back!
this would be a very smart move IMO - OpenGL makes a very good, GPU managed fast 2D library, leaving the CPU to do the real work, like crunching numbers.
I think it would be quite nice to get Pd to the point where it would be relatively straightforward for people to write their own GUIs for it. DesireData is that idea, but unfortunately, its more like a fork, so its very unlikely that those changes will be incorporated by Miller. I suppose it would be possible if the DD devs started submitted patches to the patch tracker. Miller accepts the majority of them these days.
So there has been much talk over the years about doing this, I think there needs to be more action. Any volunteers?
Well sure, I can work on this. I think probably the existing pd-tcl/tk interface needs to be documented first. I've started a bit on this. I guess it needs a wiki page someplace.
this is a good idea. perhaps it could begin as a general central site for consolidating ideas and existing attempts to 're-skin' PD.
Then there is the question: do we take the existing socket connection and hook it to a tcl/tk-openGL translator (the easy but slow way) or redo the whole thing to get rid of the special characters and unreadable command strings that cause so much grief (harder but in the long term more robust)?
probably best to rewire it altogether.
one thing that really needs to be considered is that OpenGL forces a single window interface context. this would mean all the PD canvases wouldn't be inside real windows themselves, but all fake windows nested within a single larger window for rendering. this has it's obvious advantages and disadvantages.
recently several igh level API's have emerged that aim to make developing rich 2D OpenGL interfaces easier. here's one i found the other day, though it's intended use is very different from that of PD:
http://projects.o-hand.com/clutter/
i'd also consider looking at the what Blender could already offer PD, as many similar UI elements are already in use in Blender: sliders, patch-like interface (w/bezier splines), toggles, editeable text fields, 'number boxes'.
cheers,
julian
Julian Oliver wrote:
So there has been much talk over the years about doing this, I think there needs to be more action. Any volunteers?
Well sure, I can work on this. I think probably the existing pd-tcl/tk interface needs to be documented first. I've started a bit on this. I guess it needs a wiki page someplace.
this is a good idea. perhaps it could begin as a general central site for consolidating ideas and existing attempts to 're-skin' PD.
Then there is the question: do we take the existing socket connection and hook it to a tcl/tk-openGL translator (the easy but slow way) or redo the whole thing to get rid of the special characters and unreadable command strings that cause so much grief (harder but in the long term more robust)?
probably best to rewire it altogether.
one thing that really needs to be considered is that OpenGL forces a single window interface context. this would mean all the PD canvases wouldn't be inside real windows themselves, but all fake windows nested within a single larger window for rendering. this has it's obvious advantages and disadvantages.
recently several igh level API's have emerged that aim to make developing rich 2D OpenGL interfaces easier. here's one i found the other day, though it's intended use is very different from that of PD:
[snip]
also don't forget:
* Cairo [1] (see also glitz [2]) Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System, win32, and image buffers. Experimental backends include OpenGL (through glitz), Quartz, XCB, PostScript and PDF file output. Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension). License: LGPL
* flowcanvas FlowCanvas is a canvas widget for dataflow systems. It consists of a Gtkmm widget containing movable modules and ports which can be connected in various ways. See the screenshots, you'll get it :). Yes, this means FlowCanvas is C++ only. Sorry, C people. FlowCanvas is Free Software licensed under the GNU GPL
[1] http://cairographics.org/ [2] http://www.freedesktop.org/wiki/Software/glitz [3] http://www.nongnu.org/om-synth/flowcanvas.html
On Sat, 2006-06-24 at 14:51 -0700, Hans-Christoph Steiner wrote:
I suppose it would be possible if the DD devs started submitted patches to the patch tracker. Miller accepts the majority of them these days.
i admire you enthusiasm, but from my own experience, i must state, that the pd development process is not as interactive as you describe ... the biggest problem is that no one knows, if a patch will apply to future versions of pd ... i did a lot of porting of patches from 0.38 to 0.39, and i definitely don't want to go through this process again ...
So there has been much talk over the years about doing this, I think there needs to be more action. Any volunteers?
well, i guess, the volunteers are there and they took action ... but they don't work on miller's branch ... matju and chun did quite some work on desire data, forking from miller's pd, and i'm writing my own engine, which will be combined with christian klippel's gui 'karma' ... while pnpd/karma is rewritten from scratch and thus wouldn't be interesting for the future of the pd development, i guess, that the desire data developers doubt that their code would be included into miller's pd ... (this is somehow understandable, as it's not only a 5 lines patch) i was following this discussion with great interest, but i'm still remembering guenter's tool tips patch, that where written for 0.38 and ported to 0.39 ... they are not a big patch, but it never made it into miller's pd ...
imo, the problem of pd's development is not the lack of ideas, but the lack of collaboration ...
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac
Tim Blechmann wrote:
i was following this discussion with great interest, but i'm still remembering guenter's tool tips patch, that where written for 0.38 and ported to 0.39 ... they are not a big patch, but it never made it into miller's pd ...
one problem with the tool tips patch is, that miller accepted my patch for up/downsampling long ago (btw, i am very thankful for this): both use the arguments to the [inlet~], but disagree on the meaning of these arguments.
mfg.asdr IOhannes
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
one problem with the tool tips patch is, that miller accepted my patch for up/downsampling long ago (btw, i am very thankful for this): both use the arguments to the [inlet~], but disagree on the meaning of these arguments.
I think this is not the real problem, as up/downsampling could be specified through other means and backwards compatibility could be maintained easily.
The reason why he didn't accept the patch was that it changes the size of the pd base class, which breakes the external ABI and therefore externals compiled with older version of pd would stop working.
Anyhow, the last thing I wanted to achieve with the tooltips patch was that some of us use it in order to justify their stopping to submit patches to the tracker. I have the feeling that these people are missing the goodwill towards Miller that Miller has always demonstrated towards them.
So, to all of those who are frustrated and not happy with the current situation, please try to grow up, and lets try to solve the problem by working together, not against each other.
Amen
Günter
geiger wrote:
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
one problem with the tool tips patch is, that miller accepted my patch for up/downsampling long ago (btw, i am very thankful for this): both use the arguments to the [inlet~], but disagree on the meaning of these arguments.
I think this is not the real problem, as up/downsampling could be specified through other means and backwards compatibility could be maintained easily.
seems like a bit blindfolded... the simplest way would of course be to just ignore the fact (on the users side) that there is an additional word (e.g. "linear") in the comment. e.g [inlet~ linear center frequency] would do linear resampling and have a tooltip "linear center frequency" which in fact should read only "center frequency" but might be ok as a simple workaround (requires the user to be aware of the whole thing); even better if you do [inlet~ linear - center frequency]....
however, what exactly do you mean with "through other means"? i have a strong feeling that this method ought to be given via the argument, as it changes the behaviour of the object, whereas the tooltip only changes the graphical appearance of the object.
personally i would prefer most, if tooltips would be available for _every_ object and they should be set via the preferences (right-click) menu. this of course does not deal at all with the way how this information is stored within a pd-patch. probably it would be a good idea to do it similar to the way arrays are stored inline.
e.g. something like
#X obj 100 100 inlet; #G tooltip reset the game #X obj 100 200 outlet; #G tooltip finished! #X connect 0 0 1 0 #G tooltip here flows the data #G color red
#G (like "Gui") is attached to the preceding "#X" line. i would prefer "#P" (Properties), but this is already taken by the good olde Patcher.
the patch given create an abstraction with 1 in- and 1 outlet: if the abstraction is closed, the tooltips "reset the game" (inlet) and "finished!" (outlet) would popup when you hover over the iolets. when you open the abstraction, you get the tooltip; by hovering over the objects; the connection between the 2 objects is red and has also a tool-tip....
any pd interpreter could just omit lines starting with "#G", and still the functionality of the patch would be untouched. an interpreter could also choose to ignore certain tags in the #G lines (e.g. no fanzy color support).
so i am thinking about an _optional_ non-functional data-field for each element of a pd-patch (not just iolets)
The reason why he didn't accept the patch was that it changes the size of the pd base class, which breakes the external ABI and therefore externals compiled with older version of pd would stop working.
ok, this is obviously far more important than my little concerns.
reading miller's comment at the patch tracker suggest, that he also wants to keep things as tight as possible.
it would be good to hear miller's opinion (once everything has calmed down) of whether there is a chance to get a feature like the tooltips (or my more general idea of graphical properties) into vanilla pd and how it ought to be done "the right way"....
Amen
mfg.asdr IOhannes
IOhannes m zmoelnig wrote:
personally i would prefer most, if tooltips would be available for _every_ object and they should be set via the preferences (right-click) menu. this of course does not deal at all with the way how this information is stored within a pd-patch. probably it would be a good idea to do it similar to the way arrays are stored inline.
There would also need to be a function to register default tooltips in hard-coded externals. Something like:
void settooltipsymbol(t_class *c, t_symbol *s, t_object *iolet);
e.g. something like
#X obj 100 100 inlet; #G tooltip reset the game #X obj 100 200 outlet; #G tooltip finished! #X connect 0 0 1 0 #G tooltip here flows the data #G color red
#G (like "Gui") is attached to the preceding "#X" line. i would prefer "#P" (Properties), but this is already taken by the good olde Patcher.
Or #I (Info)?
Martin
e.g. something like
#X obj 100 100 inlet; #G tooltip reset the game #X obj 100 200 outlet; #G tooltip finished! #X connect 0 0 1 0 #G tooltip here flows the data #G color red
#G (like "Gui") is attached to the preceding "#X" line. i would prefer "#P" (Properties), but this is already taken by the good olde Patcher.
it would be good to hear miller's opinion (once everything has calmed down) of whether there is a chance to get a feature like the tooltips (or my more general idea of graphical properties) into vanilla pd and how it ought to be done "the right way"....
Since there is already an approach to GUI properties in DesireData i'd really like to see a uniform solution. To my mind the DesireData way to tackle this looks promising (maybe because i'm biased, or maybe not).
greetings, Thomas
Thomas Grill wrote:
Since there is already an approach to GUI properties in DesireData i'd really like to see a uniform solution. To my mind the DesireData way to tackle this looks promising (maybe because i'm biased, or maybe not).
so please tell us the dd-way of doing this. i am not really involved into this project, though from time to time i have a look at it. naturally it would be good to have the properties system work on every Pd interpreter.
mfg.asdr IOhannes
greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Am 28.06.2006 um 11:05 schrieb IOhannes m zmoelnig:
Thomas Grill wrote:
Since there is already an approach to GUI properties in DesireData i'd really like to see a uniform solution. To my mind the DesireData way to tackle this looks promising (maybe because i'm biased, or maybe not).
so please tell us the dd-way of doing this. i am not really involved into this project, though from time to time i have a look at it. naturally it would be good to have the properties system work on every Pd interpreter.
I would suggest that Matju tells us about it.... i don't know about the actual implementation - i just proposed some ideas a while ago which have obviously been integrated.
greetings, Thomas
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
geiger wrote:
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
one problem with the tool tips patch is, that miller accepted my patch for up/downsampling long ago (btw, i am very thankful for this): both use the arguments to the [inlet~], but disagree on the meaning of these arguments.
I think this is not the real problem, as up/downsampling could be specified through other means and backwards compatibility could be maintained easily.
seems like a bit blindfolded...
why ?
the simplest way would of course be to just ignore the fact (on the users side) that there is an additional word (e.g. "linear") in the comment.
thats a good idea, one could then implement the different upsampling methods through standard pd objects that take a zero padded input signal.
e.g [inlet~ linear center frequency] would do linear resampling and have a tooltip "linear center frequency" which in fact should read only "center frequency" but might be ok as a simple workaround (requires the user to be aware of the whole thing); even better if you do [inlet~ linear - center frequency]....
I think for backwards compatibility it is enough to detect "linear" and do the right thing. I do not expect that everybody will add tooltips to the inlets everytime.
however, what exactly do you mean with "through other means"?
One possiblity would be to supply the upsampling information together with the upsampling factor, in the block object. Or the above mentioned method of having an object for different up/downsampling methods.
I just wanted to state that there are solutions to the problem. Which one gets chosen or if your proposal of #G objects get implemented can be decided after considering advantages and disadvantages. The original tooltips patch didn't interfere with the functionality of upsampling at all, so calling my arguments blindfolded is a bit, hum, short-sighted, I'd say.
Günter
geiger wrote:
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
geiger wrote:
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
one problem with the tool tips patch is, that miller accepted my patch for up/downsampling long ago (btw, i am very thankful for this): both use the arguments to the [inlet~], but disagree on the meaning of these arguments.
I think this is not the real problem, as up/downsampling could be specified through other means and backwards compatibility could be maintained easily.
seems like a bit blindfolded...
why ?
sorry: this line should really have read: "seems like i am a bit blindfolded" i didn't want to insult anybody, just wanted to express that probably i am not seeing the wood through all the trees (or however this is translated into english)
the simplest way would of course be to just ignore the fact (on the users side) that there is an additional word (e.g. "linear") in the comment.
thats a good idea, one could then implement the different upsampling methods through standard pd objects that take a zero padded input signal.
i see. this sounds like a good idea to me (generally). probably not too many patches use up/downsampling anyhow. the question is, whether the zero-padded upsampling is the best choice...
however, what exactly do you mean with "through other means"?
One possiblity would be to supply the upsampling information together with the upsampling factor, in the block object.
i don't like that, since it does not allow you to have differently upsampled signals within one subpatch...
Or the above mentioned method of having an object for different up/downsampling methods.
...but otoh, both methods could coexist.
the reason why i did not implement it like this was, that i wanted the parent patch not to have any knowledge about the samplerate of the child. the problem is rather with downsampling than with upsampling, since we have to decide beforehand, which samples are to be kept and which not.
i admit that it could have been done better (right now, if you really want "cleanly" resampled signals, you need to do filtering of the signal outside of the child anyhow)
I just wanted to state that there are solutions to the problem. Which one gets chosen or if your proposal of #G objects get implemented can be decided after considering advantages and disadvantages. The original tooltips patch didn't interfere with the functionality of upsampling at
right. i only wanted to ask kindly as which solutions you were thinking of. (and i got an answer already)
all, so calling my arguments blindfolded is a bit, hum, short-sighted, I'd say.
i'd even say, it is...blindfolded :-)
mfg.asdr. IOhannes
On Wed, 28 Jun 2006, IOhannes m zmoelnig wrote:
why ?
sorry: this line should really have read:
ok, understood ... often I am just too paranoid. Sorry.
i see. this sounds like a good idea to me (generally). probably not too many patches use up/downsampling anyhow. the question is, whether the zero-padded upsampling is the best choice...
I thought its the most general one, a resample object can use it to do sample+hold, linear interpolation or any other type of filtering. You could also just use a bunch of lop~'s, or you do a fft and cut off the unwanted bins. One good thing about it is that you can implement other more sophisticated schemes without having to touch Pd's core code and sometimes even without having to write in C/C++.
however, what exactly do you mean with "through other means"?
One possiblity would be to supply the upsampling information together with the upsampling factor, in the block object.
i don't like that, since it does not allow you to have differently upsampled signals within one subpatch...
Yes, its less flexible.
Or the above mentioned method of having an object for different up/downsampling methods.
...but otoh, both methods could coexist.
the reason why i did not implement it like this was, that i wanted the parent patch not to have any knowledge about the samplerate of the child. the problem is rather with downsampling than with upsampling, since we have to decide beforehand, which samples are to be kept and which not.
If I remember correctly, you can do downsampling by lowpass filtering inside the child, and let the picking of samples up to the inlet. This should give you a perfectly downsampled signal (because you removed the frequencies above the parents nyquist frequency). The only thing that you need to know is the resampling factor in the child patch.
For resampling there is a very good webpage by J.O.Smith, http://www-ccrma.stanford.edu/~jos/resample/resample.html
i admit that it could have been done better (right now, if you really want "cleanly" resampled signals, you need to do filtering of the signal outside of the child anyhow)
Really ? Isn't that too late, as you already have the aliasing in the signal ?
I just wanted to state that there are solutions to the problem. Which one gets chosen or if your proposal of #G objects get implemented can be decided after considering advantages and disadvantages. The original tooltips patch didn't interfere with the functionality of upsampling at
right. i only wanted to ask kindly as which solutions you were thinking of. (and i got an answer already)
all, so calling my arguments blindfolded is a bit, hum, short-sighted, I'd say.
i'd even say, it is...blindfolded :-)
well for a misunderstanding it always takes two, I really have to learn to read between the lines in a positive way. Anyhow, apologies for the harsh words.
Günter
mfg.asdr. IOhannes
geiger wrote:
On Wed, 28 Jun 2006, IOhannes m zmoelnig wrote:
why ?
sorry: this line should really have read:
ok, understood ... often I am just too paranoid. Sorry.
never mind. i guess, when one has a reputation like me (often being a bit harsh,sarcastic,...), then one has to take extra care that at least the things one writes do not get obfuscated by mispelling, forgotton letters, words, phrases, or bad english in general...
i see. this sounds like a good idea to me (generally). probably not too many patches use up/downsampling anyhow. the question is, whether the zero-padded upsampling is the best choice...
I thought its the most general one, a resample object can use it to do sample+hold, linear interpolation or any other type of filtering.
i agree that it should be an as simple as possible algorithm. zero-padding between samples is very simple, even simpler is zero-padding at the end of the block (but otoh, the filtering gets more complicated then)
If I remember correctly, you can do downsampling by lowpass filtering inside the child, and let the picking of samples up to the inlet. This should give you a perfectly downsampled signal (because you removed the frequencies above the parents nyquist frequency). The only thing that you need to know is the resampling factor in the child patch.
i admit that it could have been done better (right now, if you really want "cleanly" resampled signals, you need to do filtering of the signal outside of the child anyhow)
Really ? Isn't that too late, as you already have the aliasing in the signal ?
it seems like you are referring to the child as being upsampled in relation to the parent, while i was thinking the other way round.
so if the child is downsampled (with a lower sampling- and thus nyquist-frey), we have to do some filtering before the actual downsampling process, in order to avoid aliasing (because when we are downsampled it is too late). my idea was, that the parent patch need not know anything about the sampling frequency of the child, so if the child was downsampled, then the downsampling algorithm itself has to take care of the pre-filtering.
this can be done with "intelligent" iolet~s (as it is now; but this is bad since they will never be as intelligent as one would like them); it should also be possible with an added sub-patch level between parent and child which does the pre/post filtering as needed.
well for a misunderstanding it always takes two, I really have to learn to read between the lines in a positive way.
after all, the sun breaks through the clouds....:-)
mfg.asdr. IOhannes
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
#X obj 100 100 inlet; #G tooltip reset the game
what i'll implement tonight is most likely:
#X obj 100 100 inlet; #V name reset_the_game;
then suppose one wants [inlet] to look red at once:
#X obj 100 100 inlet; #V color red;
the combination of both will look like:
#X obj 100 100 inlet; #V name reset_the_game , color red;
because , is the A_COMMA as found in messageboxes; so "name" and "color" are selectors in #V. This will also be loadable as:
#X obj 100 100 inlet; #V name reset_the_game; #V color red;
but pd won't remember the difference so will save using only the first form.
Also note that "color" is reserved for the color of the objectbox while "icolor" (or any other name that you suggest) will be used for the color of the inlet itself.
At runtime, for each t_gobj *x, those values will be held in g_adix->g_adix->visual, which is of type t_hash *.
Note that t_hash is not thread-safe, because i'm lazy.
Semicolon still ends each line, because absence thereof still signifies continuation of the same line, because it's really not worth it to introducing parsing rules specific to #V (or to your #G).
any pd interpreter could just omit lines starting with "#G", and still the functionality of the patch would be untouched.
That's also one of my goals.
an interpreter could also choose to ignore certain tags in the #G lines (e.g. no fanzy color support).
The problem is that Miller's Pd will ignore #V upon load, so saving back will remove #V information from the file.
#G (like "Gui") is attached to the preceding "#X" line. i would prefer "#P" (Properties), but this is already taken
The problem with "Properties" is that everyone else's "Properties" are already stored in the #X line. To complicate matters, many object classes (IEMGUI and anything that was created by copypasting IEMGUI files) have visual (patch-only) properties stored in #X. Makes you wonder what the right-click menu should look like when a class has both #X properties and #V properties.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 30 Jun 2006, Mathieu Bouchard wrote:
what i'll implement tonight is most likely: #X obj 100 100 inlet; #V name reset_the_game;
I've implemented #V, but not any handlers for it. This means that it can load and save #V directives and will preserve any content. The order of #V directives is not preserved for a given object, because it is stored in a t_hash.
I was thinking about supporting one atom per property but ended up supporting a whole list per property instead.
Patchcords can have #V directives too, because they partially count as being objects themselves (t_outconnect is now an extension of t_gobj and it's now allocated using pd_new instead of getbytes).
because , is the A_COMMA as found in messageboxes; so "name" and "color" are selectors in #V. This will also be loadable as:
turns out that , is a A_SYMBOL after parsing, and that messageboxes further munge arglists by turning the , A_SYMBOL into the A_COMMA.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jul 3, 2006, at 2:59 PM, Mathieu Bouchard wrote:
On Fri, 30 Jun 2006, Mathieu Bouchard wrote:
what i'll implement tonight is most likely: #X obj 100 100 inlet; #V name reset_the_game;
I've implemented #V, but not any handlers for it. This means that it can load and save #V directives and will preserve any content. The order of #V directives is not preserved for a given object, because it is stored in a t_hash.
I was thinking about supporting one atom per property but ended up supporting a whole list per property instead.
Patchcords can have #V directives too, because they partially count as being objects themselves (t_outconnect is now an extension of t_gobj and it's now allocated using pd_new instead of getbytes).
because , is the A_COMMA as found in messageboxes; so "name" and "color" are selectors in #V. This will also be loadable as:
turns out that , is a A_SYMBOL after parsing, and that messageboxes further munge arglists by turning the , A_SYMBOL into the A_COMMA.
On a related note, if you are reconsidering properties panels, I strongly encourage all y'all to make them Pd patches. This is how Max/MSP does it and I think it would work very well for Pd as well. Sounds like this is a good opportunity to make the switch.
.hc
------------------------------------------------------------------------
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
On a related note, if you are reconsidering properties panels, I strongly encourage all y'all to make them Pd patches. This is how Max/MSP does it and I think it would work very well for Pd as well. Sounds like this is a good opportunity to make the switch.
I guess (?) max uses a internal variable to connect the edit patches and GUI objects. In case the properties-patch gets implemented, I would suggest that this internal-send-mechanism doesn't interfere with the already common send-receive mechanism, as it is one of Pd's neatest and 'individual' features. For example one of the inconveniences of my gui-edit patch is that the receive-symbol (and occasionally send) of the GUi must be edited, and then put back to 'normal' (in case a $0-variable is used). With this backstage temporal connection things would be even faster.
And, still assuming that this idea would get forward, it would really be necessary to implement query of GUI objects to know all the current parameters (for now only possible with the position of a cnv). Or, as it happens now, each properties patch is made from 0. To make new objects is this works (for example, I implemented the standard values), but to edit already existing ones (2 pixels wider, slight color change, etc.) is a pain.
speaking of colour, that would bring up the colour schemes question.... well, you know what I mean. (I guess sometime all these small incongruencies will be solved, it just takes a bit of time - but the later the sollution, the bigger the problem)
Joao
On Jun 25, 2006, at 5:43 AM, Tim Blechmann wrote:
On Sat, 2006-06-24 at 14:51 -0700, Hans-Christoph Steiner wrote:
I suppose it would be possible if the DD devs started submitted patches to the patch tracker. Miller accepts the majority of them these days.
i admire you enthusiasm, but from my own experience, i must state, that the pd development process is not as interactive as you describe ... the biggest problem is that no one knows, if a patch will apply to future versions of pd ... i did a lot of porting of patches from 0.38 to 0.39, and i definitely don't want to go through this process again ...
So there has been much talk over the years about doing this, I think there needs to be more action. Any volunteers?
well, i guess, the volunteers are there and they took action ... but they don't work on miller's branch ... matju and chun did quite some work on desire data, forking from miller's pd, and i'm writing my own engine, which will be combined with christian klippel's gui 'karma' ... while pnpd/karma is rewritten from scratch and thus wouldn't be interesting for the future of the pd development, i guess, that the desire data developers doubt that their code would be included into miller's pd ... (this is somehow understandable, as it's not only a 5 lines patch) i was following this discussion with great interest, but i'm still remembering guenter's tool tips patch, that where written for 0.38 and ported to 0.39 ... they are not a big patch, but it never made it into miller's pd ...
imo, the problem of pd's development is not the lack of ideas, but the lack of collaboration ...
I'll second that. There is a lot of good development going on in Miller's Pd, pd-devel, and desire-data, too bad it can't be all in the same package. But yes, porting patches is not a fun way to spend time.
.hc
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Jun 24, 2006, at 12:17 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 23, 2006, at 2:48 PM, Frank Barknecht wrote:
I would prefer something like a tooltip. IIRC I never ran into the
Personally, I find tooltips far more distracting that just a tiny bit of color on the screen.
If the tooltips have a longer delay until they show up, may that's endurable?
I find popups annoying in general. I guess Windows people are used the them, and they have unfortunately been emulated in KDE and GNOME.
How about displaying this information in a status bar, like at the bottom of the patch? That's how Max/MSP does it, IIRC, and I think that works quite well. Its easy to find if you want the info, and easy to ignore if you don't.
.hc
------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
On Fri, 23 Jun 2006, Frank Barknecht wrote:
Additionally I think, that there is no natural connection between the graphical signal: "object colored differently" and the information to be transported: "default value is overwritten".
Pd had to be learned. There's not much natural things in Pd. After Pd is learned, it may seem contextually natural that a certain thing be done a certain way. However, Pd doesn't have a vocabulary of colours.
(Some of my patches introduce a vocabulary of colours, such as: yellow is configuration; light green is monitoring; green means "start"; red means "record" or anything that one has to be careful with. However I've not been too consistent with that and I've never really tried getting other people into a standard of color codes)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
carmen -
Federico -
Frank Barknecht -
geiger -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
João Miguel Pais -
Julian Oliver -
Luke Iannini (pd) -
Martin Peach -
Mathieu Bouchard -
padawan12 -
Thomas Grill -
Tim Blechmann -
zmoelnig＠iem.at