vcvrack / library Goto Github PK
View Code? Open in Web Editor NEWDatabase for the VCV Library
Home Page: https://library.vcvrack.com/
Database for the VCV Library
Home Page: https://library.vcvrack.com/
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?
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.
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.
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
On Windows:
CastleRocktronics-0.5.0
)solmods
)sonusmodular
)Stellare-Modular
)ValleyRackFree
)VCVRack-plugin-JE-0.5.0-Win
)VCVRack-Simple
)VultModules
)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.
what's the idea with setting RACK_DIR? we do it by hand / in .bashrc?
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.
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?Web app for creating/editing manifests
Disclaimer: The existence of an issue by me doesn't imply it will be implemented.
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?
clickthrough stats - any notice of popularity, or lack thereof, would be awesome.
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?
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.
https://github.com/VCVRack/community/blob/master/plugins/Grayscale.json says:
"source": "https://github.com/VCVRack/Grayscale",
but it's not there anymore.
HTH
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.
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.
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.
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
@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.
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.
Version should be updated to 0.6.0
Haven't checked the others...
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
Is it possible to get a column added to the table that represents release date?
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:
TO REMOVE the __MACOSX dir do:
zip -d yourpluginpackage.zip __MACOSX/*
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
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?
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!
Participating in the Library team is the simplest of the four. Requires knowledge of submitting PRs and editing JSON in the manifests/
directory.
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.
The spec has no field for author
. I think people should get credit for their work.
Inspired by this thread in the Rack tracker:
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?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
.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.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.
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.
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?
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.
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
please update
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"
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.
git checkout master
and git pull
the latest Rack source code, and build it.git clone
the forked repo in your plugins/
folder.RACK_DIR
which will be useful later.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
.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.
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.
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.
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.
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...
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": ""
}
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):
It would be immensely helpful if there was a standardized method to get the last good version to compile.
What would that entail?
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:
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.
please update
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.
Placeholder. Subscribe if you are interested in joining the Build team.
TODO
Only the Build Team may change properties status
and latestVersion
in manifest files.
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...
The Review team is responsible for updating and adding plugin source code to repos/
, making sure the source code is not malicious.
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.
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.
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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.