Frozen Wasteland 1.20.3

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.

1 Like

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 :smiley:

5 Likes

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).

1 Like

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

3 Likes

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.

1 Like

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.

1 Like

Yes, I have them migrated to v2, now I am doing the tedious part of all the port labels :slight_smile:

3 Likes