Add Carla automation support

[ghost]

Thanks PhysSong for the review in the previous PR.

• Converted all indentation to tabs.
• Added whitespaces (coding style).
• Removed EffectControls.h from carla.cpp
• Removed QtDebug from carla.cpp, it wasn't needed anymore.
• Signal/Slots Qt4 support.

[LmmsBot]

Downloads for this pull request

• Windows 32 Bit: download.
• Windows 32 Bit: download.
• Windows 64 Bit: download.
• Windows 64 Bit: download.
• Windows 32 Bit: download.
• Windows 64 Bit: download.

Generated by the LMMS pull requests bot.
SHA: 5d06520

[PhysSong]

Converted all indentation to tabs.

Sorry, What I mean was keeping consistency in new code, not changing old code.

[ghost]

@PhysSong ; Ok do you want me to change them to spaces again? (I’ll prefer the tabs BTW.)

I'm also working on putting the parameters in a subwindow since some Carla plugins have a lot of parameters. I have working code for this, but it needs to be cleaned before I put it online.

Other thoughts of adding are giving the user the ability to colour a knob so it stands out and it easy recognisable. And adding a search/filter bar that will result in only showing knobs with matching names.

[PhysSong]

It seems like you messed up the ZynAddSubFX submodule while merging branches, but it's okay. I can fix that before merging if you want.

[PhysSong]

Ok do you want me to change them to spaces again? (I’ll prefer the tabs BTW.)

We use tabs for indentation, but indentation changes make it harder to view changes. I think we should convert them to tabs eventually.
Feel free to do what you want for new code, but I think we should preserve old code for now.
Also, please use new coding styles for new code. You are mixing old and new conventions in some places.

// old
if( a )
{
	b( c );
}
// new
if (a)
{
	b(c);
}

Also, note that if (a) is simpler than if (a == true), the same for false.

[PhysSong]

Since master branch doesn't support Qt4, you can revert knob connection as you did in #4569 (review) . Functor-based connections look cleaner than the current way to me.

[ghost]

@PhysSong

About the messed up ZynAddSubFX submodule: Hmm I didn’t touch anything but carla.h and carla.cpp, did I have to remove the submodules before merging with the upstream? And yes please fix it before merging if you would.

I made some changes (see commit log) in response to your review, thanks again :-)

[PhysSong]

I've suggested some improvements and cleanups. Sorry for the late response.

[falkTX]

Just saw this, note that carla will have a way to handle automation in plugin mode "soon".
The base work for it is already done

[ghost]

Hello @falkTX , can you tell what that does mean for this PR? And the done base work, is it on the Carla git repo so we can follow it?

[falkTX]

Only the code that allows the actual automation of plugin parameters is in place, so nothing to see yet.
Previously the rack and patchbay engine modes would misbehave on variable process cycles, that hosts use for sample-accurate automation.
WIth that fixed, there is no more blocker to exposing some parameters in carla plugin versions.

My idea is to have a static number of parameters (say, 100), that the user can map to a specific plugin parameter. I have to expose the 100 parameters in the plugin code, and then design a new UI for this.

[0xf0xx0]

Lemmie just revive for a sec:
I ran this on MacOS Mojave, and i like it. The issues i have with it is that i can only automate the first vst in the list, or the instrument vst. It for some reason cant grab the automatable knobs in a new carla entity(?). It only got them in a existing project.

[ghost]

@gingkathfox

i can only automate the first vst in the list, or the instrument vst.

I’m not sure if it’s currently possible with Carla yet, but I will look into it.

It for some reason cant grab the automatable knobs in a new carla entity(?). It only got them in a existing project.

I don’t quite understand, what do you mean by grab then? Grab and drag to a automation track? And this only happens when you add a new Carla Patchbay/Rack instance? What about after saving and reopening the project, does it work then?

If you can tell me what version of Carla you use, I will try to reproduce on Linux, I don’t have access to a Mac.

[0xf0xx0]

@cyberdevilnl the knobs wont show up in the knob menu. they only show up in existing Carla projects. im using Carla 1.9.12 2.0 RC2.

[0xf0xx0]

and no, saving and reopening wont show the knobs either.

[ghost]

I have found a way to get a list of loaded plugins by Carla but this is kinda tricky. Also I haven’t found a way to get dispatched by Carla on the changes of plugins. A lot of questions come to mind on how to handle such events, some examples:

Unique identifier.

The CarlaBackend::CarlaPlugin->getUniqueId() method isn’t reliable since most plugins I tested didn’t supply one. We can work around that by using getName() wich should be unique but it isn’t perfect. What about this:

1. User removes a plugin.
2. User adds another plugin.
3. User renames that plugin to the same name as the previously removed plugin.

Index (Id)

We can access a plugin by their Id through CarlaBackend::CarlaEngine→getPlugin(i). But if the order of the plugins changes inside Carla so will their Id’s.

So I think it’s best to leave it this way and wait till the static number of parameters feature @falkTX mentioned (#4571 (comment)) is implemented, then change this code to work with that.

Also I’ve found two bugs in the current code. will fix that asap.

• Bug 1: If there are knobs loaded, remove all plugins inside Carla, then reload knobs and the old knobs won’t be removed. It should be empty.
• Bug 2: If there are no knobs, pushing refresh values will crash LMMS.

Oh and @gingkathfox, just to be sure did you press the refresh parameter knobs button after you loaded a plugin inside Carla? If not with current code you should, like I said I haven’t found a way yet to get dispatched on plugin changes inside Carla so till then you have to press the button manually after loading a plugin inside Carla.

[falkTX]

I appreciate the enthusiasm here to try to get this working.
But you know I am right here so you can ask me stuff on how Carla works, right?

Anyway, a proper implementation of this will need changing the code in carla.
Otherwise we just hack around it, and then have to maintain it as well, which is not nice.

You are already in the right path by using the native plugin parameter API.
I have not yet decided how many parameters will be exposed, but at least 25 (static).

[0xf0xx0]

@cyberdevilnl i did, still didnt work.

[ghost]

With Carla 2.0 we need to refresh the params and their values manual. With the develop branch of Carla it can be done automaticly, it however only works for the parameters of the first plugin inside Carla, in the future Carla should get all parameters until the max parameters is reached. (This is still TODO for Carla.)

What this means for this PR: It can be used if the behaviour of manual refreshing the parameters is acceptable. If it is not then we have to wait until Carla 2.1 is released. I'm in for waiting until the Carla 2.1 release.

I created another branch on my LMMS fork with code that's working for Carla develop branch. https://github.com/CYBERDEViLNL/lmms/tree/master_carla

Please let me know what we want to do here so I can update this PR or create a new one.

[PhysSong]

Anyway, a proper implementation of this will need changing the code in carla.
Otherwise we just hack around it, and then have to maintain it as well, which is not nice.

@falkTX How is that going on? We have Carla 2.2.0 now.

[falkTX]

Anyway, a proper implementation of this will need changing the code in carla.
Otherwise we just hack around it, and then have to maintain it as well, which is not nice.

@falkTX How is that going on? We have Carla 2.2.0 now.

This is fully supported now, exposed in Carla internal plugin as well as in the Carla VST2 version.

There is a callback on carla plugin API for when a refreshing of the parameter list needs to be done (basically everytime a plugin is added, removed or reordered).
There parameters are even grouped by plugin.

Here is how it looks for the carla-rack plugin inside of carla:

[PhysSong]

Closing in favor of #5846.

[PhysSong]

...And I didn't really close this. 😂

[tinkerlevu]

Hey wait a minute, speaking of 'getting merged', if this issue is moved to #5846, why is this still in https://github.com/LMMS/lmms/projects/11?