"Stage 1 runs on Linux only." ./main/low/cargo.toml

[GavinRay97]

In trying to run the bindgen process to create the binding for one of the newer functions released, I noticed that it seems like the config is set up so that stage one only runs on Linux.

Is this necessary for some reason, or can it be run on Windows/OSx? I don't have a problem using WSL but just curious why this is:

[helgoboss]

Please see the README.

[helgoboss]

Short answer: Generating the bindings on Linux generates the correct bindings, on Windows not necessarily (because the input headers are different). Exactly, on Windows I use WSL to generate the mappings.

[GavinRay97]

Ahh got it, my bad @helgoboss. I think I have gravely misunderstood how bindings and C/C++ barriers work.

I tried to pull in these files, and the most recent SDK definitions, but nothing seemed to be generated in regards to the VST3 interface making plugins available to be embedded in the TCP/MCP UI:

https://github.com/justinfrankel/reaper-sdk/blob/main/sdk/reaper_vst3_interfaces.h https://github.com/justinfrankel/reaper-sdk/blob/main/sdk/reaper_plugin_fx_embed.h

This was just released in pre-release today, and I wanted to try to make a dummy VST3 in Rust + reaper-rs to see if I could get it displayed in TCP. (But I'm not really sure what I'm doing, thought maybe a magic Rust interface might get generated for the C++ interface)

https://forum.cockos.com/showthread.php?t=249561 + VST3: support third-party embeddable UIs via new IReaperUIEmbedInterface interface

So I've pulled that in, the interfaces.h file made the bindgen explode (I think because it's C++ and not C? Why do they have the same file extension?), but with just the plugin_fx_embed.h it seemed to work fine:

namespace reaper_functions {
  #include "../lib/reaper/reaper_plugin_functions.h"
  #include "../lib/reaper/reaper_plugin_fx_embed.h"
  #include "../lib/reaper/more_reaper_plugin_functions.h"
  #include "../lib/reaper/coolscroll_reaper_plugin_functions.h"
}

---

But the only changes were this, and two other mostly-insignificant functions. If you want I could PR it but it might be faster if you did it yourself, not sure (your call).

[helgoboss]

VST 3 would justify a whole new crate, that's not in the scope of reaper-rs. However, as mentioned in reaper_plugin_fx_embed.h, you can use the UI embedding also from VST 2 plug-ins, so using vst-rs is fine. Just using bindgen on reaper_plugin_fx_embed.h will not give usable results because it contains C++ virtual classes. Rust can't as easily interface with those as with C. I think that's not the best stuff to start with to be honest, it's really messy.

[GavinRay97]

Ahhh, so that's why it didn't do anything. Thank you clarifying 😃

VST 3 would justify a whole new crate, that's not in the scope of reaper-rs. However, as mentioned in reaper_plugin_fx_embed.h, you can use the UI embedding also from VST 2 plug-ins, so using vst-rs is fine.

Makes sense, so from:

/*
 * to support via VST2: canDo("hasCockosEmbeddedUI") should return 0xbeef0000
 * dispatcher will be called with opcode=effVendorSpecific, index=effEditDraw, value=parm2, ptr=(void*)(INT_PTR)parm3, opt=message (REAPER_FXEMBED_WM_*)
 *

Then it would be using this: https://docs.rs/vst/0.2.1/vst/plugin/enum.CanDo.html#variant.Other

But it looks like the implementation just returns the name of Other as a string in the response, and somehow need to return 0xbeef0000. I'll try to ask around on the Rust Audio Discord server I suppose, ty!