Sorry, I cannot provide builds outside of the official Rack Plugin Manager. You will have to wait until the plugin is officially submitted, reviewed, and integrated.
What is your association with this code? Are you the original developer?
Thank you verry much. It is good that there are still some people here who understand the concept of community.
He manages all builds into the VCV Library, and checks compliance with library rules.
2 Likes
Windows 10, Bitwig 4.1, VCV Rack VST crashes about 9 times out of 10 loading Gateseq from browser. Its fine in standalone, also in Ableton 11. I wonder if its due to Bitwig stack size of 1MB similar to this? docB padsynth crashes VCV VST - Plugins & Modules - VCV Community (vcvrack.com)
Interesting. VCV Rack doesn’t work at all in Bitwig for me since just before Christmas. Doesn’t seem to be a plugin causing it for me though, crashes when trying to open the GUI.
GateSeq is OK under VCV VST in Cubase as well. Bitwig’s vaunted plugin hosting seems to have issues with VCV VST other DAWs don’t. I don’t know the source of information about Bitwig plugin host 1MB stack size but perhaps it’s something to raise with Bitwig devs.
It isn’t necessarily stack size, just because that happened once. Also, 1M is a huge amount of stack space for an audio plugin to use. There is no doubt a better way to code modules that do this, if in fact there are more of them out there.
True, GateSeq doesn’t seem to set up large data structures. One more observation; it’s fine under another VCV VST host in Bitwig like Blue Cat Patchwork; just not as a direct Bitwig plugin.
1 Like
I was the one that identified Bitwig as having a 1MB stack. That’s true of almost all Windows DAWs, while standalone Rack has a 2MB stack. That makes it possible for a Rack module to work perfectly in standalone Rack but crash in almost any DAW.
It’s unusual to use anywhere near 1MB of stack, so this problem is unlikely to be widespread. It’s also unlikely for a sequencer to have this problem - it’s more likely to happen in audio-processing plugins that need to process buffers of audio samples, FFT tables, and so on.
I don’t think we can blame stack limits for your crash with GateSeq. I modified my standalone Rack to use a 256KB stack and GateSeq worked fine.
@Rodney, can I just check that we’re both talking about Impromptu Gate-Seq-64? Maybe you’re using a different module with a similar name? I can’t make Bitwig crash by adding Gate-Seq-64 to my patch within Bitwig.
Duh, sorry, look in the thread title, Richie you twit. 
I’m now looking at the right module, and it’s crashing in Bitwig for me too. I’ll see what I can figure out, but at first glance it doesn’t look to be a stack problem.
1 Like
The crash in Bitwig is due to an assumption that GateSeq makes about the sequence of events when creating a module instance. The assumption is always true in standalone Rack, but not always true in the VST.
I’ve raised an issue with a more detailed description of the problem here: GateSeq crashes when added to the Rack Pro VST within Bitwig · Issue #29 · starlingcode/Via-for-Rack · GitHub
4 Likes
Richie thanks for investigating and raising the ticket! Good to catch this bug before Starling Via hits official Rack 2 Library.
1 Like
I don’t understand. Is Starling fixing this thing? Or is this a bug in the port that someone else did?
The github states “We welcome Issues and Pull Requests to this repository if you have suggestions for improvement.”. The suggestion for improvement provides an opportunity to fix this if anyone is planning to get Starling Via into the library. Given the nature of the bug (only surfaced by new VST application of the plugin) it may have been there for some time.
There’s a V2 branch on the original developer’s GitHub linked above so I would think they’re working on it.
ok, so Starling is active, there is a bug that could be an old bug, or (more likely) it a bug in the port to V2, and for some reason everyone it pitching in to fix it. Because Starling, while still active, doesn’t want to, or can’t? I don’t really understand, but that’s cool.
I guess Starling may not even be aware of it; I mentioned the bug just yesterday and Richie helpfully looked at it and clarified the likely cause (not stack-related but the plugin often trying to use data before initialization in VST mode). This line virtualModule.slowConversionCallback() which seems to lead to the bug is in V1 and V2 branches within Gateseq::process(). In a sense this is V2 branch bug as something not changed from V1 but which needs to change for VST application in V2. Nobody has commented on the ability or willingness of Starling to fix it.
I just reported here because I want to use it in Bitwig 4 which is included in VCV supported DAWs. Did not intend to confuse.
2 Likes
Oh, confusion is ok. Thx for the info.
The modules and firmware have been updated on the v2 branch.
2 Likes
Thanks the GateSeq instantiation crash on Bitwig seems to be fixed. Tested under Win 10, Bitwig 4.2 Beta 1