[PD-dev] Pd-Extended - pixelTANGO broken

[B. Bogart]

Hey Hans,

Thomas, I'm CCing you as well, since I seem to be getting lots of
crashes from pool in pd-exented, see the attached logfile.

It took me ages to take a look at pd-extended so I'm working on it today.

#1. PixelTANGO needs the pt.py script which is in pixelTANGO/scripts in
the PD abstractions CVS. This file should be included in the pixelTANGO
libdir.

I took a look at the extended build makefile, but I have no idea where
to put this. I guess I should move the "scripts" just into "abstractions"?

Any ideas about the best way to deal with abstractions that depend on
python parts?

Looks like all the "py" examples are also broken for the same reason, py
can't find the corresponding python scripts:

py - No namespace available
ImportError: No module named script

#2. For some reason PD is looking for stripPath_setup, [stripPath] is an
abstraction that wraps [py pt stripPath] it seems to function fine,
dispite pd complaining that it can't find the stripPath_setup symbol.

#3. Loading patches with many externals that have not been used yet
takes forever, "Two-Layer-Example.pd" from pT took about 3 seconds to
load, we really need to change the pointer to reflect that pd is loading
and not doing nothing.

#4. PD seems to frequently exit, I close a pT example patch and boom, PD
quits, not does not crash, gdb things pd exists cleanly, but all I did
was close a patch, not the problem. This has happened several times. I
finally got a OSX crashlog for this (attached), but gdb still said PD
exited normally. I see lots of pool functions in there...

#5. The GUI is certainly a lot less responsive for some reason, looks
like tk issues though, simply opening a [popup] in pixelTANGO seems to
take over a second... Any ideas on how to figure out why this is
happening? It actually seems like the same example patch in the
pixelTANGO.app runs much faster than in pd-extended, even the OSX dock
responce is slow... (just doing a motionblur on a single DV file). Ah, I
turned on the "defeat real-time scheduling" startup flag and now it
seems to be running great. Maybe that should be the default for
pd-extended? Of course I have not played with how it effects audio
processing.

#6. How to deal with meta-data like pool.dat files? I can open an
example in the browser, but if I want to open a memento datafile it
depends on using [openpanel] I can't navigate to it, let alone the end
user will have no idea where to find it. This is why I has pushed for a
pixelTANGO .app approach where the examples/ is an exposed directory
under a pixelTANGO directory that contains the pixelTANGO.app. I'm not
sure how else to solve this issue, since the contents of a .app is
supposed to be hidden... but example files probably should not be
hidden... since they do need to be naviagable... I guess for pd-extended
the [openpanel] should default to the same folder as the browser does...
then it should be easy to find support files...

#7.I think the browser should only open a pd file on double-click I find
myself constantly clicking on more than one entry and those pT patches
take a while to load!

#8. I need a better system for pT's dependance on fonts, I could use a
python script that checks a few places for fonts on all platforms, and
then choose the first it finds... or do I need a build system for fonts
that will tell the patch what to load depending on the platform?

Ok, a few bugs here and there but I think with a little tweaking I got
pT working in pd-extended working as well as it does in the pixelTANGO.app

Thanks Hans for all the work here, I think we're really close to a great
pd package.

.b.




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.txt
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20060316/0751af40/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20060316/0751af40/attachment.pgp>