Any Mac user who had a Bitwig crash on reloading a patch with my modules in? Mac OS X shows some sort of error-box containing debug-information, that text I need for analysing. Unfortunately on Mac M1 this is nor raised due to Rosetta2, I don’t know why…
It would be really nice, if someone could copy the text and send it via mail or so… thanks!
There should be a Rack crash log, check Console app (Applications/Utilities has it…
in the VCMA the knobs have a very unpredictable behavior,
when I set them to some different values and close rack and reopen it ,
they all are set to the middle position,
but the values are what I did set them before closing rack.
almost on every knob the values and the display don’t fit,
see in the picture (this is from one patch), I assembled it to show how different the values and the display of the knobs is.
some other “special knobs”:
maybe you need to enlargen (just double click) the pic to see the values better.
Oh - somebody is using my light skins 
Cool!
Ok, I can see… will check it, thanks!
Ahhh yes you are right, the bypass function. That works for easy bypass. What I wanted to do was to send the signal around the module, so you get the clean signal.
FOr the mix knob, that would need a new knobs I guess.
Ah, found it thanks
I will check it, thanks 
Well, I thought I can present an update for the weekend with a fixed Bitwig/Patch-Reload fix, but nope. I have no glue why it crashes when the plugin is loading on saved projects - even with debug-information it makes no sense… I will search and try… stay tuned!
Whenever I had problems with Rack Pro crashing in Bitwig before (when it was first released) it was generally related to what Troubled Mind linked to above - “Don’t store Font and Image references across multiple frames”.
The way you said you are cacheing the SVGs to a buffer which then acts as a rasterised image made me wonder if the problem might be related to that.
I haven’t had to support 2.0 plugins, so I’m no expert. I think you can’t hold fonts, but you must be able to hold onto images - that’s the whole way that FrameBufferWidgets work, and the world would be an awful place if those didn’t work any more.
To me, the “contract” is not super clear. But for sure you are fight that most of the 2.0 vst crashes were around holding onto fonts.
Meander uses PNG images for the panel when in the browser. For this, I do a loadImage() call in each ModuleWidget draw() function. As I remember it, loadImage cannot be cached.
I believe the V2 porting document says don’t cache fonts or images.
As I have understood Andrew, which might not be correct at all, the backing implementation in the SDK does the caching, and the developer should just use it, not cache themselves.
That’s how I understood it as well.
Yeah, it’s this section specifically: Migrating v1 Plugins to v2 - VCV Rack Manual
You might encounter these issues while testing.
Font and Image references across multiple frames ¶The DAW plugin version of Rack uses a different OpenGL context each time the plugin editor window is closed and reopened. This means that if you load and store a Font or Image in a widget’s constructor with font = APP->window->loadFont(...) or image = APP->window->loadImage(...), its OpenGL reference will be invalid if the window is reopened later.
Instead, save only its path, and fetch the font/image each frame in draw(). Example:
void draw(const DrawArgs& args) override {
std::shared_ptr<Font> font = APP->window->loadFont(fontPath);
if (font) {
nvgFontFaceId(args.vg, font->handle);
...
}
}
loadFont() and loadImage() caches the font/image by its path, so this operation can be efficiently called in draw() every frame.
That is good to know. The documentation seems vague about this and I have worried that calling loadImage() every frame hurts my module performance although it does not in practice.
Thanks for you input!
You are right and in generell I would agree, but I had to implement my own renderer for complex SVGs, they are cached as rasterised version and currently there are no functions to handle that. You can see it as some kind of framebuffer which shares it’s data among all modules using that SVG.
The font and image handles are one issue where it crashed when I started porting to v2, but that was after reopening the windows in a running session. Now it crashes only when a new VST session is started (from a saved project in Bitwig/Reaper etc.) while loading a saved patch with my modules it it. It crashes not on loading something it crashes very early, that is the strange and hard part, it makes no sense. The normal Rack standalone can be easily debugged via lldb but running as VST I have not much help… so, I will try…
Those are the exact symptoms of the images/fonts problem that lots of modules had when moving to v2. They open fine in a new instance but deleting Rack instance and undo, or saving/reloading project, causes the crash to happen.
Even without Bitwig file save/load the error is reproducible in an unsaved new project:
Yeah, my case was the UI of my “Colors” module. It generates a “noise” texture programmatically and then hold onto it for the life of the plugins. I wasn’t sure if this was ok, or now forbidden. Andrew said it was ok (iirc). Of course that didn’t use loadImage or loadFont, so I guess there is some built in caching for the high level stuff but some lower level stuff you can hold onto it?
Maybe it was Ok before Rack Pro but not as a VST, just speculating…