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…
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.
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’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()
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 (Console.app), 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
It’s possible the binary’s entitlements don’t allow attaching a debugger - I’ve seen the same thing with Live. The output in console.app 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/Live.app
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 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!):
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.
select that process.
enjoy debugging your plugin in bitwig.
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.
you make the code changes and rebuild the solution (in vst3 mode with copystep enabled ofc).
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)
If you do need to debug a plugin on load, start the BitwigPluginHost process by opening any plugin on a track. Then attach VS to BitwigPluginHost.exe. Now you can launch your plugin, and start debugging on load. Still quite a hoop to jump through but it means you don’t have to set up Bitwig to run every plugin in a unique process.
So now I’m at the stage where I need to debug a plugin that is loaded with a session, so I can check its saved state. The only solution I’ve come up with is to write the state to disk, but is there really no other way?
I’m doing precisely the same thing, only I’m on MacOS and test with the following DAW’s: Cubase 12, Waveform 12, Reaper and Garageband.
I recently had to address a setState bug in my plugin, requiring me to debug its instantiation life-cycle … I merely did this by telling my IDE (CLion) to Execute Waveform 12 (pointing CLion directly to the binary in the Waveform.app bundle…) when I hit debug. I then set breakpoints in my plugin project, go back to Waveform 12, and instantiate the plugin - hitting the breakpoints immediately.
The only DAW I have issues with is Cubase, which hates being debugged - but this is why its important to have access to dev builds from the DAW vendors… a majority of the time, I test and develop plugins using REAPER, and when there are things to test more rigorously I fire up the other DAW’s. Lately Cubase and Waveform have been on par for exposing obscure bugs …