Findings while porting Modules to v2.

My findings while porting SubmarineFree to v2.

  • the property bool settings::paramTooltip has been replaced by bool settings::tooltips
  • app::PortWidget::Type has been replaced by engine::Port::Type
7 Likes

Stuck at the moment. I was starting to implement LightsOff widgets. But the API changed 5 days ago and the latest SDK is 11 days old.

Managed to unstick myself.

For now I’m porting against a v2 Rack that I built myself, rather than the SDK. Not ideal, especially since the version of Rack and the version of Fundamental that I checked out yesterday are not compatible. But I fixed them.

Ported my illuminated Knobs and the LA-108 (which has knobs and several other widgets that need to light up.)

There is a v2 branch of SubmarineFree, but it only has a handful of modules at present, I’m adding them back in a few at a time as they get ported.

1 Like

string::filenameExtension which is now deprecated returned the extension without the leading period .

system::getExtension returns the leading period .

4 Likes

Module->id is now an int64_t (previously int) which is important if you are in the habit of saving the moduleId in your undo/redo items.

(which you probably should do, because there’s no guarantee that the instance of the module you are undoing the change on is actually the same instance that made the change originally)

3 Likes

Sorry to intrude in this presonal thread of yours, but I figured this would save you (and others) a few minutes of searching. In the latest Rack2 (588342d7), for any CableWidget* (called cw in my example)

cw->setNextCableColor();

should be replaced with:

cw->color = APP->scene->rack->getNextCableColor();

1 Like

Ran into that same one.

I also had to put all Rack.hpp includes to the top before including any other files (at least that is how I solved the issue where I got errors during build saying:

error: #error “Plugins must only include rack.hpp. Including other Rack headers is unsupported.”

1 Like

Sorry about that. Decades of training were looking over my shoulder telling me not to includes un needed headers. This time it would have been better not to do that… I think those headers also pull everything from the rack namespace into the global namespace?

I ran into this one too and have been talking to Andrew about it. There is going to be a new API release that will include a setNextCableColor() for those of us with cable management modules to use.

7 Likes

Another change I had to make is changing the names of at least one of the standard components. res/ComponentLibrary/LEDBezel.svg has been renamed to res/ComponentLibrary/VCVBezel.svg. I didn’t notice as I was only ’ upgrading’ and not completely reinstalling my Rack. So on my local system the ‘old’ file was still available. Luckily someone else who did a fresh install noticed the bug. I see more component names starting with VCV now so it may be there are more names that have changed.

I’ve renamed this thread since it has become more general, and I think probably more useful to the community

7 Likes

I heard about this one on one of Vortico’s streams:

The APP macro can be replaced with rack::contextGet(), which returns the specific context associated with a module instance (for cases like VST where there may be multiple Rack instances) rather than the global context.

2 Likes

Interesting, but “can be replaced” seems like it’s optional, and looking into Fundamental v2, Andrew still uses APP instead of contextGet, so reading between the lines would mean this is an equivalent or optional new way, and would seem it’s not necessary to make the change (?)

2 Likes

Whatever I said, you misheard me. APP is a macro equal to contextGet(). It returns the thread-local Rack context. APP is easier to type.

5 Likes

I’m sorry, my mistake. I misremember you referring to it (or something related to this) as a favorite feature in the Rack 2 API.

Edit: Upon reflection, I think you must have been highlighting that APP now returns a local context rather than a global one.

thread-local. Multiple threads can run multiple Rack instances simultaneously, and one thread can run multiple Rack instances at different times. So APP keeps track of that.

2 Likes