plugins that are questionable whether there will be V2 updates

Is trowaSoft on anyone else’s radar ?

[Edit] Ah, the github issues indicates that the plugin will be ported to v2. :slight_smile:

3 Likes

Iversion is in every patch I make. And I have an M1, I really hope someone can help porting 6+1 in it’s totality. Thanks in advance!!

EDIT: I just saw it might work soon on the mac!

This is just fantastic news!!! No patch without Iversion Jr. for me.

Anyone heard anything about Grayscale? really hope those make it over to v2.

6 Likes

Alikins:

They are really handy utility modules that I use all the time. Haven’t been updated for 2 years and I really hope someone picks them up!

1 Like

The Skrylar plugin builds with only the change to plugin.json and a single instance of the loadPath fix.

3 Likes

could you explain this a bit more, or maybe post an example?

My bad, I meant to write fontPath.

In the v1 source code for one of the Skylights modules we see:

font = APP->window->loadFont(
     asset::plugin(pluginInstance, "res/LEDCalculator.ttf"));

This should be changed to:

std::string fontPath="res/LEDCalculator.ttf";
font = APP->window->loadFont(asset::plugin(pluginInstance, fontPath));

as per the instructions here:

https://vcvrack.com/manual/Migrate2

Best regards,

dp

1 Like

I did a test build with the rack-plugin-toolchain of all remaining plugins in the v2 Backlog.

57 are building successfully without any code changes and would just have to have the version updated in the manifest.

The following plugins have build errors and do not currently build against the Rack v2 API:

  • Alikins
  • AriaSalvatrice
  • AuntyLangtonsFree
  • AuraAudio
  • BOKONTEPByteBeatMachine
  • Chiptuner
  • EH_modules
  • FrankBuss
  • ILovePerlin
  • KautenjaDSP-PotatoChips
  • Koralfx-Modules
  • LifeFormModular
  • LomasModules
  • Mog
  • MyLittleTools
  • NocturnalEncoder
  • RJModules
  • RacketScience
  • ReTunesFree
  • STS
  • Sculpt-O-Sound
  • StudioSixPlusOne
  • TheXOR
  • VO
  • WhatTheRack
  • WrongPeople
  • cvly
  • forsitan
  • luckyxxl
  • moDllz
  • mscHack
  • rchoices
  • trowaSoft
  • wiqid-anomalies

If you want to help

  • submit GitHub PRs against these plugins to fix the build issues OR
  • adopt them from the original maintainer (we will need formal transfer of ownership in those cases).
2 Likes

I have a working fork of LomasModules and submitted a PR six weeks back but got no response unfortunately. There’s only 2 modules but they are both great.

I imagine this might be the case with a few plugins so we will probably end up with a thread of unofficial forks that can’t go in the library?

3 Likes

Seems likely.

Hi, I am the developer of the Sckitam plugin. I am currently working on the v2 migration and hope to have an update soon on github.

13 Likes

Thank you. I have removed your plugin from the list above. Looking forward to your update.

(I confess I’ve never used your module, which probably makes me unqualified to express my opinion, but here it is anyway. :slight_smile: I hope this post isn’t clutter.)

Although I’ve never used Meander, I’ve watched its development with interest, and I’ve been massively impressed by the module, the music it’s helped to create, and your involvement with the community.

I appreciate the effort it would take to port it to V2, and by no means do I want to put pressure on you to put in all that effort, but I feel it would be a great loss to the community if you and Meander were to disappear from it. You and Meander have my unqualified upvote.

5 Likes

Without understanding how exactly the module works or should be used (I do not have the music theoretical understanding) I have often used the module intuitively and often achieved beautiful results for me. I would appreciate it very much if you would port the module and continue to participate in the community.

1 Like

Not that it isn’t a lot of work, but once you properly put all the global as module instance properties you can access them from the widget. The widget already has a module pointer, so you can either cast that one or keep your own typed copy. Then what was “global = foo” becomes “mymodule->global = foo”. Of course even now your widget and module are running on different threads, so better have appropriate code to handle that.

Anyone who knows c++ can help you with errors. Just put it somewhere public and ask.

You must not ever use a lock or mutex on the audio thread, or you will get pops and clicks. The general advice is that you need to be aware that any of these shared variables a pan change at any time, and it’s possible they will be in an inconsistent state when you look at them. So make sure it works ok. This is often called something like “lock-free atomic data structures”.

Sorry, I accidentally deleted my post while trying to copy it over to my development topic.

I am tentatively planning to attempt to migrate my PurrSoftware Meander plugin/module to V2 after V2 launches. As I announced in December of 2020, I “suspended” development. This plugin is not abandoned. The anticipated effort to migrate Meander is so great that I do not want to do it piecemeal and more than once.

Migrating Meander to V2 boils down to a few big issues:

  • Since Meander started out as a Windows app in 1988, I essentially turned the app into a plugin/module. To do this, I had to make all of the app variables global for V1 as the module and the module widget both needed to access the variables. The source code for the module amounts to just under 12,000 lines including just under 2000 of those being global variables.
  • Due to the use of globals, I had to make Meander operate as a singleton with only one instance of the single module plugin allowed.
  • A dynamic GUI circle of 5ths required that the GUI graphics mostly be runtime procedural with a very sparse SVG panel graphic.
  • To duplicate the Windows app, the GUI needed to display parameter values on the panel.
  • Upon users request, I made all parameters settable via CV with values once again rendered to the panel. Since the SVG panel image is basically just the plugin module logo, all input and output jacks as well as parameter knobs, etc., had to be generated procedurally at runtime.

Bottom line, Meander is a very complex module done in non-standard ways.

My approach to migrating to V2 will be to first migrate the existing V1 singleton module. If that works, I will try to figure out a way to not use global variables so that multiple module instances can be instantiated. My V1 experiments over the past couple of months have not been successful in moving all variables to the module instance level. The module code works correctly but the module widget code has referencing errors whatever I try.

If you are interested in me migrating Meander to V2, please like this post so that I have some idea that others want Meander migrated, without cluttering up this topic.

I am going to attempt to maintain a low profile, focusing on positivity, encouragement, respect, kindness, acceptance and all of those common sense but not-always commonly practiced values. Constructive suggestions are welcome.

Ken (cyberpunken)

11 Likes

Yeah, that’s what I meant. Thanks

Isn’t it possible to script most of the changes needed? I’m not a programmer but I was watching Andrew’s livestream recently where (I think) he was doing what you describe about the global variables and he made a comment that on his normal setup he had a script to change the globals to non-globals.