zion

Working on a m4l device that I am building, something is going wrong and strange with the 

 option on every Live set that I drag my device to 

 a simple action I have to hold cntr+z a few seconds and going through many sub-actions, 

Screenshot_20211212-232831_WhatsApp.jpg

Working on a m4l device that I am building, something is going wrong and strange with the undo option on every Live set that I drag my device to 
  To undo a simple action I have to hold cntr+z a few seconds and going through many sub-actions, re-undo is not an option..
 From the Edit menu I see - Undo change "button" all the time,


Working on a m4l device that I am building, something is going wrong and strange with the undo option on every Live set that I drag my devic

live-'undo'-going-wrong-when-working-with-m4l

We'll need more information about your patch in order to really help you.

My guess is that you are using [live.object] to modify the value of a control. This adds actions to the Live undo list. [live.remote~] would perhaps be preferable.

https://docs.cycling74.com/max8/vignettes/live_api#Automating_device_parameters_at_signal_rate

We'll need more information about your patch in order to really help you. 

My guess is that you are using [live.object] to modify the value of a control. This adds actions to the Live undo list. [live.remote~] would perhaps be preferable.
https://docs.cycling74.com/max8/vignettes/live_api#Automating_device_parameters_at_signal_rate 


I really apologize for the time it took me do answer! I made a few tests and came with a short clip that minimize and spot the M4L+Live undo problem. please take a look

The patch attached as well as the link for my short clip

Untitlenew1.amxd

https://drive.google.com/file/d/1THn9Ciqat2tRvS4NeDSEXP_BTMCFFJJ2/view?usp=sharing

Hello there 
I really apologize for the time it took me do answer! I made a few tests and came with a short clip that minimize and spot the M4L+Live undo problem. please take a look
The patch attached as well as the link for my short clip

https://drive.google.com/file/d/1THn9Ciqat2tRvS4NeDSEXP_BTMCFFJJ2/view?usp=sharing
Thanks!

Ok, I got around watching your demo. So what happens is : when your clip is playing and sending MIDI notes into your M4L device, it updates the [preset] box. And that adds an action in the undo menu.

Addind the [change] object in the line will help but still create undo actions when a new note is played.

If you explain what you are trying to accomplish here, we can discuss ways of implementing it without creating undo actions. Why are you trying to update presets with MIDI notes?

Ok, I got around watching your demo. So what happens is : when your clip is playing and sending MIDI notes into your M4L device, it updates the [preset] box. And that adds an action in the undo menu. 

1. you wrote that midi notes are getting into M4L device and '

updates the [preset] box. And that adds an action in the undo menu

' - why? why would a change of preset would count into the undo list and how can I avoid Live from doing it? 

For example I red (see link bellow)that changing

would eliminate it from the Live undo list - page 22 here

https://maxforlive.com/resources/M4L-Production-Guidelines.pdf

I did that in any object that I don't need the automation option in my patch (because changing the 

 field, I think because it is not M4l object.. and again if it is not a M4l why does Live save it and count it ? will it do the same to a Max [float] num box?

2. About the [change] suggestion, I do have it in my original patch - from different reasons, but it is not suppose to help to much, because midi notes come and change all the time..

3. The reason midi notes in my original patch call preset numbers (and then bang a play button..) is that each preset holds two locators that represent a slice of a wave in a [buffer~] to be played now.

4. I captured our issue to the small patch that I sent and I don't want to bother you with a hole patch but please watch this movie that demonstrate it - it works beautiful but still create sometime a large unwanted number of Undo events.

I am happy to get your replay!
1. you wrote that midi notes are getting into M4L device and 'updates the [preset] box. And that adds an action in the undo menu' - why?  why would a change of preset would count into the undo list and how can I avoid Live from doing it? 
For example I red (see link bellow)that changing 'parameter visibility' attribute of an object, from 'Automated and store' to 'Hidden' would eliminate it from the Live undo list  - page 22 here
https://maxforlive.com/resources/M4L-Production-Guidelines.pdf

I did that in any object that I don't need the automation option in my patch (because changing the parameter visibility from 'Automated and store' to 'Hidden' would avoid automation from the object) but - to the [preset] object there is no  parameter visibility field, I think because it is not M4l object.. and again if it is not a M4l why does Live save it and count it ? will it do the same to a Max [float] num box?

3. The reason midi notes in my original patch call preset numbers (and then bang a play button..) is that each preset holds two locators that represent a slice of a wave in a [buffer~] to be played now.

4. I captured our issue to the small patch that I sent and I don't want to bother you with a hole patch but please watch this movie that demonstrate it - it works beautiful but still  create sometime a large unwanted number of Undo events.
https://youtu.be/UJ52dZNsmcc
Thanks!!


What you are saying is right : with M4L objects, we can change the parameter visibility to avoid undos.

[preset] kind of is an exception in the realm of Max for Live. It's a standard Max object but it is controlled by the Max for Live API. It has no "parameter visibility" option in its inspector. Perhaps that could be a feature request, but I'm not the one to talk to. I'm solely a Max user trying to help another Max user...

If your goal is to store start and end locations of a buffer~, you could use [coll] to store and recall those. And [coll] wouldn't trigger an undo action...

What you are saying is right : with M4L objects, we can change the parameter visibility to avoid undos. 

[preset] kind of is an exception in the realm of Max for Live. It's a standard Max object but it is controlled by the Max for Live API. It has no "parameter visibility" option in its inspector.  Perhaps that could be a feature request, but I'm not the one to talk to. I'm solely a Max user trying to help another Max user...

If your goal is to store start and end locations of a buffer~, you could use [coll] to store and recall those. And [coll] wouldn't trigger an undo action... 

The [preset] stores locators of [buffer~] slices as well as a path to changing audio files.. So it is becoming complicated.. But I did thought of using coll, the thing is that I really need the visual UI of the [preset] and furthermore I like the fact that 

saves its content automatically when saving the set.. but then again the price is getting into the undo list.. So it is a conflict.. 

I asked myself what is the Live equivalent for Max [Preset], maybe it should be, or at least adding "parameter visibility" option in its inspector, like you suggested.. And how, where and to whom can someone make a feature request ?

The [preset] stores locators of [buffer~] slices as well as a path to changing audio files.. So it is becoming complicated.. But I did thought of using coll, the thing is that I really need the visual UI of the [preset] and furthermore I like the fact that Live saves its content automatically when saving the set.. but then again the price is getting into the undo list.. So it is a conflict.. 
I asked myself what is the Live equivalent for Max [Preset], maybe it should be, or at least adding  "parameter visibility" option in its inspector, like you suggested.. And how, where and to whom can someone make a feature request ?
Thank you for your answers! (;

Live 'Undo' going wrong when working with m4l