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@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/
> > >
> > >
> >
> >
> >
>
>