agraef / pd-lua

Lua bindings for Pd, updated for Lua 5.3+
https://agraef.github.io/pd-lua/
GNU General Public License v2.0
51 stars 11 forks source link

search paths for .pd_lua files are not including folders named after object #36

Closed ben-wes closed 8 months ago

ben-wes commented 8 months ago

not sure if this is a valid issue and there are obviously workarounds - but hoping that it might be a simple thing to add.

i'm normally organizing my own abstractions in separate folders in one of Pd's search paths. Pd will search for .pd files also in folders of that name - like this:

/Library/Pd/abstraction/abstraction.pd

... however, this is not the case for .pd_lua files. here's the console log for the failed search after i put my abstraction as osci3d~.pd_lua in /osci3d~:

tried /Library/Pd/osci3d~.darwin-arm64-32.so and failed
tried /Library/Pd/osci3d~.darwin-arm64-0.so and failed
tried /Library/Pd/osci3d~.darwin-fat-32.so and failed
tried /Library/Pd/osci3d~.darwin-fat-0.so and failed
tried /Library/Pd/osci3d~.d_arm64 and failed
tried /Library/Pd/osci3d~.d_fat and failed
tried /Library/Pd/osci3d~.pd_darwin and failed
tried /Library/Pd/osci3d~/osci3d~.darwin-arm64-32.so and failed
tried /Library/Pd/osci3d~/osci3d~.darwin-arm64-0.so and failed
tried /Library/Pd/osci3d~/osci3d~.darwin-fat-32.so and failed
tried /Library/Pd/osci3d~/osci3d~.darwin-fat-0.so and failed
tried /Library/Pd/osci3d~/osci3d~.d_arm64 and failed
tried /Library/Pd/osci3d~/osci3d~.d_fat and failed
tried /Library/Pd/osci3d~/osci3d~.pd_darwin and failed
tried /Library/Pd/osci3d~.pd_lua and failed
tried /Library/Pd/osci3d~.pd and failed
tried /Library/Pd/osci3d~.pat and failed
tried /Library/Pd/osci3d~/osci3d~.pd and failed

... in this case, i was hoping for

tried /Library/Pd/osci3d~/osci3d~.pd_lua and succeeded
agraef commented 8 months ago

I agree that this would make sense. But I'm afraid that this might introduce ambiguities that could break the existing algorithm contributed by @sebshader which takes into account relative pathnames and also keeps track of identically named objects in different subdirectories. It was hard to get this right (cf. #26), so I'm reluctant to touch this code. But I haven't really thought about it, so I don't know how hard it would be. If you have a solution which doesn't break the existing code, please toss me a PR and I'll take a look. Or maybe @sebshader can come up with something, he knows this code better than I do. ;-)

sebshader commented 8 months ago

I think I may have a fix but I'm trying to get around some weird .dll windows error when testing

ben-wes commented 8 months ago

quickly tested this on macOS sonoma here. works well for the case mentioned above. thanks a lot!