[PD] Re: py/pyext (offlist)

[Thomas Grill]

Hi David,
i'm cc'ing this to the list - there might be others having the same 
problem or people who can help you better than me.

> Hm, I tried adding the script directory to my PD paths, and it didn't 
> work, then I restarted PD and it didn't work, then I tried copying all 
> the scripts to the "examples" directory (where the example patches I 
> was trying are located) and it still didn't work.  
It would be helpful to have more detailed information, like what exactly 
doesn't work under which circumstances. Try starting PD with the 
-verbose flag and try to provide a walk-through so that i can reproduce 
your situation.
> Again, [py] will load as an object but [pyext] will not, not even 
> typed in an object box by itself - it's like pd doesn't recognize the 
> symbol I typed, like I just typed junk.  
According to the error output you sent me, this doesn't seem to be the 
case. The pyext object is created ok, only the Python scripts can't be 
found.
> The [py] object never complained about finding the scripts before, but 
> they didn't seem to be working correctly either...
What exactly isn't working correctly?
>
> I'm actually using 0.2.1 from the pd-extended dist, copied into the 
> appropriate folders of my 0.39-2 release.  But all of these things 
> happen exactly this way using pd-extended as well.
>
The console output says that you are using version 0.2.0. So, if you are 
really having 0.2.1 in your PD package, then there's obviously another 
py/pyext binary somewhere in the path which is loaded beforehand.

best greetings,
Thomas

>
> On 2/16/06, *Thomas Grill* <gr at grrrr.org <mailto:gr at grrrr.org>> wrote:
>
>     Hi David,
>     pyext seems to run fine on your machine, only the Python scripts can't
>     be found.
>     They have to be either in the same directory as the current patcher or
>     in the PD load path (where also the externals are found) which can be
>     set in the "Path..." menu dialog.
>
>     What i find a bit strange is that according to your console printout
>     [pym] wants to be loaded and gives an error. If i'm not mistaken this
>     is only included in pyext >= 0.2.1 which is the cvs version, not the
>     packaged one that you a using. Do you have a mixup of versions? Well,
>     first try to fix the path and let's see if pym is ok, or not.
>
>     best greetings,
>     Thomas
>
>     Am 16.02.2006 um 06:52 schrieb david golightly:
>
>     > Hi Thomas,
>     >
>     > Hope I'm not bothering you here, just wanted to make sure I'm doing
>     > things correctly... are you still maintaining py/pyext? I got the
>     > most recent WinXP binaries from your website as well as the
>     > pd-extended distro & there doesn't seem to be any pyext.dll or
>     > pyext.py file - although the example patches use [pyext], this
>     > module/object fails to load - same with [pym] (although [py]
>     will at
>     > least load, but doesn't work at all). Am I missing something here?
>     > Using PD 0.39-2 and Python 2.4.2, I get messages like this in the pd
>     > console when I load the example patches:
>     >
>     > ------------------------------------------------
>     > py/pyext 0.2.0 - python script objects
>     > (C)2002-2005 Thomas Grill - http://grrrr.org/ext
>     >
>     > using Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
>     > (Intel)]
>     > ------------------------------------------------
>     >
>     > ImportError: No module named simple
>     > pyext simple ex1
>     > ... couldn't create
>     > ImportError: No module named sendrecv
>     > pyext sendrecv ex1 he hu
>     > ... couldn't create
>     > pym 2 *
>     > ... couldn't create
>     >
>     >
>     > By the way, thanks for doing all this work! These patches are
>     > brilliant. Once I get these externs running this'll be fantastic
>     > addition to my pd arsenal. A pity more pd'ers don't bother to
>     learn a
>     > bit of python - using these modules, externs are much easier &
>     quicker
>     > to write than either using C or native pd abstractions.
>     >
>     > Thanks,
>     >
>     > David
>     >
>
>

-- 
Thomas Grill
http://grrrr.org