Hi all,
Well, I{m in Cuba all rgith and have anice Cuban keyboard with American labels (colon hard to find to quit VI with) but I can at least read and enjoy...)
cheers Miller On Tue, Sep 18, 2001 at 06:13:01PM +0200, Krzysztof Czaja wrote:
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