I built on windows, no obvious problems. You now, if it’s an LFO you don’t really need to generate a sample at full audio sample rate. I think my LFN runs internally at 400 Hz sample rate, and it has a multi band equalizer in it.
2 Likes
Thanks for this suggestion! I am now down-sampling LFOs by a factor of 8 which makes the modules much more efficient. Maybe I can do even more, I’ll keep testing. Still working on the param update but it’s sensibly better now.
1 Like
Nice! Make sure you don’t get little stair steps on the output. I run it through a one pole low pass at full audio rate to avoid that.
1 Like
As an ignorant, now I’m curious Bruce. Is that economic because the simple filter is much cheaper to calculate than the LFO?
1 Like
I can’t find the thread you mentioned 
1 Like
Thanks. I spent a couple of hours trying to run git push from the terminal but the authentication process on Windows seems very buggy. I was using GitHub desktop for my commits, but for the automated building that is not an option.
I have installed the credential-manager app but I still get this
git: 'credential-manager-core' is not a git command. See 'git --help'.
Extensive stackoverflow research has not solved the issue.
Well, LFN has I think 10 two pole filters in it. So that is the main cpu user. I guess you could call that processing the lfo. In any case, all that uses at least 10 times as much cpu as the output filter. Maybe much more than that. 20x, 50. But yeah, I run everything at reduced sample rate, then “upsample” back up to full rate with a simple filter.
1 Like
I finally got it to work, thanks!
2 Likes
I tried to dl the binary, but I get this:
the vcvplugin file is only 6kb big
and I can only dl a txt file for the NLS folder with the dll and json files.
1 Like
I am now compiling via GitHub (see above) . I am getting errors there, I am not sure why
Can you try again now? It should work for windows…
The GitHub action is just installed by adding a file to the repo in .github/workflows/build-plugin.yml
The contents of that file will determine on what actions your plugin is built, you can set it up to build on certain tags or version changes etc, but, for example I just have it rebuild on a push, so I make all my changes locally and then only push them up to GitHub when I want it rebuilt
name: Build VCV Rack Plugin
on: [push]
Yes, the command line setup for GitHub can be a little tricky because you will need to get all the auth figured out, it is much easier to just use GitHub desktop https://desktop.github.com/ and there is nothing inherent to that which would prevent the GitHub action from running on a push that I know of, what makes you say this is not an option?
1 Like
Ah! I didn’t know I could change the type of action. I will add the push feature for sure. By default the build-plugin.yml only rebuilds when a new version is pushed.
I have figured out the command line setup adding a token in the credential manager so now it works.
I am still dealing with compiling errors in Mac and Linux which I am really not sure how to debug. I am new to this kind of work, it will probably take me a few days (weeks?) to have it all run smoothly.
Thanks
I am just looking at your repo…
Personally, I have removed the modify-plugin-version: job from the action because I manually update the plugin version, and sometimes i want to rebuild the plugin without changing the version number.
I have also removed the publish: job because my repo is private, but also I don’t necessarily want every build to be published, so i manually create releases when I want them as well.
I can’t tell what exactly the issue is with your build:
So in an effort to be useful, here is my exact workflow (this currently works fine on my private repo, however my plugin has no deps)
name: Build VCV Rack Plugin
on: [push]
env:
rack-sdk-version: latest
rack-plugin-toolchain-dir: /home/build/rack-plugin-toolchain
defaults:
run:
shell: bash
jobs:
build:
name: ${{ matrix.platform }}
runs-on: ubuntu-latest
container:
image: ghcr.io/qno/rack-plugin-toolchain-win-linux
options: --user root
strategy:
matrix:
platform: [win-x64, lin-x64]
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- uses: actions/cache@v3
id: plugin-version-cache
with:
path: plugin.json
key: ${{ github.sha }}-${{ github.run_id }}
- name: Build plugin
run: |
export PLUGIN_DIR=$GITHUB_WORKSPACE
pushd ${{ env.rack-plugin-toolchain-dir }}
make plugin-build-${{ matrix.platform }}
- name: Upload artifact
uses: actions/upload-artifact@v3
with:
path: ${{ env.rack-plugin-toolchain-dir }}/plugin-build
name: ${{ matrix.platform }}
build-mac:
name: mac
runs-on: macos-latest
strategy:
fail-fast: false
matrix:
platform: [x64, arm64]
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- uses: actions/cache@v3
id: plugin-version-cache
with:
path: plugin.json
key: ${{ github.sha }}-${{ github.run_id }}
- name: Get Rack-SDK
run: |
pushd $HOME
wget -O Rack-SDK.zip https://vcvrack.com/downloads/Rack-SDK-${{ env.rack-sdk-version }}-mac-${{ matrix.platform }}.zip
unzip Rack-SDK.zip
- name: Build plugin
run: |
CROSS_COMPILE_TARGET_x64=x86_64-apple-darwin
CROSS_COMPILE_TARGET_arm64=arm64-apple-darwin
export RACK_DIR=$HOME/Rack-SDK
export CROSS_COMPILE=$CROSS_COMPILE_TARGET_${{ matrix.platform }}
make dep
make dist
- name: Upload artifact
uses: actions/upload-artifact@v3
with:
path: dist/*.vcvplugin
name: mac-${{ matrix.platform }}
1 Like
Here were the problems
- The repo has a checked in ‘build’ and ‘dist’ directory which stops builds from happening cross platform.
- The .gitingore was not configured properly to stop that
- The code used the pre-c++11 convention of declaring a function without a return type in a few spots
If you remove build and dist, add a .gitignore, and add ‘void’ before the Foo_process_init declarations it all builds fine with the 241 sdk on my mac
If you then commit all that, push it to your fork, and open a pull request, you get Fix build issues on mac, elsewhere by baconpaul · Pull Request #1 · michelezaccagnini/NLS · GitHub
I would imagine the maintainer will see a button on that pull request which says something like ‘enable actions for this contributor’. If you press that the actions will run and I bet they will work.
If not let em know on GitHub and I can fix that too.
3 Likes
I think your triggers may also be a bit short. The Voltage Standards - VCV Rack Manual suggests 1ms open at least for a trigger signal. Bit hard to tell but I’m not sure I’m getting them all. if I run your trigger into your trigger per gate with a tiny gate I get a different result than if I run into a set of modules using dsp::schmidt trigger type trigger detection.
2 Likes
Great. Yes I was wondering why the triggers would not always work. I will check everything tomorrow. Thanks so much for your help!
1 Like
I am having a problem publishing the plugin: all the builds check out but the publishing is not working 