Without wanting to take away anything from the fantastic latest developments of Pd, I find it a bit disheartening to find out that - after using Pd since 14 years - some basic usability flaws like these ones are still not addressed. It's not really a lot of effort or a drastic change.
@seb-harmonik-ar thanks, yes, I had set the path to zexy in my preferences. The objects would not created not only in my own patches bu also in their own help files. And with the same prefs path, my old zexy works fine, while the newly downloaded zexy from deken is broken. Not all objects are broken but many of them. I checked a few help file at random and 4/5 help files had broken objects.
Anyway, I did more testing and I'm a little baffled. It turns out that whether I add zexy to the path preferences or not is completely irrelevant. If I do it or not, zexy from deken doesn't work.
The lib works only when I include [declare -lib zexy -path zexy], as Seb suggested. Now, this doesn't really make sense from a user point of view: first, because this is not indicated anywhere, and second, because the declare object is not included in zexy's own help files. This means that when one uses the Pd Browser to open some zexy help files, most patches are broken because zexy itself doesn't get loaded by its own help files. Am I missing something here? This seems to me a weird approach, does anybody knows whether this is wanted by IOhannes (who I think is the maintainer)?
@oid Yes, that's exactly what I find confusing, and I agree with you that deken should follow conventions. That said, from a brief research on AMD64_32, it would seem that it refers to code compiled so as to run as 32-bit on a 64-bit system.
See for instance: https://www.oracle.com/database/technologies/instant-client/linux-amd64-downloads.html
In any case, as per my message above the AMD64_32 version works, but only with [declare].
(and zexy versions from 2015 in deken are named AMD64_64, by the way).
ok, so I found time to compile Pd, 0.51.2, and I think now I understand my problem was twofold.
Pd compiles fine and all libraries in /extra works fine now.
So the fact that those same libraries installed by the public package were broken could point to issues with the package itself, as @oid suggested.
The other issue with the libraries installed via deken. Well, on one hand is my bad: those broken libraries I had installed were not technically broken, but simply compiled for AMD64_32 which is a different architecture than my machine (which is 64-bit). I had installed the 32-bit version without even checking what it was, I assumed the most recent deken package would be compiled for all platforms, but apparently this is not the case.
Which leads to my other question: I find it strange that those very common pd libs are not compiled for 64-bit platforms?
Anyway, issue is not entirely solved, but at least I understand now what has happened.
ok, I see, that's what I wanted to know.
It would be good to know whether anyone else has installed the same package and is not having troubles, or else...
Yes, compiling is a good way to understand whether it is my system, thanks for the suggestion. That said, I have a fresh linux mint install, so it would be strange, but one never knows.
Not sure when I can do it since this is happening on my production/touring machine, that's why I was looking to know more about others' experiences. But I'll post info here if I discover anything relevant.
Thanks for now!
it has been a while, hope you are all doing well despite the times.
I'm on Linux Mint 20 on a DELL M4800. I installed pd with:
sudo apt install -y puredata
The available package is 0.50.2. I'm aware this is not the newest, but I would expect the package to be fully functional since it's available in public repos.
The problem is that Pd works fine but numerous libs are broken, i.e., objects cannot be created.
This affects both libraries that came with the puredata package I installed and libraries that I installed via deken.
I confirmed that, at least for the broken libs installed via deken, it was not a problem with [declare] or paths or startup prefs, because I replaced the broken libs with older versions of the same libs that I had in my archive, while keeping the same paths prefs. The older versions of the libs work.
The libraries installed via deken that are broken are so far:
Other broken objects from /puredata/extra/ :
There may be more that I haven't noticed, these are the ones I use in my projects.
Am I doing anything wrong, or is there something wrong with this package, and if so, any idea what could it be?
I'm speculating it could be some objects are compiled for an incorrect architecture, or perhaps some issue with the libraries loader?
Thanks in advance for the help,