-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
(I think the Gem error is unrelated, so I'm better opening another thread)
with the pd~-help i am experiencing the problem, that I can't move the objects in edit mode, clicked message boxes will keep their highlighted border permanently. That's only in the child process. Audio and Messages however can be sent from and to the subprocess.
SOLUTION
before sending the mail I found the problem, It may be useful as a future reference, so I am sending it anyways:
I suspect that when trying to install the current Pd, I re-set the path settings.
So in verbose mode I noticed that pd~ was found in /usr/local/lib/pd/extra I removed that path from the path settings and now pd~ is found somewhere else. It is the same (v0.3) but it works now.
tried /usr/lib/puredata/tcl/../extra/pd~/pd~.pd_linux and succeeded
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.
chers Miller
On Sat, Sep 06, 2014 at 11:20:55PM +0900, Max wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
(I think the Gem error is unrelated, so I'm better opening another thread)
with the pd~-help i am experiencing the problem, that I can't move the objects in edit mode, clicked message boxes will keep their highlighted border permanently. That's only in the child process. Audio and Messages however can be sent from and to the subprocess.
SOLUTION
before sending the mail I found the problem, It may be useful as a future reference, so I am sending it anyways:
I suspect that when trying to install the current Pd, I re-set the path settings.
So in verbose mode I noticed that pd~ was found in /usr/local/lib/pd/extra I removed that path from the path settings and now pd~ is found somewhere else. It is the same (v0.3) but it works now.
tried /usr/lib/puredata/tcl/../extra/pd~/pd~.pd_linux and succeeded -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEUEARECAAYFAlQLGEcACgkQ3EB7kzgMM6KaFQCVGMrbYAuT2WxUJ5AWmOYlULvs mACfdZL/n8QFKM8rkpiSB5dHtrnX5rs= =umwA -----END PGP SIGNATURE-----
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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. 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?
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.
chers Miller
On Sat, Sep 06, 2014 at 11:20:55PM +0900, Max wrote: (I think the Gem error is unrelated, so I'm better opening another thread)
with the pd~-help i am experiencing the problem, that I can't move the objects in edit mode, clicked message boxes will keep their highlighted border permanently. That's only in the child process. Audio and Messages however can be sent from and to the subprocess.
--- SOLUTION
before sending the mail I found the problem, It may be useful as a future reference, so I am sending it anyways:
I suspect that when trying to install the current Pd, I re-set the path settings.
So in verbose mode I noticed that pd~ was found in /usr/local/lib/pd/extra I removed that path from the path settings and now pd~ is found somewhere else. It is the same (v0.3) but it works now.
tried /usr/lib/puredata/tcl/../extra/pd~/pd~.pd_linux and succeeded
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Odd - I just now tried recompiling Pd 0.46 with jack and it compiled and ran fine (on Fedora 20)... just did "make -f makefile.gnu JACK=TRUE" in pd/src and no problems. I'm curious what went wrong for you.
cheers M
On Mon, Sep 08, 2014 at 12:17:25PM +0900, Max wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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. 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?
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.
chers Miller
On Sat, Sep 06, 2014 at 11:20:55PM +0900, Max wrote: (I think the Gem error is unrelated, so I'm better opening another thread)
with the pd~-help i am experiencing the problem, that I can't move the objects in edit mode, clicked message boxes will keep their highlighted border permanently. That's only in the child process. Audio and Messages however can be sent from and to the subprocess.
--- SOLUTION
before sending the mail I found the problem, It may be useful as a future reference, so I am sending it anyways:
I suspect that when trying to install the current Pd, I re-set the path settings.
So in verbose mode I noticed that pd~ was found in /usr/local/lib/pd/extra I removed that path from the path settings and now pd~ is found somewhere else. It is the same (v0.3) but it works now.
tried /usr/lib/puredata/tcl/../extra/pd~/pd~.pd_linux and succeeded
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQNH8QACgkQ3EB7kzgMM6LxOgCfYrQNOnkpwW7RTdF7jLABRpZU TuYAnR60+Rp/g6uCjVoEND0FdP7qVZ8G =3ekb -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
do you use jack1 or jack2? I have to use the later.
Anyways, I solved it. Didn't have the development files installed. after adding libjack-jackd2-dev it compiled. Was getting this before:
make -f makefile.gnu JACK=TRUE cc -DPD -DHAVE_LIBDL -DHAVE_UNISTD_H -DHAVE_ALLOCA_H
s_audio_jack.c s_audio_jack.c:15:27: fatal error: jack/weakjack.h: No such file or directory #include <jack/weakjack.h> ^ compilation terminated. make: *** [s_audio_jack.o] Error 1
On 09/08/2014 12:30 PM, Miller Puckette wrote:
Odd - I just now tried recompiling Pd 0.46 with jack and it compiled and ran fine (on Fedora 20)... just did "make -f makefile.gnu JACK=TRUE" in pd/src and no problems. I'm curious what went wrong for you.
cheers M
On Mon, Sep 08, 2014 at 12:17:25PM +0900, 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. 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?
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.
chers Miller
On Sat, Sep 06, 2014 at 11:20:55PM +0900, Max wrote: (I think the Gem error is unrelated, so I'm better opening another thread)
with the pd~-help i am experiencing the problem, that I can't move the objects in edit mode, clicked message boxes will keep their highlighted border permanently. That's only in the child process. Audio and Messages however can be sent from and to the subprocess.
--- SOLUTION
before sending the mail I found the problem, It may be useful as a future reference, so I am sending it anyways:
I suspect that when trying to install the current Pd, I re-set the path settings.
So in verbose mode I noticed that pd~ was found in /usr/local/lib/pd/extra I removed that path from the path settings and now pd~ is found somewhere else. It is the same (v0.3) but it works now.
tried /usr/lib/puredata/tcl/../extra/pd~/pd~.pd_linux and succeeded
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----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:
lives in /usr/lib/puredata/
has jack enabled
lives in /usr/local/lib/pd
does not have jack enabled
"/usr/bin/puredata" (0,45; the debian package)
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 SIGNED MESSAGE----- Hash: SHA1
On 09/08/2014 04:36 PM, IOhannes m zmoelnig wrote:
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].
cool, thanks for that. I guess it is just a matter of patience until it tickles down to Linux Mint.
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?
as far as I can tell, I think that's what was happening.
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?)
the Jack error is unrelated and is still there. It doesn't seem to do any harm though as it is running fine.
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)
I agree entirely. It did cost me some time to figure out what is happening, and that's frustrating. But if you'd ask me what could be done to make it better or foolprof - I don't think there is a flaw in existing way how it works.