Joseph A. Sarlo hat gesagt: // Joseph A. Sarlo wrote:

On Tue, 11 Sep 2001, Frank Barknecht wrote:

...

[and I don't think that putting the gui kinda outside of pd like in gripd is a real solution to the problem]

Why not? I'm not being argumentative, I'm just curious as to your, and others' thoughts on the matter.

I like gripd, that was not what I meant. But gripd IMO fills another niche: it allows one to build "performance patches" like in Reaktor, where only the important things are visible.

I like those GUI thingies in PD because they help me build patches and keep them clean.

A simple example is [tgl]. Without [tgl] I need one [1( and one [0( to control a [metro] and I don't see at one glance if the [metro] is on or off. With one [tgl] instead I do.

Also colors in PD patches help me finding my way.

Ciao,

                                             __    __

Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___\ / / / ____/ / / / // ____// /\ \ ___\____ \ /_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\

On Tue, 11 Sep 2001, Michal Seta wrote:

...

I like those GUI thingies in PD because they help me build patches and keep them clean.

Also colors in PD patches help me finding my way.

I agree...

Me too. I use the iem stuff all the time (and ggext before that). I think including them in the PD distribution is probably a good idea from a usability standpoint, but it might make it a little more difficult to pull PD away from tcl/tk. I think this is probably Guenter's point. Personally, I would be interested to know what Miller's plans are.

And I think I would rather see more features added to gripd (and I'm sure more of such gadgets will pop up)

Any suggestions?

And then the proper credit should be given :)

I agree, anybody that voluntarily writes tcl/tk deserves all the credit he can get! ;)

-- ______________________________ | | Joseph A. Sarlo | | jsarlo@mambo.peabody.jhu.edu |______________________________

Hi all,

Well, first of all, I don't think incorporating the GUI objects from IEMLIB will make Pd any harder to extricate from tk if that ever has to be done. It can always be fixed so that when you import a Pd patch into some newer, leaner Pd, all those controls just revert to number boxes, or to some much simpler, less versatile GUI objects that anyone could write quickly...

My own question is how to prevent confusion when all the controls can have "send" and "receive" connections that you don't know about until you open the dialog. Someone could get in serious trouble copying and pasting sliders and wondering why they all seem to jump at once...! Also I'm baffled how to deal with dollar signs in send and receive names for GUIs.

I'm not too worried about efficiency problems since in any case you have to limit the number of graphical controls you have visible if you want your patch to run well. Someday I want to implement a kind of flow control to ease this situation, but then you'll just see the interface react slower and slower as you add creamy GUI objects to your patch.

No, I don't think color is CPU-expensive... it's probably all those labels on the VU meters that are the real killers (the more stuff you have on the screen the more things TK has to check if it needs redrawing when sonething changes).

Anyway, I have many more thoughts than that, but I'm focussing on getting ready for ICMC right now... :)

cheers Miller

On Tue, Sep 11, 2001 at 05:37:30PM -0400, Michal Seta wrote:

Frank Barknecht wrote:

...

I like gripd, that was not what I meant. But gripd IMO fills another niche: it allows one to build "performance patches" like in Reaktor, where only the important things are visible.

In my opinion this is what the gui is supposed to be for :)

...

I like those GUI thingies in PD because they help me build patches and keep them clean.

A simple example is [tgl]. Without [tgl] I need one [1( and one [0( to control a [metro] and I don't see at one glance if the [metro] is on or off. With one [tgl] instead I do.

Also colors in PD patches help me finding my way.

I agree...

I admit that I was just thinking of the iemlib vs gripd issue... If you remember I reported a problem using gripd. So, as I was somewhat desperate, I built my gui with iemlib. The whole thing. I'm rebuilding it with GriPD as well but I'm not in a hurry anymore... since I'm planning, perhaps, releasing the thing to the public at some point I thought that GriPD will be "cuter" ....

However, iemlib is great for quick things. More like testing/prototyping. I would probably not use gripd early on during patch development. But then, it's possible in any case....

And I think I would rather see more features added to gripd (and I'm sure more of such gadgets will pop up) than iemlib. But we should not underestimate the usefulness of iemlib. And then the proper credit should be given :)

mine 0.02

./MiS

hi,

right, you can either escape it ($), or simply write a hash (#) in the properties dialog, but then you cannot save instantiated abstractions, because the gui objects have their own saving functions which know of the instantiated parameters and not of the template form of parameters (unless you save the template).

If you do save an instantiated abstraction -- and 1) it should be allowed; 2) it is very easy to make such a mistake accidentally (by pressing Ctrl-s instead of Ctrl-w or Ctrl-e or even wanting to save the parent patch while abstraction window is active) -- then all your parameters are gone.

Krzysztof

marius schebella wrote: ...

i tried to use dollarsigns in the GUI-Objects and after some trying i found maybe a possible handling: if you type "$1" instead of "$1" the properties-dialog takes it and next time fills it with the arguments given.

hi,

actually this behaviour was changed in non-test 0.34 and now #0 (aka $0) used in gui objects is treated in special (shell I say hackish?) way -- you seem to be using some older Pd version?

Krzysztof

dieb wrote:

my problem with the #0 and $0 thing is: i can save a gui object with #0 in it and it gets replaced correctly on the nextloading, but if i save the patch again after doing some changes. the number is stored instead of #0 or $0. so saving only works once...

...

hi,

yes, it is broken...

the reconvert2unique() function added to g_7_guis.c in 0.34-2 in order to patch one hole has apparently opened another one. It does what should never be done: changes the name of a symbol stored in symbol-table (probably it would work if it was done to a copy of this symbol)...

but anyway those $-send/receives in gui objects are simply experimental, do not use them (yet?)

Krzysztof

d wrote:

hi krzysztof, hi list! after downloading and installing pd0.34-2 the $0/#0-hack doesn't work in any way for me... no reaction with "send $0-xyz", no reaction with "send 1000-xyz". it seems totally broken.

...

hi all,

while the wise men ramble sunny beaches of Cuba, this thread is dying, so let me try to keep it alive until after ICMC.

At least five questions come into mind. I would like to know the answers, particularly to Q1-4. What I can offer are only loose comments -- very simple and naive.

Q1. What kind of a gui frontend is best suited to help developers of Pd patches during patch composition, testing etc?

I agree with Guenter that in order to help developing Pd patches and make them more readable, one could think of extending the frontend in many other ways, apart from simply having a few nice widgets. Also those widgets could be designed in many different ways. As stated in the html manual (2.6.2), one of Pd design principles is `printability' of patches. In this sense hiding object's behaviour attributes (like send/receive symbols) in a properties dialog takes some purity away from PureData.

Maybe the appearance properties should be kept separate from the behaviour attributes, or maybe even better to delegate behaviour of some of the more complex widgets entirely to the middle layer `glue' between beckend and frontend (see Q4).

Q2. How patch developers should link implementation backends of their patches with gui widgets of the kind choosen (hopefully) after considering Q1?

At first thought it would appear to better rather not to mix guts with guis. In max at least one could hide the guts while in performance mode, which is, however, only a partial solution. Designing guis on top of the guts could be tricky even if those guts are to be hidden later on. And oftentimes one would want to see things the other way around, with no guis cluttering appearance of a patch designed to graphically reflect static concept of an algorithm, rather then to track dynamic process of its execution.

Such reasoning is hardly specific to Pd or max, having in mind all the classic concepts of information hiding, modular design, providing encapsulated implementation for public interface etc.

But since keeping guis and guts separate by placing them in different windows usually involves many nonlocal connections, one can easly find the overall design of such patches even more patchy.

Q3. What kind of a gui frontend is best suited as a final performance surface?

Of course any judgment will depend on intended use of Pd (be it in studio, on stage, off stage or in any other environment) and also on target user taste and skills. Better to keep the options wide open.

Q4. How patch developers should link implementation backends of their patches with performance surface of the kind choosen (hopefully) after considering Q3?

In my work I often add a middle layer `glue' between performance surface and the actual interna of the patch. Since currently there is little support in Pd for such a middle layer, this is sometimes the trickiest part of the whole design. The more obvious tasks of the glue are grouping gui objects and synchronizing user actions with backend's feedback to the gui.

Q5. Which is the best way to internally link Pd with its graphical frontend(s)?

Perhaps I should have started from question 5, because this was the main subject of GG's thoughts. But answering this question would need someone much more experienced and sober then myself. Let me only say I support Guenter's view that it would be nice to have a well-defined generic protocol, which should then be used, exclusively, at Pd side, and which would allow easy porting of the gui side to any graphical toolkit. The hard part seems to be first designing a protocol both small and really generic, then making all the changes to the code -- a huge task.

Another matter: do not forget iemgui in its present form is probably only the start, as more and more gui goodies will be added, following max with its pictctrl and the likes. Taking the right decisions now is important.

K-red-eye-pink-nose-of

hi,

I'll take a stab at this for the sake of reanimating the dying discussion... Obviously, it's very subjective. If other people contribute we'll have a nice overview of different people's working habits :)

(I'm just brain storming here)

On 9/18/01 12:13 PM, "Krzysztof Czaja" czaja@chopin.edu.pl wrote:

Q1. What kind of a gui frontend is best suited to help developers of Pd patches during patch composition, testing etc?

When I first started looking at PD I had quite a bit of experience with Max so the first thing that struck me was that there was no gui (some 2 years ago). In retrospect, I think it was a good thing because it helped me to organize my patches better. I could no longer stick everything in the same window and just hide stuff I didn't need to see in the 'performance' version. So since then, I've developed a way of building the patches (quite unconsciously) in the MVC (Model-View-Controller) way if I can call it that way. So, starting with all the guts, getting the patch do what I think I want it to do and then moving into ways of controlling it with GUI if necessary. So a short answer is that for developing a patch I don't need a GUI. Well, I didn't need one until I started incorporating iemlib. However, I do test my designs right from the beginning so having some GUI objects kicking around is fun when you want to do some testing. So I prefer to use a graphical bang to see what's happening and when or VU meters and such. Of course, the more GUI items one has the more one will use even in early development and although that might contribute to better looking patches it probably isn't (at least for me) helping to organize the algorithms and data flow.

So now, for the short answer (aesthetic reasons aside): iemlib kind of gui is just fine with me. Definitely I prefer having the gui items available to me directly within PD rather than having to switch back and forth between 2 different applications.

I agree with Guenter that in order to help developing Pd patches and make them more readable, one could think of extending the frontend in many other ways, apart from simply having a few nice widgets.

Actually, one thing I was thinking about lately is some kind of an 'inspector' (yeah, I know, I've been using a Mac for too long) that will show you a list of all the sends/receives in your current (root)patch. And then, of course, segmented patch cords and colors... (No, I don't miss Max/MSP, but I do think they're great features).

Q2. How patch developers should link implementation backends of their patches with gui widgets of the kind choosen (hopefully) after considering Q1?

In my case, I use both patch cords and messages. It depends on the feature/context I'm trying to control with a GUI object. Patch cords are great for quick testing. Messages for things that are more or less sure in the backend implementation but some tweeking is still needed for various tests and we're not yet ready to move to the 'raal' GUI (from Q3).

So, I'm still fine with iemlib. Now, extending my 'inspector' idea, when you interact with a particular GUI object that send a message to some thingy deep down in the guts the send/receive pair flashes. And when you click (or double-click) on it it takes you right there. Cool, eh? OK, I know I'm exaggerating.

At first thought it would appear to better rather not to mix guts with guis. In max at least one could hide the guts while in performance mode, which is, however, only a partial solution. Designing guis on top of the guts could be tricky even if those guts are to be hidden later on. And oftentimes one would want to see things the other way around, with no guis cluttering appearance of a patch designed to graphically reflect static concept of an algorithm, rather then to track dynamic process of its execution.

While developing the patch and forming ideas I do tend to mix those. However, when the logic of particular 'module' or a group of them is clear I get rid of the GUI elements and eventually move them to a higher level. So it is useful to have those around when you need them.

But since keeping guis and guts separate by placing them in different windows usually involves many nonlocal connections, one can easly find the overall design of such patches even more patchy.

That's where my inspector comes in handy :)

Q3. What kind of a gui frontend is best suited as a final performance surface?

Of course any judgment will depend on intended use of Pd (be it in studio, on stage, off stage or in any other environment) and also on target user taste and skills. Better to keep the options wide open.

Definitely. However I would suggest some kind of a streamlined guidelines of the implementation of such frontend. I think this was one of Guenter's concerns as well... I found, when I was trying to implement a GUI for the same application with iemlib and gripd that there were some differences. For example the sliders in gripd send only ints. Although it's not a problem and once you are aware of that you design your patch accordingly but if you do your development with iemlib and get too used to the sliders that can sent floats between -1 and 1 you eventually have to go back to your design just to divide the slider's output in some places. And it goes vice versa: if you design with gripd in mind and stick a slider from iemlib just for testing .... blah blah blah.

Q4. How patch developers should link implementation backends of their patches with performance surface of the kind choosen (hopefully) after considering Q3?

In my work I often add a middle layer `glue' between performance surface and the actual interna of the patch. Since currently there is little support in Pd for such a middle layer, this is sometimes the trickiest part of the whole design. The more obvious tasks of the glue are grouping gui objects and synchronizing user actions with backend's feedback to the gui.

I, too, found myself designing a 'dispatcher' that's collecting messages from the gui and sending them to appropriate places and vice versa. But hey, this could extend the inspector and we could have a 'dispatcher building wizard'! (please, somebody, stop me!)

I think, though, that this is a personal choice of each patch developer. I don't even think we should be given a set of choices to link frontends with backends. I do think that send/receive is quite appropriate but it'd be nice to have an easier access to send/receive pairs (inspector!) because at a certain level of complexity of the patch things get a bit messy.

Q5. Which is the best way to internally link Pd with its graphical frontend(s)?

well, that's a question for a developer who knows already a bit about present state of PD<->gui and has seen different solutions elsewhere.

As a user I would like to see, as I mentioned earlier, some streamlined behaviour of similar types of objects (between different guis, of course). So I do think that the 'protocol' idea is a good one. Especially since it is to be expected to see different 'gui toolkits' in the future. In such a case, it'd be nice to mix them at will...

hope I made any sense....

./MiS