Why cant I call getPlugin?

Development
1

Getting back into plugin programing, and I feel like I must be missing something obvious, but maybe someone else can help me see what it is…

Code:

void SeqBaseWidget::appendExpanderContextMenu(Menu* menu){
	Plugin* p = plugin::getPlugin("JPLab");
	//...
}

Error:

src/JPSeqBase.cpp: In member function 'virtual void JP::SeqBaseWidget::appendExpanderContextMenu(rack::ui::Menu*)':
src/JPSeqBase.cpp:4403:29: error: 'getPlugin' is not a member of 'rack::plugin'; did you mean 'Plugin'?
 4403 |         Plugin* p = plugin::getPlugin("JPLab");
      |                             ^~~~~~~~~
      |                             Plugin
2

Is plugin.hpp somehow not getting included? Does it work if you put #include <plugin.hpp> directly in your code?

3

#include <plugin.hpp> didn’t fix it, but how do I tell it I mean the plugin.hpp in the rack SDK and not the plugin.hpp in my code?

4

good question.

5

You could add #pragma message “in in my plugin.hpp”, assuming pragma message works in gcc - I think it does.

I guess if you did the include on a full path you can control it? like "#include “…/…/some-path/the-file-I-want.hpp”? I’ve never run into this in rack - I guess it’s unusual for a plugin to call some rack functions at global scope… don’t know.

6

So I renamed my plugin.hpp to plugin2.hpp and explicitly included <plugin.hpp> and that fixed it. So it does seem like it needs to be included.

Using the full path also works, but how do I make that work on different computers / when VCV builds it?

7

I don’t know. @cschol would know. Or you can try it with the toolchain build. I’m guess there is some macro that expands to the sdk path? Or if not you could always pass RACK_DIR into your cpp file? Kind of like the way it’s already used in the make file"

FLAGS += -fPIC
FLAGS += -I$(RACK_DIR)/include -I$(RACK_DIR)/dep/include
1 Like
8

You only include rack.hpp in your plugin, not plugin.hpp.

plugin.hpp is also not exposed in rack.hpp and therefore not part of the public API. See the note at the top of rack.hpp and proceed knowing that this is unsupported/unstable.

1 Like
9

Yeah that makes sense. Thanks. This won’t be the first time I’ve skirted the API.

It does seem weird to me that VCV Rack API: VCV Rack API includes functions that aren’t part of the API. But in general I don’t actually find that website that helpful.

10

The Rack API reference is generated, and no measures have been taken to exclude “non-API” methods. It can be helpful to see everything to better understand how things work, but what’s public API and what isn’t is only implicit by “whatever you can access by including only <rack.hpp>”. So yeah, the API reference is only marginally useful.

Practically speaking, it doesn’t take long before you need something basic out of a Rack dependency that Rack itself hasn’t exposed. For example, getting the last write time of a file on disk for detecting file modifications requires reaching down into ghc. I’m not sure if openFileDialog is officially exposed either.