Oh yes, “packing” it’s called. That’s not what my error was about. I had two problems, like anyone else would have trying to build it:
If you follow the build instructions it will fail, because git submodule update --init --recursive will fail, because they by mistake have an SSH link to the Via submodule, instead of the HTTPS link it should have been, which means the building only works on the developers’ machine because he has the SSH key.
To get around that, you can then instead manually git clone https://github.com/starlingcode/Via. BUT that won’t build with the default master branch. Instead you need to git checkout the viatools-updates branch of that, I think it was Steve or Russel pointing that out, and THEN the whole thing builds
I’m still on macOS 10.12 (Sierra) but an upgrade to Catalina is becoming more and more pressing because more and more things are leaving it behind.
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.
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.
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.
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.
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.
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.