PLUGIN AUTHORS: Help migrating existing plugins to Rack v1

#39

Excellent! Thank you for the help.

gbrandt1 can let us know on Github when a new version of his plugin is available and we will integrate it.

2 Likes
#40

I’ve submitted a PR for Southpole to move to the v1 API. If other plugin authors see this thread and are looking for help migrating I’d be happy to take a look, time permitting :slight_smile: otherwise I’ll pick off the next most interesting plugin to migrate!

7 Likes
#41

The author of NonLinear Instruments has said he won’t be able to port to 1.0 but feel free to fork. So if anyone’s interested:

“Hi, thanks for your interest, but I’m afraid I’m much too busy in other things. Sorry … and feel free to fork !!“

#42

I wasn’t here for the 0.5 to 0.6 migration. Were the changes significant?

0.6 to 1.0 migration felt like a lot of busywork for almost no benefit (on the plugin side.)

#43

Not sure.

As to the busy work I feel like it’s unfortunate, but Andrew is responsible for the overall direction of Rack and if he feels the changes are necessary for the overall good of Rack I think we should give him a bit of slack. I’m fairly sure he didn’t change the API unnecessarily.

Having said that I am truly sympathetic for the amount of changes that plugin developers felt they had to make that didn’t help their plugin get any better and I’ve heard this from more than one developer so not discounting the assessment.

#44

I did a lot of PRs for open source plugins for 0.5 -to-0.6 myself and the changes were not as significant as the 1.0 changes in terms of amount of work especially.

I see anything pre-1.0 as at most beta state of the API. Per Andrew’s comments, with 1.0 the API is stable and developers can expect it to change far less frequent and with far less impact than it did up until now. The fact that even in beta state Rack took off like it did was probably not expected.

In the end, developers that care about the platform will update their modules and for those that don’t there is the option of others taking on maintenance and development if the plugin is open-source.

1 Like
#45

And that’s unpaid work, right? All the more appreciated. :+1:

But “no benefit”?
Keep in mind that v1.0 enabled me (and possibly many other people) to use many plugins for the first time. Only after v1.0 I could run a meaningful number of plugins with good performances, without constant dropouts and clicks. I wasn’t able to even try many of the existing plugins before v1.0.

2 Likes
#46

@Skrylar meant no benefit for the plugin developer and for the functioning of the plugin itself.

@mixer, what you are talking about is benefit for the user, and in fact the benefit of running more plugins with better performance comes from the improvements of the engine in rack version 1, not from the porting of plugins to the v1 API.

2 Likes
#47

i am working on porting aepelzen’s modules (which were abandoned a long time ago) to version 1, and implementing a redesign of the graphics by @pyer. i am pretty much a noob developer, tho i have some experience as a package maintainer in the past with gentoo linux, so i am not unfamiliar with the tools.

i have successfully ported the burst module, but ran into an issue with the folder module. in the right-click menu there is an option for an alternative folding algo, but clicking it results in nothing or in rack crashing. i am probably overlooking something simple, but i have not been able to track it down.

can anyone lend a hand? the code is at https://github.com/wiqid/repelzen/blob/v1/src/folder.cpp

5 Likes
#48

I don’t see module of FolderMenuItem anywhere set?

#49

thanks! got it.

#50

Oh, these panel designs look amazing, great work @pyer, again!

1 Like
#51

Yea, if you forget a setModule call you get a crash. And don’t expect gdb to explain why either. The stack trace will just show a death deep in Rack with no mention of your plugin :thinking:

There really should be an assertion and “this plugin is broken” pop-up for that.

1 Like
#52

I just opened a pull request on Github to update the StochKit modules:

Waiting for the owner to (hopefully) get back to me…

4 Likes
#53

i’ve started implementing polyphony in the repelzen modules, starting with refold. i would like to implement the “advanced” simd optimization, but i’m a bit out of my depth here. where do i need to add float_4, where [c / 4], and where not? if someone wants to lend a hand, i would be much obliged: https://github.com/wiqid/repelzen/blob/master/src/folder.cpp

(i’m also considering dropping the alternative mode, since it doesn’t seem to make a difference.)

#54

float_4 is a vector of 4 floats. If you want to support up to 16 channels, you need an array of 4 float_4s. See How polyphonic cables will work in Rack v1 for more information.

#55

the PR was merged :slight_smile:

1 Like
#56

i had found that, and that was my starting point. i have also found a couple of examples of how it was done in open source modules (tho to my surprise i also saw quite a few who didn’t use the advanced method), since that is the way i learn best. but i am too much of a noob… i guess i’ll need to keep trying, and study more c++, until i figure it out.

#57

Hello all, the author of the fine PvC plugin just announced that he will try to port his plugin to v1.
Maybe someone could assist and help him if he needs help?

2 Likes
#58

Hi, I could use some help with porting the plugin I’ve developed for Rack v0.6.2c. It is a single plugin called Vocode-O-Matic (which you will find under the name Sculpt-O-Sound), so that should not be too much work to convert.
I’ve managed to create a working copy for v0.6.2c by looking at example code but since I’m not really fluent in C++ I have difficulties in understanding the changes needed for v1.x. I tried to follow the migration steps but am running into troubles after that (see branch here: https://github.com/josbouten/Sculpt-O-Sound/tree/v0.6_to_v1.1). Possibly it is best to start again but with the guidance of someone more experienced in C++. Can anybody help?