[PD] thoughts about iemlib (from Cuba... )

[Miller Puckette]

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