Lmms: Automating "mute" is broken on project load

Created on 28 Sep 2018  路  15Comments  路  Source: LMMS/lmms

Every time you do an automation of the mute control (the green led) either on mixer, tracks on songeditor or tracks in beat bassline editor, after restart lmms and reopen the project, the control links are lost and so you have to redo ctrl every time you load it.

This is really annoying, and i think it's a serious bug. Hope this helped for RC8 :)

To reproduce it just do like i did here

immagine

The first is an automation on the 3osc track, the second of the kicker in B&B ed and the third one is on master mixer. After reloading the project neither of those will work

bug good first issue

Most helpful comment

Sounds like #2399 covers it.

Good find. I'd say let's not save this knob's automation for now if we're going to remove automation later anyways?

All 15 comments

Friend in which version of lmms are you ?, I had never seen that interface.

@Gabrielxd195, it is the FL studio theme which @RoxasKH has developed. If you are unaware, I'll like to bring to your notice that you can apply different themes on LMMS. Here you can find different type of themes: https://lmms.io/lsp/?action=browse&category=UI%20themes

@Gabrielxd195 When lmms 1.2 stable will be released i will release my theme, if you're interested, but the main argument of this was the automation problem, so the next time contact me through DM

Lets stay with the Issue -shall we?
I confirm the bug on win 32 rc7
It is a real loss of connection. The chosen shape does not apply

@PhysSong we may be able to tackle this when #3781 is closed. Milestoning for 1.2.0 assuming it's a quick fix. If not, feel free to bump it to 1.3.0.

@PhysSong we may be able to tackle this when #3781 is closed.

We can fix this even if #3781 is open.

assuming it's a quick fix

Yes. Only ~two~ four lines in Track::saveSettings and Track::loadSettings need to be changed to save automation for mute/solo. FX mixer's mute/solo works well, so we need to just adapt the logic.

A few more things which can be automated but its settings can't be saved:

  • The tension of automation patterns
  • Whether to enable effect chains

If we address them as well, it'll be enough to change just 8 lines.
Note that saving them may break loading it for old versions. However, I think that'd be fine because upgrading LMMS is enough. Also, we're approaching to the 1.2 stable now. :)

Note that saving them may break loading it for old versions.

I found that I can work around it: we can save the state as both automated and non-automated form. The automated form takes precedence when being loaded, so I think this should work without breaking the backward compatibility.

@PhysSong I could fix them all, except for "tension of automation patterns". That one isn't an automatable model, so it can't be connected nor be saved like one.

However, maybe we should make that knob automatable. The fact that you can drag, but not drop it seems confusing.

Edit: Not sure if automizing this tension knob makes any sense: The automation patterns are processed before the instruments are being played. This simply can't work, because the instrument inputting to the peak controller will be processed after any automation. Even if you connect the knob to another automation pattern, I think there is no guarantee which automation pattern will come first (users could even force cyclic dependencies between automation patterns).

except for "tension of automation patterns". That one isn't an automatable model, so it can't be connected nor be saved like one.

I can automate that because AutomationEditor do have an AutomatableModel named m_tensionModel. It sounds odd to me because AutomatableModel doesn't have such one. Also, the automation applies to the currently opened pattern in the editor.
It's somewhat nonsense, but I have no idea what should we do.

It's somewhat nonsense, but I have no idea what should we do.

Oh, I didn't see that one in AutomationEditor. If it really only applies to the currently opened editor, it's indeed nonsense that this could be automated.

Anyways, I'd say dragging this knob should be forbidden. One possibility would be to add a bool AutomatableModelView::automatable (it's a base class of Knob), defaulting to true. Not sure if this is a good approach, but I guess we should wait for stable-1.2 to fix this?

One possibility would be to add a bool AutomatableModelView::automatable (it's a base class of Knob), defaulting to true.

Sounds like #2399 covers it.

Sounds like #2399 covers it.

Good find. I'd say let's not save this knob's automation for now if we're going to remove automation later anyways?

That sounds good.

Created the PR #4667 . Tested and works. Feel free to review.

Was this page helpful?
0 / 5 - 0 ratings