Is trowaSoft on anyone else’s radar ?
[Edit] Ah, the github issues indicates that the plugin will be ported to v2.
Is trowaSoft on anyone else’s radar ?
[Edit] Ah, the github issues indicates that the plugin will be ported to v2.
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.
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!
The Skrylar plugin builds with only the change to plugin.json and a single instance of the loadPath fix.
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
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:
If you want to help
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?
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.
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. 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.
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.
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:
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)
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.