vcvrack / library Goto Github PK

On Windows:

• CastleRocktronics (folder: CastleRocktronics-0.5.0)
• s-ol (folder: solmods)
• SonusModular (folder: sonusmodular)
• StellareModular (folder: Stellare-Modular)
• Valley Free (folder: ValleyRackFree)
• JE (folder: VCVRack-plugin-JE-0.5.0-Win)
• IO-Simple (folder: VCVRack-Simple)
• Vult (folder: VultModules)

I am not a module developer, but I am a software developer with nearly a decade's experience with git, so I feel qualified to comment.

I really appreciate the amazingly dynamic and rapid development on VCV rack. But as you all know, it can be a little chaotic.

One of the issue I run into is this: How do I get the latest, best version of each module's source?

This isn't a straightforward question. Many of the module developers are new to Git, and there are obvious ways they've made mistakes, including (but not limited to):

• master (i.e. main central development branch) won't compile.
• object files (.o .obj etc) checked into git.
• files with conflict markers checked in (i.e. a failed merge leaving <<<<<<<, ========, >>>>>>>> lines in source.

It would be immensely helpful if there was a standardized method to get the last good version to compile.

What would that entail?

• do new development on a branch, and keep releases on the master branch
• tag releases with consistent tag names.

Right now my build script looks at the tags in each repo and checks out the last tag. This seems to be a good compromise for the purposes of getting a known-good compile. The community repo script (community-builds-from-source.sh) just assumes the master branch is the best.

Neither of these approaches is ideal. Some repositories (as I mentioned) are broken at the head revision of the master branch, and some use tags inconsistently.

I don't know what the proper solution is, and I'm assuming Andrew Belt has an opinion about it that would carry more weight than mine. My suggestion would be:

1. Do all development on a branch, and merge to master when it's verified working.
2. tag releases consistently: I don't care what system is used, but my preference would be .. where . match the main Rack API version, e.g. 5.1

Let this be the beginning of a discussion. Rack is becoming too large a thing to just leave things to a 'wild west,' anything goes environment. What will end up happening is the main developers (i.e. Andrew et al) spending too much time trying to corral module developers, and end users not knowing what they're getting.

@AndrewBelt

Inspired by this thread in the Rack tracker:

1. Right now, I am moving any plugin that is confirmed to be working on all platforms and adhering to the new Makefile template (RACK_DIR!) to v2. Even after launch, I expect some plugins to not be updated. We would continue to monitor their state and move them over as soon as they are updated. Does this match your expectation?
2. A lot of plugins define their version as 0.6.0dev right now. Do the developers need to update the version before release to remove the dev suffix? If yes, we would start pinging developers that are already included in v2.
3. Are you planning on providing a developer guide for updating the community repo with git submodules and providing PRs for their plugins? I expect there to be confusion with developers who are not familiar with git submodules. I can draft a guide.

please update

If possible, I would like to have these tags added to tags.hpp...
ARPEGGIATOR_TAG
PORTAMENTO _TAG (I know there's a SLEW_LIMITER one but portamento is more common..)
Thanks.

You might not like this one, Andrew. :[

We should split version and rack_version into different fields. It is very confusing and non-standard to have two different meanings jammed into a single string. It certainly isn't the intention of semantic versioning to do this, so calling it semantic might be another source of this confusion.

I realize that changing it again is going to make it even more confusing in the short term, but I think it's the right thing to do in the long wrong.

MSM v0.6.0 plugin is ready here:
https://github.com/Phal-anx/MSM/releases/tag/0.6.0

"name": "MSM",
"author": "Phal-anx",
"license": "CC BY-NC-ND 4.0",
"contactEmail": "[email protected]",
"pluginUrl": "https://github.com/Phal-anx/MSM",
"manualUrl": "https://drive.google.com/file/d/1Cjof90oYVltSJuXu0hqpw9hIN3r3U94T/view",
"latestVersion": "0.6.0"

With the increasing number of manufacturers in the plugin list at vcvrack.com/plugins, and the fact that we can loose track of who does what kind of module, would it be possible/reasonable to add tags to the VCVRack plugin manager? If we are searching for sequencers in the plugin manager, for example, TheXOR would show up, along with all manufacturer that have sequencers in their packages. It would be a great help when searching for a certain type of module to install, however, it comes at the expense of having to add tags to the plugin manifest files and the developers maintaining such tags. Any thoughts?

Placeholder. Subscribe if you are interested in joining the Build team.

Workflow

TODO

Only the Build Team may change properties status and latestVersion in manifest files.

Version should be updated to 0.6.0

Is there any specific reason Fundamental is missing the downloads section in the .json file?
It seems to be the only "core" VCV Rack plugin that does not provide a link to the binaries.

@AndrewBelt

We have a few examples of plugins that require 3rd party libraries to build, e.g. Stellare Moduar VCV-Link (requires asio.hpp from, e.g. libasio-dev) or IO-Simple still requires libsamplerate.

What should the guidance for plugin developers be when it comes to these dependencies? I am thinking specifically of the case where the plugin gets added to the community repository and someone else (you, the community) builds it.

A lot of open-source projects just say "install library x or y with your package manager, then make".

What is acceptable for the plugin to require from the build environment?

Example of an acceptable build workflow applicable for all plugins:

• git clone plugin-repo
• git submodule update --init --recursive
• make dep
• make dist

Does this roughly match what you had in mind?

Is it acceptable for make dep to install a 3rd party binary library during the build process via package manager or do the plugins have to provide source versions (e.g. as submodule) built in the make dep step like Rack itself does?
Are some of these considerations actually requirements for acceptance into the community repository? If yes, what would be the best way to communicate these to the plugin developers?

This question has come up for me while testing plugins for migration into community. Some have their special requirements, be it custom Makefiles (ParableInstruments, Southpole-Parasites) or build failures due to special library requirements (Stellare-Modular-Link).

As far as I understand the quick way is to just use a different slug for every set, for example:

 Tom&GerryTools, Tom&GerryOSC, Tom&GerryFX etc.

But this approach is cluttering the module developers list menu already, not important when typing a search but a bit annoying when looking into developers list.

I noticed if we keep the same name slug at compile time, then manually change the name of the dist folder(to avoid replacing the first module set), any extra module set will appear under the same developer name (first set, second set, etc.). Version info may be confusing for users though.

Would this be the proper approach or there's another method contemplated?

Thanks!

Hi,

It's now... 1d6+5 days before 0.6 goes live. Could you give us an idea of what you'd like the module developers to do and when? I think we'd all be keen to have our modules available as quickly as possible (if not simultaneously).

Also, what version numbering scheme is preferred? I was planning on 0.6.9 for AH (0.6 corresponding to the Rack version, and the 9 corresponding the 9th release of the modules). I guess that so long as the major.minor convention is respected, you are not bothered either. way

thanks.

For all the open source plugins hosted on github it's clear that the github issues page is the channel to contact for support. The issues page can be accessed through the "Source" link.

However since I don't have the sources in my public github it would be good having some way of redirecting the users wanting to contact me to my github issues page. I can add a link in my Manual page and contact email. But I wonder if the plugin manager should provide support/contact/issues information so the users can report any problems without jumping to find the page.

I raise this because one user (of my commercial plugins) told me he had some problem to find how to report an issue with my plugins.

From the plugin manager I can see a bunch of things, but to find out what they do it seems I need to click on the manual and read that. Is there an easier way to, for example, search for filters?

We can use this thread to discuss how we want to built an automated test/build/delivery system for merged.

OSX and Linux builds shouldn't be any problem, but Windows builds might. I think we can cross compile from Linux to Windows if we install the correct headers and stuff.

I suggest that we come up with a Docker image which can cross compile for all three platforms. That way, we can share that image with anybody who wants to build for all three without using the build box.

Related, we may also want to add build_author and signature fields to the manifest as well.

If we set up a little script and a .travis.yml, Travis could automatically check stupid stuff like JSON formatting and required fields all being in place.

clickthrough stats - any notice of popularity, or lack thereof, would be awesome.

NYSTHI plugins currently do work on Ubuntu 16.04 LTS (see this issue reported back in December).

The error when loading plugins is as follows:

[warning] Failed to load library ./plugins/NYSTHI/plugin.so: 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6:
version `GLIBCXX_3.4.22' not found (required by ./plugins/NYSTHI/plugin.so)

Per the issue mentioned above, the Linux version of the plugin was compiled with Fedora 26, which has a newer compiler and supporting libraries than the current LTS version of Ubuntu 16.04.

Kent Williams provided a workaround on Facebook, which involved building a newer version of the compiler from source. This is not acceptable for non-developers. There also seems to be a workaround mentioned in the issue above that uses the custom LD_LIBRARY_PATH Rack sets up to load a newer version of the libstdc++.so.6.

I really don't like plugins relying on what I would call implementation-defined behavior of Rack to work (other recent example was some plugins relying on libsamplerate to be provided by Rack itself).

I understand the desire to not necessarily want to support oldold versions of Linux distributions, but could we define a minimum supported version of fundamental libraries for plugins that follows what Rack requires? Is this defined for Rack already?

We could punt and say that a "unified build system" (for example see #6) for all plugins would help solve this, but immediately, certain plugins are not working on all platforms. Cross-platform support is hard and plugin developers should be aware of those issues. Just jumping to the latest, greatest distros for development and requiring users to either upgrade or do other (worse) things does not seem to be a very user-friendly approach.

Thoughts?

Bidoo, Bogaudio, dBiz, and Sonus Modular are all causing the Red Dot issue as of 1/10/18 on Windows. Can any one else confirm this?

I don't know if I should be posting this here, but I would like to supply my manifest file for the v2 community repo, and also request an update of the repo link to my latest master. Thanks!
ImpromptuModular.json:

{
  "name": "ImpromptuModular",
  "author": "Marc Boulé",
  "license": "BSD 3-clause",
  "contactEmail": "[email protected]",
  "websiteUrl": "https://github.com/MarcBoule/ImpromptuModular",
  "manualUrl": "https://github.com/MarcBoule/ImpromptuModular",
  "sourceUrl": "https://github.com/MarcBoule/ImpromptuModular",
  "latestVersion": "0.6.0",
  "status": ""
}

This is an invitation for anyone who is interested to volunteer in curating, building, and organizing open-source Rack plugins for all Rack users.

Many people from very little to advanced C++ knowledge have asked how they can help the VCV project. This is a perfect opportunity for all to contribute. Volunteers may focus on one or multiple tasks required to keep the zoo of plugins up-to-date and working.

1. keeping plugin metadata up to date, perhaps including URLs and screenshots for the website
2. building plugins from source on any of the three OSes to produce ZIP packages that users will download automatically from the VCV Plugin Manager
3. auditing plugins for security and marking them as "valid" when they are added and occasionally when they are updated
4. testing plugins for improvements that could be reported back to the developer

The name "VCV Community" is different from the "Rack community", which includes all Rack users. If you a only a Rack plugin developer, it is of course not required to be a member of the VCV Community, but I would highly encourage you to consider, since you already have the skill of building and reading C++ code and knowledge of the Rack platform.

After the VCV Community is ready to "launch" and all procedures and guidelines are decided, I may be willing to provide free commercial VCV plugins or other compensation for quality contributions.

For now, this thread will serve as the discussion platform for inventing those procedures and guidelines. The timeline to launch is a month or two after Rack 0.6 is released and a few months before Rack 1.0 is released.

I have just uploaded a new version of some plugs with small bugfixes.
VERSION is the same
filenamame and download URL are the same
I noticed that the SHA256 code remains the same is filename doesn't change

Should I edit the Manifest or should I simply replace the files on my server and that's it?

Haven't checked the others...

well, maybe I am just idiot today or I missed something....
but how do i link my plugins for download if they are not on a repo but on my server?
I had no problem with the direct link approach we had before, but can't understand how to create the manifest now...

what's the idea with setting RACK_DIR? we do it by hand / in .bashrc?

The vult modules plugin here:
https://vcvrack.com/plugins.html

incorrectly has a link to the source of the vult modules. However, the author has removed the source:

https://github.com/modlfo/VultModules

Relevant section from readme:

Where did the code go?

I have decided to close the source of some of my new plugins. The reason for closing them is because my new plugins have a very substantial amount of work and research. The nature of my code makes very hard enforce the license terms and the fair use. Even when only some of the modules are closed source, I have removed all the code from the repository in order to avoid confusion when someone compiles the code and some of the modules are not shown.

Please remove the source link as its misleading.

Platform: Windows

From vcv-plugindownloader script:

[FrozenWasteland] Version 0.5.11
[FrozenWasteland] Downloading version 0.5.11...ERROR: Checksum verification failed
expected: df233bb718ff171fd9d9b120e44adcbf77924178e848816930356876df07c689
actual:   0d5e65f6e061127eb7bde4a5a117539da580c26de694acd5b9e87d291d4f2198

The spec has no field for author. I think people should get credit for their work.

The Review team is responsible for updating and adding plugin source code to repos/, making sure the source code is not malicious.

Workflow

Begin by checking this repo's issues for requests from plugin developers.

If someone requests an update to their build, first figure out what commit they're talking about in their source repo. Sometimes they'll mention a tag or branch or just say "the latest".

Next, cd into repos/<their plugin> and git pull, git checkout <tag>, or do whatever it takes to get the source they want into the submodule.

Then most importantly, review the source code for alarming stuff like system() calls, networking, modifying files, running stuff in the background, and anything else creative that someone can do. It's just as important to review their Makefile.
A "review" simply means gliding your eyes over the source code, or git diff in your terminal between the current commit and the last state of the submodule. TODO: What's a git command to compare the submodule's HEAD with the submodule's HEAD of the previous community commit?

If all is good, set "repoVersion" in the plugin's manifest JSON file to the VERSION string specified in the plugin's Makefile.
Don't change "latestVersion" or "status" in the manifest.

Finally, make a commit, and send a pull request (if you don't yet have VCV community access). In your commit message, say "reviewed" somewhere to acknowledge that the commit only contains reviewed source code.

Members

• @phdsg
• @mdemanett
• @cschol

@dBiz Can you please check into the following issue I filed a while ago. The checksum of the dBiz plugin still fails on Windows.

@AndrewBelt @Phal-anx Maybe we should remove that particular version of the Windows build from the manifest until it is fixed? Linux and MacOS are checking out fine.

Is it possible to get a column added to the table that represents release date?

If I use the "create new file" method to make a PR, rather than forking, do I create "myslug.json", or "plugins/myslug.json".

tx.

I am confused about slugs

in my Autodafe.cpp

void init(rack::Plugin *p) {
    plugin = p;
    plugin->slug = "Autodafe - Drum Kit";

    #ifdef VERSION
    p->version = TOSTRING(VERSION);
    #endif

should my manifest file reflect the SAME EXACT Slug? Without spaces?
In my Manifest I have something like "AutodafeDrumKit" at the moment...

https://github.com/VCVRack/community/blob/master/plugins/Grayscale.json says:
"source": "https://github.com/VCVRack/Grayscale", but it's not there anymore.

HTH

Hi.
I'm trying to open some patches and getting the message "could not find plugin ...".
"mscHACK or "ML_Modules" for instance, but these are installed and i'm able to see and open the modules.

any idea what could be wrong.
I'm on Windows 7_64

Thanks
Rico

Making everybody store and download versions for systems they don't use is going to be a waste of space and bandwidth for everybody, and requires that developers run a script or something to merge their zips. It's more sensible to split downloads into distinct architectures. I hope this ship hasn't sailed.

please update

A future where people want to run VCVRack on Windows 10 ARM devices and Raspberry Pi devices, isn't too far off. We should we using better platform descriptors for our prebuilt plugins. I propose:

As a first go, I propose slug name be:

`uname -s`-`uname -m`

eg Darwin-x86_64

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.

After the latest pull this morning all publicly available v0.6 versions of plugins compile fine, except hetrickcv (@mhetrick).

src/BlankPanel.cpp: In member function 'virtual rack::Menu* BlankPanelWidget::createContextMenu()':
src/BlankPanel.cpp:174:53: error: 'text' is not a member of 'rack::MenuEntry'
     menu->addChild(construct<MenuLabel>(&MenuEntry::text, "Panel Art"));

BlankPanel.cpp source for reference.

@AndrewBelt Is this an update to the API and/or should this code be implemented some other way?

av500 uses -fshort-enums in the Makefile, which crashes Rack when using the search field for modules.

Issue reported here around 20 days ago.

Recommend removing from manifest until Makefile is updated.

I have my binaries ready but I found that I didn't add the last zero to the version number. I have v0.6 instead of v0.6.0. I don't know if this is an issue.

https://github.com/modlfo/VultModules/releases/tag/v0.6

In any case, I'll update my binaries in a couple of hours with the full version number and I'll wait for instructions to make them available.

Participating in the Library team is the simplest of the four. Requires knowledge of submitting PRs and editing JSON in the manifests/ directory.

Tasks

• Keep plugin manifests correct and up-to-date.
• Handle issues opened by plugin developers who want to add/update their plugin.
• Seek new plugins/updates when developers don't notify us.

Workflow

Begin by checking this repo's issues for requests from plugin developers.

If someone requests an information change, simply make a commit (and send a PR if you don't yet have VCV community access) with the change to the manifests following the manifest format at https://github.com/VCVRack/community#library-team, and someone with write access will accept it after a quick review. You may combine multiple manifest updates in one PR.
Do not modify or add the "status" or "latestVersion" property.

If someone requests an update to their build, leave that to the Review team (or become part of the build team by reading the instructions #353).

If someone requests a new plugin to be added, add a new JSON file to manifests/ with all known information. Do not add the "status" or "latestVersion" property.

Finally, send a pull request, and someone with write access will review and accept it.
After accepted, notify the plugin developer by commenting "Updated information" in the original plugin's thread.

I think that's it, pretty simple. I may add JSON validation scripts that you should run before committing, but I'll wait until we've had a case of invalid JSON. Expecting all plugin developers to write valid JSON (like we did in during Rack 0.5) is impossible, but I can assume Library Team volunteers will do most everything correctly since you'll be more familiar with the process.

Members

• @cschol
• @phdsg

This will be a Rack 1.0+ thing, so don't worry about until then.

There should be no manifest data in C++ files except the Plugin slug and Model slugs. Instead a plugin.json file should be created alongside the plugin.{dll,so,dylib} files with all the information that is currently in the C++ and this repo's manifest.

We'll have ~6 months to standardize this after Rack 0.6 is released. The standard will of course be derived with whatever this repo evolves into.

My goal for this repository is to achieve perfection of the plugin manifest JSON files for all known Rack plugins. Once achieved, the "red dot" on the Update Plugins button will go away for all platforms when all plugins are successfully downloaded to the users' computers.

This will involve cooperation from plugin developers, but they will not know what to do unless you tell them upon finding an issue. The rest of the work is making sure the manifest JSON files match their actual plugins, instead of what they claim they should be.

Here's how the whole system works.

As soon as you commit or merge a pull request (PR), the api.vcvrack.com server receives a webhook from GitHub, pulls its own local copy, and re-loads it to be served at https://api.vcvrack.com/community/plugins.

On launch, Rack requests this file as well as a list of the logged in user's plugins and follows the following logic when the user clicks the Update Plugins button:
If a slug is present in your VCV account, check that the slug is currently loaded and that it has the same version that the JSON manifest claims. If not, download the new version if a download URL exists for your architecture. Once done, ask the user to restart Rack.

Rack produces a log.txt file with warnings and info regarding plugin downloading and loading, which is helpful in figuring out which plugins need repair.

Potential problems

• Plugin's C++ slug doesn't match the manifest slug
• Plugin's C++ version doesn't match the manifest version. Or even worse, the C++ version is different among different architectures.
• and all the bullet points in #7 (read it). @jeremywen's TravisCI tests help, but be aware that it may return false positives or true negatives. The automated tests cannot check the first two points, since only Rack can open plugin.dll/.dylib/.so files.

I'm always open to architecture suggestions if you think this system can improve, but be aware of the costs of everyone's time when making breaking changes.

This is a design proposal for adding a "modules" property with information about each module contained in a plugin.

{
	...,
	"modules": {
		"VCO-1": { // slug
			"name": "VCO-1",
			"tags": ["OSCILLATOR"], // matches tags.hpp without the _TAG suffix
			"screenshot": "https://..."
		},
		...
	}
}

A lot of things I don't like here.

• Redundancy with C++ code
  • The obvious solution is to include the manifest called plugin.json in the same folder/package as plugin.{so,dylib,dll}. But then how do we ensure that the same plugin.json file is used in the ZIP package and the community repository? We can't because of a circular dependency on the download URLs. Fundamentally, how do we distribute this metadata to both experimental plugins (that don't belong to the community repository) and polished plugins in the community?
• People will try to make up their own tags, but they should be fixed. Additional annoyance for developers.
• Where does the screenshot be hosted? Later, it could be solved with the web app idea below, but where should it be hosted then too?

Web app for creating/editing manifests

• Attached to your VCV account
• Can be used to monitor popularity

Disclaimer: The existence of an issue by me doesn't imply it will be implemented.

Could it be possible to add an favorite list for plugins instead of searching everytime thru the whole list to find the right plugin?
Greetings

this is not an ISSUE but more an ADVICE:

if you do development on OSX and at the end you compress the package for your plugin using the
right mouse button :

compress yourpluginpackage

you can remove the unneeded items doing 2 commands on the the terminal:

1. TO REMOVE the __MACOSX dir do:

   zip -d yourpluginpackage.zip __MACOSX/*

2. TO DELETE ALL the .DS_Store files do:

   zip -d yourpluginpackage.zip */.DS_Store

@jeremywen, is not so important but, maybe you want to add to you FAQ