[PD] thoughts about iemlib

[Michal Seta]

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 at 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