search

free-audio / interop-tracker

A place to track bugs between host and plugins
6 stars 0 forks source link

Bitwig + CLAP: could not load plug-in: plugin host died: could not read responses: end of stream: broken pipe #62

Closed sjoerdvankreel closed 4 months ago

sjoerdvankreel commented 4 months ago

I get the above error message when trying to load my plugin in bitwig 5.1.9, windows 11, x64. Just to be clear, this is probably a "me" problem, not a bitwig problem, but I'm having a hard time trying to figure out whats going on.

I released version 1.7.8 of my plugin a couple weeks ago, and those distributed binaries are working fine in bitwig 5.1.9. Those were compiled on windows 10, and i have since switched to a new laptop running windows 11, and when I re-build the same plugin version (from github tag), bitwig freaks out.

Here's some stuff I tried:

Now obviously the fact that debug works and release does not is a strong hint the problem is on my side. However reaper behaves without problems (as does bitwig+vst3) with release-mode plugin and the fact that the only change is a change of platform used for compilation makes this a bit hard to debug.

Bitwig's engine.log says the following:

[2024-6-25 23:57:5.349 info] About to create a CLAP plugin instance for io.github.sjoerdvankreel.firefly_synth56AFFFF7565F48348C4359D5E6C856A4 (C:\Program Files\Common Files\CLAP\firefly_synth_1.clap\Contents\x86_64-win\firefly_synth_1.clap)
[2024-6-25 23:57:5.361 info] PluginHost: Loading initial plugin state: C:\Users\sjoerdk\AppData\Local\Bitwig Studio\plugin-states\60f5ec75-82a5-4658-8230-160afaede760.clap-preset
[2024-6-25 23:57:5.814 error] CLAP: failed to activate audio output bus index: 0, is_active: true
Error running plug-in host: Invalid UTF8 encoding
[2024-6-25 23:57:5.939 error] Could not read repsonses: End of stream: Broken pipe

Which seems to imply troubles with character encoding but i fail to see how a toolchain update can cause that, or how debug/release mode should make a difference. So I'm just throwing it out here. Any thoughts? Maybe msvcrt version or whatever? Or maybe, is there invalid utf8 data stored in "60f5ec75-82a5-4658-8230-160afaede760.clap-preset" (whatever that may be)?

baconpaul commented 4 months ago

I'm not a bitwig dev, so grain of salt.

One thought: Is your runtime different and somehow conflicting in release mode on win 11? Are you using a static or a dynamic runtime? Or does your release build set the char set differently? I"m assuming you are using MSVC but wonder if you have a DebugStatic vs ReleaseDynamic problem in your clap assembly somewhere?

Does clap-info load your win11-release-binary plugin properly and print all the values you expect also? That may be another good test?

sjoerdvankreel commented 4 months ago

Paul! Always the first to help. Thanks a bunch. I'm about to get burninated on SO once more https://stackoverflow.com/questions/78673717/how-to-debug-a-cmake-built-binary-that-crashes-in-release-mode-but-not-in-debug :)

<< Are you using a static or a dynamic runtime << I"m assuming you are using MSVC but wonder if you have a DebugStatic vs ReleaseDynamic problem in your clap assembly somewhere? MSVC + Dynamic all the way, both debug/release, although, that may be part of the problem. I might try a static link.

<< Or does your release build set the char set differently? Definately not, no.

<< Does clap-info load your win11-release-binary plugin properly Will try! That one I hadn't thought of. I kinda tend to use reaper as "single source of truth", for better or worse.

baconpaul commented 4 months ago

Yeah we are MSVC plusstatic everywhere ourselves - I would try that first just to be sure

sjoerdvankreel commented 4 months ago

The only reason I went with dynamic is because of some (maybe ancient) narrative from microsoft which said something along the lines of "statically linked plugins have a maximum of N per process." I recall there was an "official" microsoft document at one point, but i cannot find it anymore. However there's some (old! 5.2.1) juce material on the subject: https://github.com/WeAreROLI/JUCE-fork/blob/master/BREAKING_CHANGES.md.

"In a recent update to Windows 10, Microsoft has limited the number of fiber local storage (FLS) slots per process. Effectively, this limits how many plug-ins with static runtime linkage can be loaded into a DAW. In the worst case, this limits the total number of plug-ins to a maximum of 64 plug-ins."

I find it sort-of confusing that this talks about FLS rather than TLS, but, I'd better trust the JUCE devs on this. Any idea if that thing is still a problem in the present day?

sjoerdvankreel commented 4 months ago

@baconpaul jup, that did it. Static link MSVCRT, problems are gone. And if it's good enough for Surge, then its good enough for me. Still have to find a way to convince VST3 SDK Cmake stuff to static link, but that's for another day.

This does raise some questions though:

Also @abique : I'll just go with static for Windows, but I'm still not sure if there may be a bug lurking here somewhere ?

baconpaul commented 4 months ago

Mac you don't have to. You can set the macos target os version and you are guaranteed a libc that matches and if you use something newer you get a compiler error.

Linux is a nightmare. Binary distribution is basically not possible reliably for all the distress. Build on ubuntu18 and pray is the best advice people seem to have.

sjoerdvankreel commented 4 months ago

Closing, problem turned out to be on my end as expected (out of bounds read). Only after updating visual studio, only with dynamic link, only in Bitwig, only with release build, not even RelWithDebInfo. Great fun.

baconpaul commented 4 months ago

Closing, problem turned out to be on my end as expected (out of bounds read). Only after updating visual studio, only with dynamic link, only in Bitwig, only with release build, not even RelWithDebInfo. Great fun.

Those are the best. It really makes you realize that we definitely got this "how to program a computer" thing 100% correct as a species. LOL

Glad it got sorted.