[PD] GrIPD: A new front-end GUI builder for PD

[Joseph A. Sarlo]

On Thu, 12 Jul 2001, Michael Droettboom wrote:

> Python's garbage collection is irrelevant in this case, since GrIPD runs
> as an entirely separate process completely uninvolved with any audio
> signals.  It is
> theoretically possible the GC may cause (very) momentary glitches in the
> control signals between PD and GrIPD, but I doubt they could possibly be
> noticable.  Plus, there is very little memory allocation/deallocation (if
> any) that occurs during the runtime of GriPD.

Yep. I can't think of any allocation/deallocation that occurs during
Performance Mode usage, unless it's deep under the hood of the wxPython
classes.

-- 
 ______________________________
|
| Joseph A. Sarlo
|
| jsarlo at mambo.peabody.jhu.edu
|______________________________



> On Thu, 12 Jul 2001, jfm3 wrote:
>
> > This is pretty cool.  How do you deal with the real time vrs. garbage
> > collection problems in Python?
> >
> > (jfm3)
> >
> >
> > Joseph A. Sarlo wrote:
> >
> > > GrIPD is an extension to PD that allows one to design custom graphical
> > > user interfaces for PD patches.  GrIPD is _not_ a replacement for the PD
> > > Tcl/Tk GUI, but instead is intended to allow one to create a front end to
> > > a PD patch.  The concept is to create your PD patch normally and then your
> > > GUI using GrIPD (similar to SuperCollider or Reaktor). You can then lauch
> > > PD using the -nogui command line argument (although this is certainly not
> > > necessary) so only your custom front end will be displayed.
> > >
> > > GrIPD is available for Windows and Linux.
> > >
> > > Check it out at:
> > > http://mambo.peabody.jhu.edu/~jsarlo/gripd/
> > >
> > >
> >
> >
> >
>
>