My findings while porting SubmarineFree to v2.
- the property
bool settings::paramTooltip
has been replaced bybool settings::tooltips
-
app::PortWidget::Type
has been replaced byengine::Port::Type
My findings while porting SubmarineFree to v2.
bool settings::paramTooltip
has been replaced by bool settings::tooltips
app::PortWidget::Type
has been replaced by engine::Port::Type
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.
string::filenameExtension which is now deprecated returned the extension without the leading period .
system::getExtension returns the leading period .
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)
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();
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.ā
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.
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
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.
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 (?)
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.
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.