Anyone having luck debugging in BitWig?

I’m trying to debug my plugin in BitWig (currently on Mac). Is anyone having any luck with this i.e., connecting the debugger and stopping on breakpoints?

So far, it crashes if using BitWig as a the executable (SIGSEGV) and if I connect the debugger after launching BitWig then I get an EXC_BAD_ACCESS (with address 0xc so looks like a nullptr deref).

This is all BEFORE even loading the plugin! It could of course be a deliberate measure against cracking…

Any thoughts?


I’ve only tried on windows, but I guess the same strategy applies to Mac version.

Bitwig runs each plugin in a separate process, so you need to attach the debugger to the plugin host process rather than to bitwig master process. You can do this easily after the plugin has been loaded.

1 Like

Thanks, yes I can see that now. It’s the same on Mac.

that’s insane :\ I have found a bug in one of my plugins that requires me to check what Bitwig does when it loads the plugin… but I can’t find a way to do such a simple task, since I have to manually attach the debugger AFTER the plugin is loaded. Any of you had more luck?

I seem to remember (certainly on the Mac) that you can attach the debugger to bitwig’s plugin process then go through adding your plugin to a track.

1 Like

I’ve tried several things and I’ve been able to disable the creation of a separate process for each plugin… but nothing seems to work. If I attach the debugger to the main process, it crashes (protection against debuggers and decompilers)… if I attach on the other process it creates, I don’t get ANY of my DBG messages. I tried to get in touch with the developers, but no answer so far… so, basically, I’m very close to explicitly not provide compatibility for Bitwig.

I found myself in the same situation while debugging Pro Tools: no DBGs printed in the Xcode window after you attach the debugger.

What worked for me was to start the host from the command line in Terminal: the DBGs at that point were being printed in that Terminal window, while still retaining the possibility to attach the debugger


didn’t worked :\ I ran Bitwig from terminal and attached the debugger to the engine process (as suggested from Bitwig devs)… no DBG messages. that’s more frustrating than debugging AAX plugins. The issue I’m having is that the plugin state is not correctly loaded. I read that this happens with other developer’s plugins too, but until I don’t have any way to see what’s going on I’ll be forced to tell my customers we don’t support Bitwig.

When you attach to the process BitwigPluginHost, it does load symbols for loaded plugins. You can confirm this by setting a breakpoint somewhere in your plugin’s startup code.

The problem is that output from the plugin to stdout / stderr seems to get consumed by the BitwigPluginHost process.

I worked around this by logging to file instead of stdout / stderr.

You can do this by inheriting from the Logger class, and overriding Logger::logMessage()

1 Like

I’m trying to do this on an M1 from CLion, but keep getting this error message:

attach failed (Not allowed to attach to process.  Look in the console messages (, near the debugserver entries, when the attach failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)
Debugger detached

I’m attaching to “BitwigPluginHost-ARM64-NEON”

It’s possible the binary’s entitlements don’t allow attaching a debugger - I’ve seen the same thing with Live. The output in should provide more detail.

Assuming that entitlements are the problem: It’s possible to re-sign the Live app to enable debugging, e.g.

sudo codesign -fs "-" /Applications/

Perhaps something similar is possible with Bitwig, however I haven’t tried it myself. Given that the plugin host is a separate app that lives inside the app bundle (I think?), it may be necessary to re-sign both the host app and the Bitwig bundle itself. I suspect a bit of trial-and-error will be required, so definitely back up your original copy of Bitwig before attempting to modify its signature.



I also tried this on macOS Mojave.

From CLion I get:

Error 1
Debugger detached

No other output, when trying to attach to the BitwigPluginHost process.

Thanks for the lead @reuk!

I was able to attach my debugger (CLion) after re-signing the plugin host app (embedded in the Bitwig app):

sudo codesign -fs "-" /Applications/Bitwig\\ Plug-in\ Host\
1 Like

i was just looking at this forum post to find out how to debug with bitwig and the information provided was not 100% convincing at that point, but i eventually figured it out, so here’s my workflow for everyone to read (Windows Only!):

  1. run your project in visual studio

  2. run your demo project in bitwig (no debugger)

  3. set up sandboxing for your plugin in bitwig:

    that makes every instance be its own process.

  4. instantiate an instance of your plugin on some track in bitwig.

  5. hit ctrl+alt+p in visual studio to open the attach-debug-window.

    you need to scroll to the right and drag out the command line section a lot in order to see which process is actually your plugin instance. that’s the worst part about this workflow. if anyone has an idea how to make this more automatic please reply to this post.

  6. select that process.

  7. enjoy debugging your plugin in bitwig.

  8. you want to make a change to the code, so you select the track your plugin is on in bitwig and hit alt+a to unload all plugins from that track. this also automatically stops the debugger in visual studio.

  9. you make the code changes and rebuild the solution (in vst3 mode with copystep enabled ofc).

  10. you hit alt+a on the track in bitwig again to reload the plugin(s) again. they will have the new build then but still the same state as before (like sidechain inputs, parameter values etc)