That is very odd, it builds without error for me against the latest Rack V2 code ( 219bbaf)
That’s what I’m using too (on Mac). Do the lines referenced in the errors relate to changes made in the last 24 hours or so?
I am getting those same errors. weird…
That is indeed weird. Should be an easy fix. Will have to wait until I finish work though.
Fix committed. I just did a clean and build and everything is building cleanly for me.Please let me know if you experience any other build errors.
I’m changing all the modules that use the dark room feature, but this one where I have buttons and ports over the draw areas now doesn’t show up. The left screenshot is what it’s supposed to look like, the right screenshot is with the latest SDK.
You might have to make your ports override drawLayer, and then draw in the same circumstances as your background widget. In which case the ports should probably draw in the drawMethod for all occasions when they won’t be drawing in drawLayer.
Using Rack 2 SE.2efb7ff5 and built with latest SDK on Windows, the ports appear in the module browser but not in the rack, like your right hand screenshot above. Although saying that, I can interact with them as the tooltips appear to show where to connect a cable.
I have a similar issue for one of my modules. I keep an eye on it to see if you fixed it. But for now I leave my module as is.
I made a quick test compiling/running my AlgoritmArte plugin in VCV Rack 2 Studio and after a couple of small fixes, everything seems ok; there is still one issue in the visualization of CyclicCA, I’ll fix it later. SDK version: Rack-SDK-2.git.219bbaf1-win.zip. This is the branch where I published the V2 code:
Lunetta Modula has now been ported to v2.
Builds clean and quick test shows no issues yet, seem to work fine. Another one done, looking better by the day!
SLM builds with the standard manifest update.
What does that mean?
Changing version
to 2.x.x
Where manifest is plugin.json. Is this a notification about a repo of yours, or an observation about someone else’s?
Observation most likely - there are many such observations in this thread.
Useful info for non-devs who want to build plug-ins to play with in the v2 beta that have not been ported by their developer yet.
In my experience, developers of such plug-ins that have often not been updated in some time and where the developer is perhaps not an active member of the community, or up-to-date with v2 news, are usually quite happy to hear that a) people care enough about their plugin to try porting it and b) that it is very easy to do.
As Steve above said, just an observation based on VCV Manual - Migrating v1 Plugins to v2 Something Andrew said; most v1 to v2 migration is simply going to be changing the major version
number from 1.x.x to 2.x.x.
Although for completeness sake you could do things like changing, e.g.
setPanel(APP->window->loadSvg(asset::plugin(pluginInstance, "res/PANEL_NAME.svg")));
to:
setPanel(createPanel(asset::plugin(pluginInstance, "res/PANEL_NAME.svg")));
Another example would be the adding of labels; not essential at all if the panel makes it obvious, and aren’t necessary to get the plugin to build.
This kind of (best practice) talk probably belongs in another thread.
All my plugins are building with the latest beta.
We are open sourcing our MIDI utility modules which use the patchable MIDI format that we came up with: GitHub - kilpatrickaudio/Kilpatrick-Toolbox: Useful modules for VCV Rack
You can read more about the format here, and it would be great if more people would make stuff that uses it: Kilpatrick-Toolbox/vMIDI.md at master · kilpatrickaudio/Kilpatrick-Toolbox · GitHub
Happy hacking towards v2!!
SubmarineFree is on it’s way. There’s a fair amount of tricksy stuff in there, so it’s taking a little while. But I got the wire manager working today.