LFO kills undo functionality?

[TomKern]

And people still wonder why I won't touch M4L...

Seriously, it's a hack channeling an unstable workaround.

Native LFO or Bust!

[kleine]

The Undo issue is known by Cycling and Ableton and has remained unfixed for about.. Ehm, when was the Live 8.2.2 release?
Your problem is just with one LFO, imagine switching 16 of them at once. You'll get at least 32 undo "Change" actions.
The whole Undo feature is there, literally to undo the mapping of an LFO. Right in the way of the 101 different things you might want to achieve. There is no workaround.

As said before, LFO isn't the culprit here.

I know, its Persistent Mapping. Present in some live.xxx objects. The most used one being the LFO (live.remote~). But it goes for all mapping devices.
Any action that changes an ID on an object with persistent mapping, will add a "Undo Change" to the menu. Devices with multiple objects keeping track of the ID, will add an "Undo Change" for each object. Resulting in the problem of added Undo actions that undo nothing at best and break device functionality at worst.

That has nothing todo with the described problem here....

[hoffman2k]

Not being purposefully obtuse here, but the thread title and the first post do point out an existing problem.
I realise that in this instance the issue has been identified as the smoothing of a parameter, but it serves as another example where a developer might want to be able to toggle Undo logging off for whatever action the device needs to undertake.

There are 2 other reasons I know off why Undo history gets filled with useless entries and why some devices will make the Live Set "dirty" (as in, you get prompted to store changes) even though the user didn't manually change anything.

1) Persistent mapping creating Undo Entries to undo the mapping of a parameter. Multiple parameters being cycled through a single object with persistent mapping will add more undo's on top of the actual last mapping action.

2) Rounding errors from the values coming out of Live.observer to a dial and going into Live.remote~. Depending on how a patch is built, sending a value like 0.0000001 won't always return as that same value once processed by whatever functionality of the MFL device. That value might be too small to register as an audible or even visible change, but undo could register it. In my recent patches, it turned out that scaling values (to a dial and back) turned up with unreliable results. But nothing I could reproduce right after experiencing it. In the end I just threw out live.dial and scale from my control device in favour of a single Function object. It'll still happen like once every few hundred actions, but I eliminated all but one possible object to cause rounding errors and not having MIDI Mapable dials eliminated most "undo change" events.

The user case in this thread could possibly be fixed if its technically possible for the developer to work around the undo triggering event. But it would be easier to just be able to turn the logging off for that event and back on to create the intended event.
My apologies for hijacking the thread and going on about this for years on end. Maybe I can just bundle all those posts into an anthology titled "My quest for a toggle button".

[kleine]

Not being purposefully obtuse here, but the thread title and the first post do point out an existing problem.
I realise that in this instance the issue has been identified as the smoothing of a parameter, but it serves as another example where a developer might want to be able to toggle Undo logging off for whatever action the device needs to undertake.

There are 2 other reasons I know off why Undo history gets filled with useless entries and why some devices will make the Live Set "dirty" (as in, you get prompted to store changes) even though the user didn't manually change anything.

Examples?

1) Persistent mapping creating Undo Entries to undo the mapping of a parameter. Multiple parameters being cycled through a single object with persistent mapping will add more undo's on top of the actual last mapping action.

If you map e.g. the LFO to a send, you can undo the mapping. This is expected behaviour. Not sure what's the problem for you here.

2) Rounding errors from the values coming out of Live.observer to a dial and going into Live.remote~. Depending on how a patch is built, sending a value like 0.0000001 won't always return as that same value once processed by whatever functionality of the MFL device. That value might be too small to register as an audible or even visible change, but undo could register it. In my recent patches, it turned out that scaling values (to a dial and back) turned up with unreliable results. But nothing I could reproduce right after experiencing it. In the end I just threw out live.dial and scale from my control device in favour of a single Function object. It'll still happen like once every few hundred actions, but I eliminated all but one possible object to cause rounding errors and not having MIDI Mapable dials eliminated most "undo change" events.

Example set? Without concrete examples, we can't help.

The user case in this thread could possibly be fixed if its technically possible for the developer to work around the undo triggering event.

It is apparently a bug in Diffuse.

But it would be easier to just be able to turn the logging off for that event and back on to create the intended event.
My apologies for hijacking the thread and going on about this for years on end. Maybe I can just bundle all those posts into an anthology titled "My quest for a toggle button".

[[jur]]

[quote="kleine"
That has nothing todo with the described problem here....[/quote]
Thanks for seconding me on this

[hoffman2k]

Alright, might take a while to have examples for all the mentioned problems, as some are very difficult to reproduce. But some are easy enough, so lets begin with those:

Flooding of Undo history example 1:

1) From the Max for Live essentials, load Map8 DEMO.als

2) Observe that you start with 7 undo actions for the 7 mappings that happened when loading the set.

3) Undo 7 times until the history is clear

4) Move Macro 1 "LPF" to another value (with a single mouse movement)

5) Now there are 2 Undo entries created.

6) Undo once and observe that "LPF" jumps to a wrong value

7) Undo again to make it jump to the right value.

You can also skip step 2 & 3 if you just want to do the wrong value jump. The set starts off with the value at 82.7%. I set it to 35.4% and now hit undo. It jumps to 81.9% and I hit undo again. Now its back to 82.7%.
A thing to note is: while running the device normally, the 2 events are both labeled as "undo change macro 1".
If you do this test while in Edit Mode, it will jump back to the right value. But now you have 2 events named "undo change macro 1" and "undo change". The second undo does nothing while in edit mode, apparently.

The rounding errors are way more difficult to reproduce, hopefully I can reproduce it in an older version of one of my mapping devices. The bug with Map8 and the jumping values won't be because of rounding, but most likely a trigger order issue. I haven't fully debugged it, but it's exactly the same issue me and other developers face.

And again apologies for taking over the conversation of an identified bug in the Diffuse device. My only argument here is that while the issues seem totally unrelated, any forthcoming solution to my problem could aid the creator of the Diffuse device to solve his problem if I am correct in my assumption of the cause. To put it as plainly as possible: We all make patches to work from the top down. The extra undo action somehow triggers one thing, while the original undo triggers something else. With varied results, while the expected result is one action from top down for a single created undo event.

[hoffman2k]

Flooding of Undo history example 2:

1) Start with an empty Live set

2) From the Max for Live essentials, add the LFO (Max Audio Effect)

3) Observe that you now have 2 Undo events. First "Undo Change", which does nothing followed by the expected "Undo Insert Device"

Edit: Same goes for the other Control Devices of that collection. But also my control devices and a random mapping device from maxforlive.com like: http://www.maxforlive.com/library/device/4016/8mapping

[stkr]

Hi all, stkr of Diffuse etc here.

Ultimately, whilst there is what could be considered a 'bug' in both Diffuse and Magnetic, which I will fix, I believe that when created three years ago, this bug did not exist how it manifests itself now. I might be living in denial here, and yes I am investigating and taking it seriously and will report anything I find to Ableton and here.

If 'id 0' is called on a live.object after having been id-ed and used on device instantiation, that live.object should have no mapping attachment whatsoever. In my current tests this is not the case at the moment. This is different to what hoffman2k has been reporting. As far as I am concerned, both of his above reports are completely true. I see them as specifically bad implementation in the device and the API. I agree these issues should be tackled. However, the OP mentioned the LFO device only by association here - in this instance, it is Diffuse (and Magnetic) that are 'at fault' for allowing the tyranny of the Live undo system to do it's thing.

As mentioned before in this thread, a live.*** system was added to both Magnetic and Diffuse 'Repeat' dials in update 1.1 of Dub Machines, in about October 2014 I think. (We are currently on version 1.2 and another update will be forthcoming). This was in order to deal with the adding of beat sync-ing features whilst attempting to maintain the same load behaviour as the original devices. Of course now I regret this complexity, and have never done it again since

The question I have been asking myself is:
Should I change the load behaviour of the Dub Machines devices at the risk of upsetting the many (many) current Dub Machines users out there relying regularly on our devices?
I have decided I will rewrite and get rid of this 'Repeat' dial bug, but only with extensive beta testing.

So, the tested fix may not be here until June / July sort of time. I am not sure at the moment. If anyone in the mean time really needs to LFO/whatever the 'Repeat' dials of either Diffuse or Magnetic (note, this bug ONLY affects those dials) then please get in touch at [email protected] and I will send you a temporary fix (which the OP of this thread is already testing for us).

Thanks,
And sorry for the verbosity,
stkr .

[hoffman2k]

Hi Stkr,

Sorry for the noise and thanks for your thoughts on the undo issue.

In regards to the issue you're describing, check all instances of live.object for the persistent mapping flag.
I'm not sure if this always was the case, but that parameter is on by default now.
In a chain of actions where you might use multiple instances of live.object, the "id 0" might not be sent to all objects. Meaning some will remember "id 0" and others will remember "id xx". So persistent mapping should be turned off in all objects that aren't used to store and recall the ID after loading a set.
This might not be helpful at all, but I recall it tripped me up when working on patches after a hiatus.

As for your dilemma, been there man. I faced it with free devices, so the pressure wasn't there as much to improve, nor was there the time for it. I went to the most extreme length to avoid as much limitations and workarounds as possible, by throwing out like 80% of the patch over the course of several rewrites and it took me years. I'd say that if you have features that don't quite work in the framework of your current version. Take it out and write your next framework with that in mind.

Though if its just a triggering order issue and you happen to use various load objects... Try to update the patch so one live.thisdevice triggers everything. Forget the loading order of the various load objects. You want your patch to load when everything else loaded its stored contents anyway. While you could raise a scenario where you'd want the loadbang before something loads it preset. You could delay whatever preset value triggers at start and trigger it by the single live.thisdevice bang in the order you choose. It makes the patch look messier yet it yields more predictive results.

Good hunting!

- Bjorn

[Stromkraft]

I can report that this issue is a common problem with certain Max For Live devices. For instance, I have this problem with Garcia's AliasClips v2.3.1. Basically I can't undo anything when using this. I have tens of undo steps for each new copy.

With devices like this it would be preferable to have batched undo steps. So if a device makes 20 changes in one operation an undo would undo all 20. I'm not sure if this could be done?

I haven't encountered it with Magnetic nor with Diffuse, but I don't run LFO to these.

I also encounter it in other devices.

[doubleUG]

https://cycling74.com/forums/parameter- ... do-history

[stkr]

With devices like this it would be preferable to have batched undo steps. So if a device makes 20 changes in one operation an undo would undo all 20. I'm not sure if this could be done?

This is a different sort of use case, but yes I totally agree that this feature would be awesome. It is already one of my top requests on the FR list I will be sending Ableton soon

For example, in Transient Machines :: Impact, there is a button to reset (flatten) the 4-band EQ. When you do this Live creates something like 14 undo steps. Such a 'batch' feature would be perfect for this scenario. Of course there are quasi-workarounds, but none of them are ever fully satisfactory and as I learnt with Dub Machines, trying to be too clever with the API leads to heartache.

Edit: I should add that the post doubleUG refers to is again a slightly different and simpler issue.

Anyway, I digress. @hoffman2k, indeed, all Surreal Machines devices only have ONE [live.thisdevice] in them, and loading is managed explicitly. You can see this by opening any of them up. The most complex load system is Magnetic, but it is not actually that complex at all.

Ultimately I was over ambitious in my Magnetic and Diffuse API load systems. I will never do it again

Yes, all three [live.objects] that deal with the 'Repeat' dials in both devices have persistence off, all are id 0-ed after simple questions asked of them on load (or re-enable) only. But alas I still cannot get the 'Repeat' dials to behave within the context of the Live undo queue.

So, I have given up, and will just get rid of this system, but be sure to thoroughly beta test it before it gets publicly updated. As I said before, if anyone wants a risky beta of this, let me know in Surreal Machines support and I'll send you something. Of course I'll make some patches/devices which clearly demonstrate the problems to pass on to Ableton / Cycling.

In general M4L is pretty solid and well behaved these days, and of course is still a fantastic resource. There are just a few edge cases like this that still need ironing out. All Dub Machines users should note that the current releases of the devices are solid, high quality and working well. The issues discussed in this thread only affect the 'Repeat' dials being LFO-ed.

Watch this space for future M4L Dub Machines updates news.

stkr .