Hello! I’ve built a huge Renoise tool for the Akai Fire, and for performance reasons I’m trying to extend it with a native .dll module written in C++ or Rust. But I can’t get the Renoise scripting system to load a .dll file at all. I’ve tried targeting x86 (32-bit) and x64 (64-bit) architectures, tried “stdcall” and “C” calling conventions, etc. But I can’t seem to get luaopen_pyre_bridge or pyre_bridge or any such module-named function to be called. The pyre_bridge.dll file is found by require(), but I guess the .dll isn’t successfully being loaded. My other test programs are able to LoadLibrary and call test functions just fine (this is all Win10 for now). Is there something special about the Renoise Lua implementation that I need to know in order to get a native extension module to load? I’m not even doing anything with Lua yet, just trying to get a .dll function called from the Renoise tool.
An example of a tool with a native (.c, .cc, .cpp, or .rs source, .dll built) module that successfully loads would be very helpful.
package.cpath: .\?.dll;C:\Program Files\Renoise 3.2.1\?.dll;C:\Program Files\Renoise 3.2.1\loadall.dll;C:\Users\skylark\AppData\Roaming\Renoise\V3.2.1\Scripts\Libraries\?.dll;C:\Program Files\Renoise 3.2.1\Resources\Scripts\Libraries\?.dll
*** error loading module 'pyre_bridge' from file '.\pyre_bridge.dll':
*** The specified module could not be found.
***
*** stack traceback:
*** [C]: ?
*** [C]: in function 'require'
*** main.lua:15: in main chunk
I can’t say what from the info you’ve given (and if ‘pyre_bridge’ is), but doesn’t the external c library have to follow a particular protocol/format and register functions etc (https://www.lua.org/pil/26.html) ?
Yes, that’s what my .dll does. It’s actually a Rust cdylib with extern “C” call convention – and it works great with various other Lua host setups (written in C++). For example, I got interop working smoothly with Lua 5.1.5 statically linked, dynamically linked, 32-bit, and 64-bit. I even got Renoise to call into my function, but I had to do it using package.loadlib() using the full path to the .dll – so if I can just get access to the lua_State* from within the script to pass into that function, then I should be off and running. Ideally, though, require() called from Renoise would behave the same way that I’m seeing require() behave in the other test hosts. It finds the .dll and calls luaopen_modulename(lua_state). It even works with submodules contained in the .dll, as documented. Strangely, Renoise require() does find the .dll file but doesn’t successfully load it and call my luaopen_… function.
I guess the answer might be buried in here but I feel so close with this package.loadlib() technique. The fact that Renoise can call my function is proof that it can load the .dll (it’s not a transitive dependency or architecture or call convention problem). Now I just need to get the lua_State* to pass in so I can tell Lua where my functions are…ideally with require(), but I’ll settle for a hack if it works.
Whoa, I got require() working as expected by moving my tool’s local copy of the .dll out to ...AppData\Roaming\Renoise\V3.2.1\Scripts\Libraries !
This is exciting to see it work, but seems like it would be quite a problem for deployment to users if they have to move files out of the tool folder. I thought keeping everything self-contained was ideal for Renoise tools?
Yeah, I’m good to go, thanks a lot 4tey and Neurogami!
I think the issue is something about the package.cpath having .\?.dll as the first entry. It messes up dll loading somehow, but I have a workaround. If I hack the cpath to look in renoise.tool().bundle_path first, then require() works correctly, my .dll happily loads and runs.
I read with great interest that you, @voidshine, are in the process of building a renoise tool for the akai fire. Since I recently got an akai fire, I’d love to hear if you’ve gotten around to finishing it - and if so, if you would mind sharing the xrnx file.
I hope you were successful with your experimentations
Heyho @hapster yeah I did build a Renoise tool for the Akai Fire. It’s incomplete but mostly usable with some neat features.
The native .dll usage was unreliable (some subtle probably-memory-related native bug/incompatibility) and Lua display management was slow, so the OLED display module is hacked out. It’s a bummer because when it works, it’s extremely helpful… I just don’t have more time to burn trying to get native/Lua interop working – it’s not officially supported IIRC.
No tool page yet, as this is not an officially released project, but here’s the repo. Happy hacking!
