Serious problem with saved state of parameters

[chapelier fou]

I've had this problem with M4L devices for a while and it's pretty serious. At first I thought it was happening only with the Convolution Reverb, but it's happened with some custom devices as well.

Problem description :

When opening a set containing a M4L device, some parameter don't recover the saved parameter values. They are set to 0 for some or all of the parameters. When reloading the set, the bug is still there, meaning it's been "saved" with the wrong values.
This happens quite rarely (I'd say 1 time out of 1000).

The weird part :

When this happens, ALL the sets within the project are affected. Meaning that all previous saved versions load with the same, wrong parameters values.

I'm extremely concerned by this.
For instance, I once had, on stage, an hardware synth not playing because all the check-boxes on my custom MIDI filter device were checked off.
Other real-life situation, on stage : Convolution Reverb set with a Decay and Size to 0%.

[filter_7]

Did you try with preset + pattrstorage?

When I design my max for live devices I like to avoid the saved state option, and use the preset box method instead.

I save my preset in the matrix box, and when I re-open a set I load the preset too with no problems.

I did'nt try with convolution reverb or other Ableton max devices, but it could be the solution for the issue.

If you try it before me please let me know.

[chapelier fou]

That’s a good suggestion. It will take a long time to test as it happens quite rarely, but I will.
It’s bug though, and needs to be corrected.

[pottering]

If it happens rarely, then maybe it is the fact that if you load a Set (and probably M4L presets too) while the audio engine is tuned off (like when the audio interface is not connected), then Live doesn't load the parameters for the M4L devices(I assume it is because M4L is also turned off)? You have to turn on the audio engine then re-load the Set.

[chapelier fou]

If it happens rarely, then maybe it is the fact that if you load a Set (and probably M4L presets too) while the audio engine is tuned off (like when the audio interface is not connected), then Live doesn't load the parameters for the M4L devices(I assume it is because M4L is also turned off)? You have to turn on the audio engine then re-load the Set.

Well, I’d love to think it’s the reason. That would mean that sometimes it would occur when I would reopen a set after the computer have been sleeping or whatever, and then save the set before realizing that the parameter values are messed up.
BUT this would not explain why it fucks up all the previous saved sets in the same project.... this part is so weird.

[chapelier fou]

Here is a video showing what happens here from time to time (on 2 different computers).
It's extremely bad :
- The Set would load with CR Decay and Size to their minimum values.
- Every previously saved versions (I use incremental names) would be fucked up as well, BUT I DIDN'T OPEN THEM.

https://youtu.be/D0zo1Oyk_i8

[djorno]

DUDE!

Watched your video and I am extremely frustrated with a similar issue. I'll use M4L devices throughout my set (some stock, others slightly modded [I'm sure they're buggy as I'm no coder, still they do the job {usually} for now]) and, without me ever knowing when the exact point of fuck-uppery during my workflow is, and which operations / changes in particular cause this headache, I'll discover that the Multimap mappings attached to all these devices have been mysteriously undone along the way.!

Luckily (or so I thought) I save version numbers of my sets as I go, so just load the old one, yeah? But it seems once the bug wrecks my latest set, when I go back to backup sets from days ago which were definitely functioning as intended previously, they too have all been totally unmapped! So much for my backup system.

Given that I have literally *hundreds* of these M4L mappings -plus- my system is already bogged down from intense CPU / RAM demand -plus- the architecture of my template is such that it requires many more repetitive clicks n’ drags n’ hold-button-while-program-hangs, whenever this happens (and it’s plagued me on several occasions over the years) I wind up doing hooooooooours of recovery work, which is tedious and demoralizing.

I got started on a support ticket with Ableton recently, but have been getting other stuff done and so kinda backburnered it. But given your very recent post regarding this soul-destroying bug I figured it best to signal boost. Even when Live 11 was announced, as cool as it looks, I just kept thinking "Wish the existing M4L issues would be resolved first before new bells and whistles are added". (Though on a side note, new functionality / improvements to the Follow Action system in particular solve challenges I was trying to fumble about and figure out using M4L, so the upgraded functionality is dope! Haven’t got to the beta yet.. Still trynna stabilize my work in 10.)

I am starting a new routine of saving to new projects, and hoping that this bypasses the corruption issue.

I see you were on the other thread where Angstrom wrote “I have many devices I’ve written which when I try to save them will corrupt not only themselves, but the parent live.als requiring a recovery by editing the xml. Many many times have I done this.” Have you any experience with editing the xml? I do not. Maybe the answer lies here.

ALSO, I have another issue with M4L devices where when I attempt to Collect All And Save so as to assemble all together into a Live Pack to share, it decides that the new M4L amxd file copied to the new Project Folder, each device in the set that now references this freshly created amxd have their mapping button entirely *erased* from the UI. It just *whoosh*, is no longer there, and I’m left with a blank grey box. Like… What?!

Anyway. This is basically a just as lengthy but kinda reworded wall of text akin to the one I made in the ‘Unstable’ thread. The suggestion of ClyphX doesn’t work for me, as I am restricting myself to the tools that come included native to Live and don’t want to complicate with costly 3rd party.

haaaaaaaaallllllllllllllllllllllp

[chapelier fou]

It looks like it could be the same problem indeed...
That's nice that you opened a ticket with the support, because they once responded :

There is no way that an issue in one set affects another set!

It might have happened that you saved a set unknowing of the fact that the parameter values of the max devices were all at 0.
In that case, you have overwritten the values and need to recreate all settings manually.

Which I agree would be what must have happened, but I swear I'm not to blame. It happened so many times, and sometimes with parameters (on custom devices) that I never touch.

It seems indeed that there is a MAJOR issue with M4L parameter save, that seems to deal with many GUI elements, which is, basically :

- some parameters are sometimes not saved with their correct values
- the wrong values are mysteriously saved in all previous versions of the livesets of the project.

Question is : when does it happen ? My guess, or my feeling, is that it happens on the saving action.

Out of curiosity, how do you name your livesets ? I thought that the naming "convention" could explain/avoid the bug "irradiation" to other sets. I do "mysong 0.01.als", "mysong 0.02.als", etc....

[djorno]

"There is no way that an issue in one set affects another set!"

Definitely calling bullshit on this one. And especially in my case, it's not that the parameter values were set to 0 or anything like that. It's not like I manually unmapped hundreds of devices and it just slipped my mind, so whoever told you that is speaking out of their ass. I really don't think, at least in my case, it 'must' have happened. You said it yourself, it happens with parameters you don't even touch.

Figuring out the when/why would be a nice workaround even if the overall bug were to remain. Like I said, I'll be saving my versions as new projects instead of sets and see if that spares me the trouble.

I name my sets as such: Exampleset---1.als, Exampleset---2. I don't see why this would have any effect, but who knows?

With the userbase as large as it is, I highly doubt you and I are the only ones experiencing these anomolies. Please, Ableton Gods, smile down on us and bless us with the functionality we oh so desire! I endeavour to turn as many people into Ableton customers as I can, but until these issues are resolved, I can't / won't.

[[jur]]

Do you collect and save? In this case a copy of the devices is made and those copies are used within your project. That could maybe explain a bit why the values are changed in all sets versions?
Could be some live.object that don't use the persistent mapping option?

[chapelier fou]

I’ve had the bug a few times quite recently and I did not collect and save.

[djorno]

What happens to me if I Collect All And Save is that the 'new' device it creates (so that it is referenced in the project folder itself instead of pointing to the amxd in my User Library) breaks and goes mysteriously empty grey box.

[[jur]]

I’ve had the bug a few times quite recently and I did not collect and save.

But is it possible that you've been using a copy of e.g Convolution Reverb rather than the original one?

[chapelier fou]

Do you mean a copy from another set that have been collected and saved ?
It’s very unlikely, and in any case would be insignificant in comparison with the high number of bug occurrence

[chapelier fou]

And..yeay it just happened with the new beta version of Convolution Reverb.
And I checked, it was using the version located in the Pack.
Just. Fuck. It.