There is, on linux is it in ~/.BitwigStudio/log/ but not sure where it is on windows/mac.
I finaly found the log files. In the Bitwig engine.log, i found what seems to match with the closing of the VCV plug-in window and what happens after i press play :
VCV Rack: editorClose()
VCV Rack: editorClose() end
Could not read async reply: End of stream: Broken pipe
Could not process audio on client audio thread 11 using remote audio thread 0: End of stream: Broken pipe
Killing pluginhost process
Waiting for plugin host process to exit
Plugin host process exited with code: -1073741819
When i re-opened the plug-in window the QAR wasnât visible anymore. I made the test in a blank project, without any other plugâin than VCV. Hope this could help. @TroubledMind & @almostEric, thks for your help.
Interesting, thatâs the message that is logged when plugins donât follow this but it might be something different because I canât make Rack crash like I would expect if it were that.
I ran my usual integration test case and Frozen Wasteland 2.0.2 works correctly with Reaper and Rack Pro 2.0.3B. No crash when reloading the patch, therefore I doubt it is related to font reference storage.
So, 2.03b definitely broke something with QAR (and maybe other modules). It doesnât work in standalone or in VST mode
Trying to figure it out tonight
Whatâs the behavior?
basically it just doesnât work - turning any of the knobs doesnât do anything, clearly something is failing during initialization
So, I downloaded the latest VCV 2.0.3 source code and built my module against that - now it works fine, so I have pushed an update that just updates the version #, which should allow people to update my modules to versions using the latest code. I guess the API was not completely stable
I tested QAR 2.0.2 with Rack 2.0.3b Standalone and VST on both GNU/Linux and macOS platforms and it works fine.
What platform do you see those issues on? Do you have a reproducible test case?
Iâm on windows 10. Does it matter? Seems like rebuilding modules against the latest api is a good thing. In my dev environment, I had to rebuild every library (basically fundamentals and befaco) against the new vcv code before they would work
It does if you are implying that any of the changes in the API in the 2.0.3 SDK matter in your case. I am not sure they do. I am trying to figure out what the problem is first. We are not rebuilding all plugins with the latest SDK all the time and should not have to.
Fair enough, but I can only report my experience.
You could do the following for me: build against 2.0.2 SDK and see if the problem re-occurs for you.
The difference between your build and any othersâ builds is that they are cross-compiled by the Rack toolchain, so even if it works for you locally, there still might be a problem elsewhere.
I have seen issues like this with Prism, where it looked like variables were not initialized correctly and the module was not working as expected. I cannot reproduce those issues anymore with the current build of Prism. Latest versions of FW and Prism were both built with the same SDK.
I had tons of problems where my local builds for windows would work fine, but the toolchain builds crashed. I ended up installing the windows toolchain in a VM running ubuntu. Then my builds would crash just like the ones in the library.
I know, but then again, those were with different (much older) versions of compilers than what you were using. We aligned compiler versions in the toolchain and whatâs available ânativelyâ. This is anecdotally relevant, but unless we have evidence that there is an issue, letâs not go there.
oh, no, that is not my intention at all! I had crashes that would only happen with the toolchain. I never did figure out why, so of course I canâtâ blame the toolchain.
My intention was rather to suggest that devs might need/want to install at least the windows toolchain for finding and fixing these issues (or in may case work around).
in my experience the worst problem for my modules arise from the
the sequence of the operation when a module is loaded from file/scrapbook/undo actions
because is changed:
in V1
the ModuleWidget (if created) was instantiated ALWAYS before the âdataFromJsonâ
in V2
this is not guaranteed so I have many UI elements going out of sync with inner status
This should be listed in the runtime issues section of porting your modules from v1 to v2. I just noticed that loading the widget theme doesnât work for my modules in v2 because the widget hasnât been created when dataFromJson is called.
Happy New Year to you. Will the Frequency Domain modules come out in V2, now they arenât there I yearn to us them again.
Yes, I have them migrated to v2, now I am doing the tedious part of all the port labels