strange undo/automation bhvr w Faint Response true panning

[re:dream]

I believe there are some well known issues relating to undo history of M4L devices in Live

This is one that is really bothersome.

I now have the 'faint response' true panning M4L device installed as a matter of course in my default set.

This device appears to record its own automation behaviour without any prompt from me

- I will sometimes have an automation event related to the parameter PanR on this device in my undo history even when I am not changing any panning parameters

- even more irritatingly, when I am recording automation on some other parameter in Push, the true panning device sometimes grabs control of the automation recording: when I try to look at the automation as I am recording, suddenly the clip view changes to the panning automation of the M4L clip

Any suggestions would be appreciated.

[regretfullySaid]

I opened it up once and it has 2 places where it bangs on a regular basis to make sure it has the id if the track it's on. If you click on any live.objects/observers and look in the inspector, at the bottom you'll see a checkbox for something I can't remembr what it's called but I think it has parameter in the name. If you uncheck this box then it win't write to the undo list. This might solve the problem.

[re:dream]

I have no idea what that means. Can you explain to me in little words please? I just use M4L, I have no knowledge of how to edit the devices.

[regretfullySaid]

Open up the patch and look for objects called live.objects and live.observers. Click each one and open up the Inspector (cmd/ctrl-I) and scroll to look at the bottom and you'll see something that's probably checked, uncheck it.

[re:dream]

I can tell you are radically overestimating my knowledge of Max for Live and Max. I think I know what you mean by 'open up the patch' (I press the edit button, right?) have no idea how to look for objects

I unchecked 'presentation' and got a very pretty picture of what I take to be the insides of the device, with boxes and lines - but nothing called a live.observer or anything like that.

[regretfullySaid]

Ah, you probably need to look inside a sub-patch (a patch inside the main patch; you can have patches inside patches, like Inception!).

You're doing fine. All those things you see the wires connected to are objects. You need to look for ones that start with 'p', like 'p Pan'. That means it's a sub-patch. If you hold cmd/ctrl and double click on it, it will open up and you can see the contents inside of it, then look for 'live.object'/'live.observer'. Lather, rinse, repeat.

It's not that big a patch so it shouldn't be Wonderland. And when you got a half-hour sometime do the beginner tutorial from the Max help to learn the basics.

[regretfullySaid]

Ok so one sub-patch is called 'getTrackPanValue' that has a live.observer in it, and the other one with the live.object in it is called 'trackId'. When you find them click on them and open the Inspector and scroll to the bottom and you'll see 'Use Persistent Mapping'. It might be checked. Mine isn't but I may have already unchecked it and saved it for the sole reason because when 'Use Persistent Mapping' is checked, it will write to the undo, so I make it a habit to uncheck them.

[re:dream]

That was very helpful.

But in my case persistent mapping was unchecked as well.


So there must be something else inside the patch that is causing it, I guess.

Thanks for the help, though, I learned something today!

[regretfullySaid]

Yeah, that sucks though, I was hoping that was the problem. Will investigate later.

[re:dream]

I opend everything and closed it without saving... and then one channel of the device was dead. So I had to download a fresh install. I clearly have lot to learn!

I have reported the issue to the developer.

[ssrmpc]

Dear all....

My name is Marc a.k.a. Faint Response and obviously you have had an issue with the device I created.

Due to an accident I write to you a little late. I have to confess that I did not fully understand the complete picture but I might have a solution that solves most of the problems.

Regarding to what I understood everything is related to the device pan knobs that were
A) active
B) sent automation data
C) got automated

As a matter of fact the knobs should be a "visual representation" only and reflect the track's pan knob. The problems you had were clearly introduced by myself since the knobs were not correctly set up. The new version 1.6 has inactive device pan knobs that should not store and/or send automation data. In case you need to automate the panning you should use the tracks pan knob.

In case you do not agree and/or have amendments, please let me know..... until then I hope the new version solves the problems.

Kind regards
-Marc

[regretfullySaid]

Oh ok, just to understand in case other people don't want the same thing to happen to their own or other creations, it was the live.dials that were adding to the undo? Was it just an issue of switching Automated and Stored to Stored only?

Hope the accident wasn't too bad and thanks for the update/clarification.

[re:dream]

Thank you Marc! V 1.6 looks like it is working fine
Much appreciated

[ssrmpc]

Dear all...

I created a new version 1.7 that makes sure that every 250ms the calculated stereo pan is promoted. Depending on the M4L version that was not always the case.

http://www.maxforlive.com/library/devic ... an-enabler

[re:dream]

I see a new version is up.

One question: how much latency does this introduce?