Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

carla.lv2 doesn't write out parms correctly #753

Open
suedwestlicht opened this issue Sep 21, 2018 · 18 comments

Comments

Projects
None yet
4 participants
@suedwestlicht
Copy link

commented Sep 21, 2018

In Qtractor's master out bus I have a carla.lv2 patchbay instance.
In this patchbay I have 3 CALF plugins (vintage delay, stereo tools, 5 band eq). They are wired to get an extra stereo effect.

When I load Qtractor's qtr-file then everything looks good and works. The plugins inside carla.lv2 load their parameters and the GUI knobs show the correct values.

But when I save this qtr-file then the CALF parms get fucked up. Loading this qtr file loads totally different parm values into the CALF plugins.

I went back in git history and found out:

  • until 2018-08-21 everything is fine
  • until 2018-08-25 CALF parms are still ok but the internal wiring in carla is broken
  • from 2018-08-26 the parms in the qtr file are written incorrectly (wrong values)
@falkTX

This comment has been minimized.

Copy link
Owner

commented Sep 22, 2018

I know why this happens. these calf plugins run in a plugin bridge, so that its gtk symbols dont clash with other things in carla.
Will try to fix the bridges so that lv2 plugins get saved and restored properly.
If too much work, I will just disable the bridges for lv2 plugins altogether (in 2.0)

@falkTX falkTX added the bug label Sep 22, 2018

@falkTX falkTX added this to the 2.0-final milestone Sep 22, 2018

@falkTX

This comment has been minimized.

Copy link
Owner

commented Sep 22, 2018

Were you making changes on the calf plugins using their native GUIs?
If so, I did a fix in latest master that might solve the issue for you, in ba0c126
Please update and report back, thanks :)
(note: previously saved projects will still be "broken")

@suedwestlicht

This comment has been minimized.

Copy link
Author

commented Sep 23, 2018

Newly created qtr-Sessions are handled correctly as you wrote.

Old qtr-sessions don't remember CALF's parms after saving even when they are updated/changed using CALF plugin's native GUI.

@falkTX

This comment has been minimized.

Copy link
Owner

commented Sep 23, 2018

Thanks for confirming. Carla was just not receiving the parameter changes, so it could not save them.
Nothing I can do about the old projects, but the new ones should remain fixed.

@falkTX falkTX closed this Sep 23, 2018

@suedwestlicht

This comment has been minimized.

Copy link
Author

commented Sep 23, 2018

Sorry, it's not resolved yet. Only those parameters that are actually changed are saved/restored correctly. The other ones get set up to default values.

Example:

  • Use CALF vintage delay in Carla.lv2
  • Set delay to "ms" and "20" (default is "BPM")
  • Set "Mix Mode" to "stereo" (default is ping-pong)
  • Close Carla.lv2's GUI
  • Save the Qtractor session
  • Load the session
  • delay is on 20 ms, "Mix Mode" is stereo. Looks fine.
  • Now don't change any value (don't touch the GUI).
  • Save the Qtracor session
  • Load the session
  • delay is on "BPM", "Mix Mode" is ping-pong.

=> So any parm that's not touched is saved with its default value when saving the Qtractor session.

Even newly created sessions have wrong CALF parms when savend the 2nd time.

@falkTX falkTX reopened this Sep 23, 2018

@Bleuzen

This comment has been minimized.

Copy link

commented Sep 30, 2018

Same when using Carla in LMMS or Carla standalone. Only parameters which are changed are saved. Re-opening a project und save again without changes breaks plugin settings.

This happens since I updated to 2.0-RC1. Before I used 2.0-beta7, and at least when using with LMMS, beta7 didn't have this issue.

@falkTX

This comment has been minimized.

Copy link
Owner

commented Sep 30, 2018

@Bleuzen are those with just calf plugins?

@Bleuzen

This comment has been minimized.

Copy link

commented Sep 30, 2018

@Bleuzen are those with just calf plugins?

No. Another example is the 'padthv1' instrument plugin.

@falkTX

This comment has been minimized.

Copy link
Owner

commented Sep 30, 2018

well, that uses the bridge stuff too :P
so I assume it is just the plugins that run in bridge mode that are currently broken.

@Lasakro

This comment has been minimized.

Copy link

commented Dec 7, 2018

@falkTX can you take a guess on when we should check back for either 2.0-RC3 or 2.0-Final to see if the bridge data is being correctly written out?

Looking to switch from Claudia to NSM but I need my beef (Calf)

@falkTX

This comment has been minimized.

Copy link
Owner

commented Dec 7, 2018

around new years is the best time. holidays are coming, I will have some time to look into this properly, I hope.
I consider it a blocker for 2.0, so before that is official out as stable release, I will get this issue sorted.

@falkTX

This comment has been minimized.

Copy link
Owner

commented Dec 25, 2018

I cant fix this easily, so I have removed the hardcoded list of plugins to run as bridges.
Calf plugins will work again from latest git.
I move this bug into another release, as to not block 2.0

@falkTX falkTX modified the milestones: 2.0-final, 2.1 Dec 25, 2018

@Bleuzen

This comment has been minimized.

Copy link

commented Dec 25, 2018

Ok, will this 'fix' it for now so that for example the parameters of padthv1 get correctly saved and loaded again?

Does the bridge mode save the parameters in another way? So could we get a problem in the future when you enable bridges again, that our old saved files with old Carla versions do not load our old plugin parameters?

@suedwestlicht

This comment has been minimized.

Copy link
Author

commented Dec 25, 2018

I can confirm that old Qtractor-projects that use Carla as a plug host for CALF plugins can be saved/restored again. Thanks for this in-between-solution that will preserve backwards compatibility.

@falkTX

This comment has been minimized.

Copy link
Owner

commented Dec 25, 2018

This "fixes" the issues yes.
The problem only happens with plugin bridges.
I won't enable them again until we sort this out properly.

It is easy to get old behaviour back for testing, by enable the experimental option of preferring plugin bridges

@Bleuzen

This comment has been minimized.

Copy link

commented Dec 25, 2018

Great (for now)!

With my second question I meant if the parameters, if in bridge mode or not, are saved the same way.
So that parameters get loaded correctly, for example when they were saved in bridge mode, but loaded without bridge mode or in reverse.
So are bridge mode and non-bridge mode compatible in save files with each other?
Sorry, can't test it myself right now.

@falkTX

This comment has been minimized.

Copy link
Owner

commented Dec 25, 2018

The save file is exactly the same, and on purpose.
The bridges are supposed to be transparent to the user. That was what I was trying to do, with the calf and v1 stuff in bridges...

@Bleuzen

This comment has been minimized.

Copy link

commented Dec 25, 2018

Ok nice, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.