[PD] (Solved) pd~ subprocess not responsive

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2014-09-08 05:17, Max wrote:
> Both are vanilla. What I am using is the Debian package Pd 0.45.4
> and what I compiled and installed was Pd 0.46.0.

for what it is wort: Debian already has 0.46.0 in testing [1].

> I can't use the newer one because I wasn't able to get it to
> compile with jack... but that's another issue. I am fine with  Pd
> 0.45.4 for the moment. I am not 100% sure what was going on, but
> the paths were "polluted" after the install so the repository
> version looked for pd~ in the wrong place. The pd~ which was found
> there did not work, may be because it was compiled without jack?

let me recapitulate your setup:

- - debian "puredata" (0.45) package installed
 - lives in /usr/lib/puredata/
 - has jack enabled
- - self-compiled "pd" (0.46) package installed (with "make install")
 - lives in /usr/local/lib/pd
 - does not have jack enabled
- - your .pdsettings has (well: had) "/usr/local/lib/pd/extra" in it's path

- - you start Pd via the desktop-menu, which really starts
"/usr/bin/puredata" (0,45; the debian package)
- - it finds (and tries to use) the "pd~" in /usr/local/...
- - and fails.

is that correct?

the jack-error you get indicates some problem with jack, but it might
as well not (and it would be *very* weird if the pd~.pd_linux having
*no* jack support would trigger a problem here. butthen: who knows?)


> 
> m.
> 
> On 09/08/2014 04:06 AM, Miller Puckette wrote:
>> This is strange - Pd extended should be using a different spot 
>> (~/.pdextended on linux) than pd vanilla to store user
>> preferences. So I don't know why the two should be stepping on
>> each others' toes like this.

i don't think this is the case at all (i mean: there is no stepping on
anyones toes).

someone added /usr/local/lib/pd/extra/ to the search path of
*pd-vanilla* (either the user or some external - e.g. mine have a
reputation for fuddling with the search path), and this led to some
conflict.

i don't see much we could do about that apart from putting a
Pd-version check inplace and issue a bold warning if somebody tries to
load an external compiled for another version of Pd.
and then: we probably don't want to go there (since Pd has a very
stable external ABI, and this is one of it's features).

so if my recapitulation above is correct, then the only problem we
were seeing was, that the external launched a non-working version of Pd.
this is probably a thing that can
be fixed in pd~: i guess it is sane to assume that [pd~] should really
launch the same version of Pd it is running in (rather than the one it
is relative to): that is when running
 $ /home/foo/mystuff/pd/bin/pd -lib /usr/local/lib/pd/extra/pd~
then pd~ should *also* start /home/foo/mystuff/pd/bin/pd rather than
/usr/local/bin/pd

if this is not the case, than we have the simple case that we have two
(conflicting) versions of an external installed, and the way Pd loads
externals preferred the buggy one.
i don't think there is anything we can really do about that, apart
from changing the search path order, which i think is a no go.
(after all, the search path order has been constructed in order to
allow a bugfixed external replace a buggy system-shipped one; alas! it
can be used in the other way round as well)

fgmdsr
IOhannes




[1] https://tracker.debian.org/pkg/puredata

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUDVyGAAoJELZQGcR/ejb4kJMP/iH2QwgtvUIt+atFR8UECREH
QI0cyIX0Glzv9DR4qus5danqmfAVYCowmVEdIM3hlzCrUCNU8S+hxJP7JVGqlZyH
TQGSIDGW41SWwzNanns461wLPk4QoRUB0ILu9HNHpXxr+YHNs2MfQsrDaS6c8M99
W/LdZgnwo9EQsxn6R0meyxExoDh6cQWn+A//2XE9iCEY1x+b8tUk9PUnfmjMUdqs
p5mPJ1DNYQ05z+jWEeUdQvkhjoMPnCfMkeBzBv0n+yK+GeZ/ES6vaY+rzJWjB9aU
R7dA/oIazHwig8+R/JIlSt15GA/8F9UocAVzRglYwoTwCEI2PukyQNlV8NDNZbzC
/w1V9/SI8jX3rG9jI7wzadrw0QJ40BblLxz/4uBpxPDeU4vSSbsmXKDENatlVWTS
mBAw7Nf0KhJeg4fXk4AX1Qt+kRBvS3EJx28LXKsqB6+yMt0Nlm+3rxHdjINGj6rj
9OMsN/qpemcf51wYYai8Ow59K5PBTaVCUdRfQzemqBpeRA7JwtjcUWswunsg8/Qs
xpXjeU8yBnGKLtf7LB6J7oqIuby9WrjejzgdO5HhZKZqGqo6Ziv5i1MErMf4PU/k
AoGAp4m7D93qkrrff7Pd3sLB/+69H17UTH65pFHhhg+oGCw2xsfKthrvf8GaORQ6
gHDafH3gi4mbU2pDUwml
=8wFz
-----END PGP SIGNATURE-----