Cloning an automation track does not copy pattern contents if pattern is connected to a control

[messmerd]

Summary

When I clone an automation track, the contents of a pattern in that automation track are not copied if that pattern is connected to a control, nor is the connection to the control copied. If a pattern is not connected to a control, however, the contents of that pattern will copy over successfully as expected.

My Thoughts

I am not sure if this is a bug or is intentional.

If it is intentional, it seems like a poor design. If there is a concern about there being two patterns connected to the same control at the same time and sending two conflicting values to the control, this conflict could be resolved in other ways that don't involve deleting the pattern contents or removing the connection to the control. For example, you could only use the pattern in the last automation track and ignore any conflicting ones in automation tracks before it. This already seems to be the behavior if you copy an automation track's pattern into a new automation track without using the "Clone this track" feature.

Steps to Reproduce

• Create an automation track

• Create empty pattern in automation track and connect a control to it (shouldn't matter which one)

• Create a waveform of your choice inside the pattern

• Clone automation track by clicking the gear icon and clicking "Clone this track"

Expected Behavior

Cloned automation track contains pattern with the same waveform as the original automation track's pattern and is connected to the same control as the original pattern

Actual Behavior

Cloned automation track contains pattern with a range of 0 to 1 and is set at a constant value of 1. The pattern also lacks any connections to controls.

For example:

In the screenshot above, the first automation track is the original and the second is the clone. As you can see, the first pattern which had a control connected to it was not copied correctly and also lacks its connection to a control. However, the empty pattern and pattern without a control connected to it were copied successfully.

Affected LMMS versions

I am using LMMS 1.2.2 (64-bit) on Windows 10.

[IanCaio]

Did some code hunting on this issue. I think this is caused by AutomationPattern::resolveAllIDs() not being called after the cloning operation happened. I tested adding resolveAllIDs to the end of AutomationPattern::loadSettings() and it fixed the issue. I don't think that's the way to go though, because currently resolveAllIDs is called on the methods that are performing operations on the project instead (probably to prevent the IDs from being resolved before the actual objects are added, i.e. when the project is being loaded for example). So the fix should probably be adding AutomationPattern::resolveAllIDs in the end of the Track::clone method. I could submit a PR with it.

[IanCaio]

Closing this issue since the bugfix ( #5732 ) was just merged to master.