[PD] thoughts about iemlib

[Krzysztof Czaja]

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