@playinmyblues said:
In my op, I provide what I used to install it but I think that was just for Ruby.
Actually not:
$ apt show gem
... skipped some stuff...
Description: Graphics Environment for Multimedia - Pure Data library
So it's definitely gem for pd.
I could not find the library anywhere on my Raspberry Pi...
I always forget this and I always have to do a google search for "linux apt list installed files," but:
$ dpkg -L gem
... long list of files, including a lot of them like this:
/usr/lib/pd/extra/Gem/GEMglBegin-help.pd
/usr/lib/pd/extra/Gem/GLdefine-help.pd
/usr/lib/pd/extra/Gem/Gem-meta.pd
/usr/lib/pd/extra/Gem/Gem.pd_linux
... where I pasted these specifically because the last one, Gem.pd_linux, is the actual library that gets loaded when you [declare -lib Gem].
Then you can infer that /usr/lib/pd/extra/Gem is the location to which the package is installed. (The point being that even in a command-line environment, there are ways to find out what was installed where. You might have to do some searching to find the commands. BTW I'm not using rpi now but its OS is based on debian, so these commands "should" be OK.)
As I see it, there are just a few possibilities:
- (1) Maybe
sudo apt install gem didn't install it properly. That seems unlikely (but, worth it to apt show gem to check the package metadata).
- (2) Or, maybe
sudo apt install gem did install it properly. That divides into a couple of sub-cases:
- (2a) Maybe Pd can't find the package. If that's the case, then what I would do is: go to the pd path preferences and make sure
/usr/lib/pd/extra is in the list. Then [declare -lib Gem] should find it.
- (2b) Or maybe the package is incompatible with RPi. In that case, everything would look right environmentally but the package simply wouldn't load.
For 2a, everybody -- everybody -- gets tripped up on pd external loading. For me, the best strategy has been to keep the Pd "path" preferences as simple as possible -- /home/your_user_name/Documents/Pd/externals for user-specific externals, and maybe add /usr/lib/pd/extra for systemwide packages -- and nothing else. Then the Gem/ root folder would go directly into one of these, e.g. /usr/lib/pd/extra/Gem. I rigorously avoid putting externals in any other locations.
Then, use a [declare] in the patch. [declare -lib Gem] tries path ++ "/Gem" for each of the entries in your path preferences. If you have kept things in standardized locations, this will work.
Maybe try this with a different external package first, one that is RPi compatible, to make sure that you understand the mechanics. (I've seen a lot of threads where people were haphazard about external installation and got tied up in knots. It's really worth some time to get it right, to be certain that this case can be ruled out.)
For 2b, if there is no pre-compiled package available for RPi, the only alternative is to compile it yourself, unfortunately. The ./configure script should tell you if that's supported for your machine or not.
@willblackhurst
sudo installs gem for you
Well, not exactly. sudo is "superuser do," which runs a command with elevated privileges so that, for instance, files can be installed in system executable locations that are normally write-protected. sudo itself doesn't install anything.
sudo apt install gem would install Gem. apt is the package manager -- this is the component that actually installs it.
I mean, now I see what you were trying to say, but there were enough pieces left out of your comment that the meaning was unclear.
hjh