Repair team

[AndrewBelt]

The Repair team is the first VCV Community team to launch. The goal is simple: For each open-source plugin in the Plugin Manager, help the developer by sending a pull request that makes it build against the latest master branch of Rack. If you are not quite familiar with GitHub and git, the procedure is the following.

• Make sure to git checkout master and git pull the latest Rack source code, and build it.
• Pick your favorite plugin and click Fork on its GitHub page.
• git clone the forked repo in your plugins/ folder.
• Inspect the code, and apply the changes mentioned in the Plugin API Updates Thread
• Update the form of the Makefile to follow the Template Makefile, including the RACK_DIR which will be useful later.
• Try building it with make -j$(nproc). If you changed everything correctly and it finally builds, make a commit with a message like "Updated to Rack 0.6 API", and git push.
• On your GitHub fork, click "Create Pull Request", and submit it back to the plugin developer.
• After the plugin developer accepts your pull request, you may delete your personal repository.

[AScustomWorks]

v 0.6.0 ready on master branch: AS

[DomiKamu]

Ohmer Modules v0.6.0.2-beta - against lastest Rack 0.6, is available on 060dev branch, for validation.

[sebastien-bouffier]

bidoo's pack is ready for v 0.6.0 on master

[Strum]

Great work everyone.

I think that we've worked together so well on this is both a vindication of Andrew's trust in the user community and confirmation of what a cool bunch of people are involved in the project.

Thanks everyone involved.

[cschol]

As of today (March 3rd), all open-source community plugins are in one the following categories:

• Upgrade to v0.6 completed and tested on supported platforms (Lin, Mac, Win)
• Upgrade in progress by plugin developer
• PR for upgrade to v0.6 was provided to developer, not merged yet

The Plugin Repair team will continue to monitor status of upgraded plugins and test on all supported platforms. The status post a the top will be updated as new information is available.

The work is not done, but we have made great progress in the last 17 (!) days towards our goal of having all community plugins available in time for the Rack v0.6 release.

Thank you to all PR contributors (@phdsg, @alikins, @dizzisound). Thank you to @phdsg for testing of upgraded plugins on Linux and Mac platforms.

This effort is exemplary for the great Rack community that @AndrewBelt has created.

[The-XOR]

makefiles updated as requested

[davephillips]

Aepelzens Modules build and run on Fedora 23 Linux with latest Rack master git pull.

[cschol]

@davephillips Thank you! Just be aware of this issue. Rack v0.6 will not ship with libsamplerate anymore and you either need to update the code or ship libsamplerate yourself.

[davephillips]

Aepelzens Parasites also built and run on latest Rack master, on Fedora 23 Linux.

[dllmusic]

moDllz updated to 0.6 on https://github.com/dllmusic/VCV_moDllz/tree/master-0.6.0dev Mac built ... need help with win and Linux. Thanks

[cschol]

@dllmusic Windows and Linux built fine. Thank you!

[liquidcitymotors]

VCVia needs a lot of work; I might as well do the transition to 0.6 myself while I am at it. Finally getting around to it. Thanks!

[cschol]

@liquidcitymotors Great! If you are done, if you could submit a PR to the community repo to get your plugin added that would be awesome.

[AndrewBelt]

@liquidcitymotors Before releasing your module, I strongly prefer that you not include the name "VCV" in the name of your plugin, as it can confuse users into thinking that it is an official plugin made by VCV, and it can dilute the brand.

[liquidcitymotors]

Didn't consider that, my apologies! I will sort that out ASAP.

[AndrewBelt]

Thanks @liquidcitymotors!

[ghost]

Sign me up for the Repair Team. I can adopt and upgrade to 0.6. Build and testing on Linux and Windows. https://github.com/hwpfeil/vcvrack

[ghost]

I'll do Dekstop, if no one else is working on it. I found a way to painlessly replace libsamplerate for vrackplugins_dekstop Recorder.cpp.

[cschol]

Thank you @hwpfeil. Please provide a PR to the dekstop plugin developer.

[ghost]

Clean compile on https://github.com/hwpfeil/vcvrack/vcvrackplugins_dekstop in Windows 10 mingw64. Everything works as advertised. I need to fix the Recorder graphics (record button and input jacks out of place) and build/test on Linux.

The only other community src using libsamplerate is AepelzensModules. I built and tested that using SoX Resampler Library in both mingw64 and Linux. Open issues: Makefile needs to restrict the soxr lib and header to Folder.cpp; mingw64 can't find the runtime dll in Rack/plugin. It works if I put it in Rack/dep/bin or mingw64/bin. I prefer the former, I'd rather locate everything cleanly within Rack/plugins, or Rack/dep if necessary. The install package would have to put a soxr dll in Rack/dep/bin somehow. Folder.cpp uses src_new(), which pulls in multiple files. Might be able to identify the needed functions and header definitions, put them in a companion cpp and compile it into Folder.cpp.o for a clean link?

[cschol]

@hwpfeil Are you planning on providing Pull Requests to the developers?

One question: why are you replacing libsamplerate with SoX? Rack used to use libsamplerate itself and was shipping with it, that's why plugin developers were using it. v0.6 does not ship with libsamplerate anymore since it uses libspeexdsp. Therefore, the plugin dependency of libsamplerate must be provided by the plugin. If you need to ship a library anyway with the plugin, you might as well ship libsamplerate. Thoughts?

[ghost]

https://github.com/hwpfeil/vcvrack/vcvrackplugins_dekstop built and tested on Linux. Ready for build/test on Mac. Release to Build Team?

[ghost]

@cschol I'm a git noob. Don't know how to provide Pull Requests. I thought if I release the code, folks could copy it? Only two 0.51 plugins use libsamplerate. Dekstop Recorder.cpp used only one simple function, so I was able to embed the necessary code. The other libsamplerate instance is AepelzensModules Folder.cpp. I used that as a learning experience in plugin design and upgrade, before I created a github account and found out you had already adopted it. I found the thread asking for a libsamplerate replacement. Sox Resampler was easy, its header wraps all of the SRC functions, like src_new(), src_delete(). I wasn't involved in the replacement discussions a couple of months ago, I know Audacity migrated to SoX, so I looked at it, found an easy fix, and, suffering from bouts of congenital indolence as I oftentimes do, decided to try it. After the 0.6 rollout we'll have more time to incorporate a skeleton version of soxr into Folder.cpp. Now you know the rest of the story. I'd be happy to go back to work on Folder.cpp. From what I can gather, wavefolding is simply inverting the portions of the waveform when its amplitude exceeds a clipping ceiling. Obviously I need to get smarter on that before I can attempt to alter someone's step() code. For now, I'm here just to apply the sed commands our boss, Mr. VCVRack, provides in "Plugin API Updates Thread #258", and upgrade the declarations and constructors accordingly. [DIsclaimer: I use the term Mr. VCVRack in awe of this amazing project. Last year I didn't understand the maze of cables on a hardware synthesizer, now I can make simple patches. -Synth and Git Noob]

[ghost]

I'll adopt https://github.com/antoniograzioli/Autodafe for 0.6 upgrade, if no one else is working on it.

[AndrewBelt]

@hwpfeil That still doesn't answer the question of why you're using SoX instead of libsamplerate.

[phdsg]

@hwpfeil

I'll adopt https://github.com/antoniograzioli/Autodafe for 0.6 upgrade, if no one else is working on it.

see: https://github.com/VCVRack/community/issues/269#issuecomment-367154320

[ghost]

... why you're using SoX Folder.cpp is GPL licensed under the Free Software Foundation; SoX Resampler is LGPL under the Free Software Foundation. Since it worked in AepelzensModules, I used it for Dekstop, too. (Can you mix GPL and 2-clause BSD?) There's http://wiki.audacityteam.org/wiki/Libsoxr. It was just for personal use, I never intended to change anything above the plugins directory.

[AndrewBelt]

Could someone check out the v2 branch of this community repo, and add all plugins to the repos/ directory as git submodules? Make sure the names of the folder exactly match their slug, and make sure the branches are the "0.6" versions. For example

git checkout v2
cd repos
git submodule add -b master https://github.com/VCVRack/Fundamental.git Fundamental

You can rename submodules with git mv <src> <dest>. Send a PR and I'll accept it. We'll begin the approval process for repos once most of the submodules repos compile.

EDIT: Partial work is welcome as well.

[ghost]

Take Autodafe off the to-do list. Mr. Grazioli is updating his own plugins to 0.6.

[cschol]

@hwpfeil Thank you for your offer to help. Please read the second post above. All plugins are being worked on already, either by the developers or PRs have been provided (and in a lot of instances merged). The post explains what the checkmark in the list means and when a plugin gets crossed off the list. There is some cleanup to do with individual plugins, but I am going to let the developer drive those changes (for example upgrading libsamplerate). They will let us know here if they need help. Issues have been created in the developer's repositories for those instances.

[cschol]

@AndrewBelt I have scripted the conversion from the old community repository to the new and will provide a PR soon.

Some of the plugins are still on dev branches for the 0.6 release. I put those plugins on the dev branches and will update to master once the code becomes available there.

The first PR will include all of the crossed out plugins in the list above, i.e. plugins that we have confirmed to be building on all supported platforms.

Any changes to the list in the next week will be handled with subsequent PRs that my script can generate.

[dizzisound]

@cschol Ops, sorry I didn't note this was in charge... So do not consider my PR, please. I did a simple and rough freewill exercise, far way better a script-sourced and official work. I should manage to drawback my PR. Thank you!

EDIT: @cschol Feel free to close the present PR #320 because I have no permissions to do that :-)

[cschol]

@dizzisound No worries! You contribution is as official as mine. Thank you! I do have to say I would prefer to only add modules right now that are known to be working on all platforms and add new working ones one by one. This would make some kind of automated CI easier for the 0.6 versions. @AndrewBelt, what to you think?

[AndrewBelt]

Let's avoid CI entirely. CI should only automate a task which we are 100% certain we've explored all exceptions and issues by performing a task manually until it gets annoying, and I don't expect this to ever happen. Automation should only be done through Makefiles and Python scripts in the v2 branch's scripts directory (not yet existing) but should always be performed by a human. Sitting down at your computer once per day to run something like make library-check (or whatever your team is) is essentially no effort. Maintaining a remote robot to do unreviewed tasks is a recipe for disaster, and it alienates anyone that wants to contribute by making the structure and build system needlessly complex to all but the author/maintainer of the CI system.

I instead encourage your script-writing tendencies to be put toward scripts that humans will run instead. If you can't run a script manually once a day, 10 other people will happily be able to for you, and they'll be able to solve problems and add improvements as they arise.

[cschol]

We are doing CI every day to check the plugins and we need it right now, because things keep breaking. I am not talking about Travis CI, but just scripting enough to not have to execute every build manually. I actually just found "make dist_all", which is enough and it helped flush out a bunch of issues when I tried to build all the submodules I added. Mostly missing RACK_DIR, but some new compile errors, too.

EDIT: Maybe I shouldn't have said CI at all. Just talking about running a script that checks plugins daily. Not automatically executed.

[AndrewBelt]

Ah, we're on the same page then. As long as it's not "some server in an unknown location" doing things on each PR. Orchestrating events is a huge mess with TravisCI, CircleCI, Jenkins, etc that is a non-problem when you initiate it each time with git pull, make whatever

[cschol]

@AndrewBelt Valley Free has a whitespace character in their slug. I assume that is not acceptable? Is there a reference anywhere that I can point to?

[AndrewBelt]

https://github.com/VCVRack/community/pull/281 Make an exception for that one and use ValleyFree as the directory name

[cschol]

Some more issues opened up today (compile errors, missing RACK_DIR in Makefile). If you want to help, feel free to grab one that is not checked in the above list and create a PR. Thank you!

[alikins]

@cschol

Alikins (3/13/18 compile fail, reported to developer)

https://github.com/alikins/Alikins-rack-plugins/issues/1 fixed in https://github.com/alikins/Alikins-rack-plugins/commit/9a19cc447f09435c1de087b5339b4a0b79003e00

[AndrewBelt]

This submodule repos thing is really cool. Everything built straight out of the box for me, and I tested it with a build against Rack-SDK which will be the new method for developing plugins without compiling Rack.

The Build Team will therefore by me for at least two weeks after the Rack 0.6 release, and I'll host files on the vcvrack.com website or something. I'll make builds at least as often as once a day and figure out the obstacles for doing it as a community effort.

The next step is the Library Team. I'll put together a workflow to begin making new JSON manifests for each plugin.

[ghost]

If I may, I'm going to rename TechTechTechnologies plugins folder from "vcv" to "TechTechTechnologies" - there are already a few "vcv_" folders, could be confusing when scanning the Plugin Browser menu.

[AndrewBelt]

@hwpfeil Sounds good. If you're the creator (or primary source) of a particular plugin, could you pull it into its own repo so that the Makefile is at the root?

[ghost]

Yes, SIr. gitNoob need input

[cschol]

@hwpfeil Are you the developer of TechTechTechnologies? The slug of the plugin is TechTechTechnologies, which means that in the new plugin structure using git submodules the source directory will be called TechTechTechnologies. I am not sure we need to rename this one.

[ghost]

Just the upgrade monkey, not developer. There's about a dozen plugins beginning with vcv. I thought the 'vcv' would get lost for those quickly scanning the modules for a patch. Easy enough to leave it in situ, I'll be lost in a add-a-little/save/compile/run/repeat loop trying to get knobs centered in the graphics. I noticed dBiz/Verbo are off. I use max-scale for fine location work. I don't suppose anyone has a grid used to get close-enough coordinates for knobs and things?

[dizzisound]

Additional plugins update: PR pending for @teletypist Stochasm here: Updated to Rack 0.6 API

[ghost]

Having a spot of bother finding RoundSmallBlackSnapKnob. There is a svg image in Rack/res, but no definition or implementation. The Plugin API thread suggests its use.

[davephillips]

@hwpfeil Just change it to RoundBlackSnapKnob.

[ghost]

The knobs are centred inside a grey circle with ticks along the circumference. RoundBlack obscures the tick marks. The author used RoundSmall. I tried deriving with snap=true, but that knob, although it renders correctly, doesn't turn. I figured out how to add a .25 grid to Inkscape so I can correctly locate the knobs to the new height. I've dozens of knobs out of place.