Jascha Narveson

I've been reading about this and found posts like this one:

https://cycling74.com/forums/parameter-modulation-without-adding-to-undo-history/

I have what I *think* is a different problem - please correct me if I'm wrong!

- a M4L device with a visible live.numbox called "the_num" (for example) that has a frequently changing value in it

- I want to have "the_num" visible to other M4L devices like Max api param2param so I can map "the_num" to many other things in my Live set

- I don't want "the_num" to write to the undo history, but if I set it to "hidden" then I can't access it with other Max api devices

- a M4L device with a visible live.numbox called "the_num" (for example) that has a frequently changing value in it
- I want to have "the_num" visible to other M4L devices like Max api param2param so I can map "the_num" to many other things in my Live set
- I don't want "the_num" to write to the undo history, but if I set it to "hidden" then I can't access it with other Max api devices

make-a-parameter-visible-for-mapping-but-without-adding-to-undo-history

If you're using a live.remote (which I believe the device you mentioned does) to control the_num, you won't write to the undo history.

If you're using a live.remote (which I believe the device you mentioned does) to control the_num, you won't write to the undo history.
What have you tried that didn't work?


In this case, the M4L device is doing this:

incoming MIDI data ---> stripping out info ---> updating "the_num" live.numbox with a MIDI parameter

Could you tell me how I'd use live.remote to fix this? I still want a visible number I can choose with the Max api param2param device and map to another value elsewhere...

Could you tell me how I'd use live.remote to fix this?  I still want a visible number I can choose with the Max api param2param device and map to another value elsewhere...

If you want the live.numbox to be modified from within your patch, also be exposed to the API, AND not update the undo history, you should figure out another way to do what you're after, because you won't be able to satisfy all of those conditions.

Why don't you forget the param2param device, and just point the data generated in your patch to the other parameter? Then you wouldn't have to have 'the_num' be exposed to the API, removing the undo history issue.

If you want the live.numbox to be modified from within your patch, also be exposed to the API, AND not update the undo history, you should figure out another way to do what you're after, because you won't be able to satisfy all of those conditions. 

Why don't you forget the param2param device, and just point the data generated in your patch to the other parameter? Then you wouldn't have to have 'the_num' be exposed to the API, removing the undo history issue.


Ok - that sounds like the way to do it, indeed.

Is there a way to point the data from inside my device but set up a set of menus à-la param2param to choose the Live path from within my device so I wouldn't have to hardwire the path in the actual patch? I'm a bit new to the Live/M4L mixed environment - is there an api abstraction I could just drop in to get the menus I want?

Ok - that sounds like the way to do it, indeed.  

Is there a way to point the data from inside my device but set up a set of menus à-la param2param to choose the Live path from within my device so I wouldn't have to hardwire the path in the actual patch?  I'm a bit new to the Live/M4L mixed environment - is there an api abstraction I could just drop in to get the menus I want?

Just copy the stuff from the Param2param, or the LFO. Basically any of the parameter modulation devices that included will have what you need (assuming what you need is a menu based API navigator that can connect your data to parameters).

Make a parameter visible for mapping BUT without adding to undo history