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