pattrstorage issue
Having some issues with pattrstorage, I want some native max objects to be stored in pattrstorage and saved with the m4l device, that works fine using pattr to bind the objects.
In 'The Limitations of Max for Live' document on C74 with regards to devices using pattrstorage, it states "it can be saved in presets, set as an initial value or stored in the Set" does this mean presets as in Live presets?
I want the max objects to be 'hidden', but still appear in pattrstorage, but if saving a preset of the m4l device in Live, then they are saved with that preset.
I can see the parameters inside pattrstorage when in the m4l device, the are showing, but just not saving as a Live preset of the device.
Is this even possible?
have you got the @parameter_enable 1 attribute set on your pattrstorage? if so, you should be able to save in Live presets
Hey Lee, yep that is all set up correctly (I think) doesn't work, have tried all the attributes in different combinations for pattrstorage, still no luck. As I said, the pattr objects feeding it are hidden (and need to be for the patch I'm doing) but they do show up in pattrstorage, and when in Live, I can see the values changing in there as they should, save the preset, try recalling it, no joy.
I'm hoping it's something stupid that I've missed. I'f you want to have quick look, file attached, no worries if not.
cool, will have a look this eve...
Hi Mark,
Params are not stored when they are hidden - well because Max will hide them from Live. AFAIK the only option is to select "Stored Only". The will be not accessible via automation but can be stored.
Jan
Thanks Jan, thought as much, the reason I'm trying to hide them is I have a 'randomise all' feature in my device, and don't want this to fill Live's undo history, this would have been an easy solution, as I do need all parameters to be stored as presets in Live. I have made a hack that uses a bound pattr for each 'randomisable' parameter which can have it's 'parameter mode enabled' switched off temporarily when randomising, which can't be done with .live objects. Thanks for the help.
Live and it's undo history.... if there's one thing I wish we could turn off, it's that....
+1!!!!!!! That would be FANTASTIC!!!!
Agreed, feels like a very unnecessary pain to work around.
I don't think it's possible on the Ableton side unfortunately - as you can imagine it has been asked for alot. Had conversations with them and it's not as simple as it seems...
@MARKMSB I am surprised that dynamically enabling/disabling parameter mode works for pattr. Did you test your code. To my knowledge Live Params are loaded on device load and remain static from there on. Did you test your patch?
@JAN yes works fine, I have the pattr set to 'stored only' and am toggling it's parameter_enable attribute dynamically in the M4L device to stop it going into live's undo, haven't checked what happens if when set to automatable and stored, I am aware of issues there though from using number boxes who's range changes dynamically when using Push etc. Have attached an example of the working hack
@MARKMSB I see - but in the device you posted the live.numbox connected to the pattr has param-mode "Hidden" not "Stored Only" (despite the comment). When set to "Stored Only" the trick doesn't work anymore. Technically that makes your live.numbox behave like a Max [number] / [flonum] object. Live preset storing works, because the value of the [pattr] is stored. I am tempted to say this is a flaw in the implementation of pattr and you might no be able to rely on that behavior in the future.
I say that because of the following behavior: When parameter_enabled is set to 0 and the value of the [live.numbox] changes the Live Set shows the dirty flag as if the Live History would have changed though in fact it has not. After saving the Live Set once the dirty flag is not set anymore. It would be very interesting to hear the opinion of support regarding this scenario.....
Hi @JAN, my mistake, yes the comment should read the live.numbox is hidden, it is the pattr that is stored only but has switchable parameter_enable, it works fine here, for what I need, but I would rather there be a more elegant way of achieving it. I've not experimented with the dirty flag, to be honest, I'm not sure what that does. I have saved the live set, carried on using it, tried to run it under different conditions etc, still seems to work, I am little cautious about releasing the device with this in though.
@Jan - I believe something has changed at some point - scripting live.* objects into existence works with pattr now aswell - I'm sure this didn't use to be the case - in fact, it seems that only loading patchers is still problematic... I'm still investigating this area though as I'm still not convinced
@MARKMSB
I am little cautious about releasing the device with this in though
that's what i had in mind, too. You probably want to ask support if "parameter_enabled" is public on purpose for Max objects or if this is a design flaw. Well the real question is: will it stay that way in the future, because as practical as it is in your case it doesn't appear to be coherent to me: All the other parameters in that section are hidden. BTW, if you use [numbox/flonum] instead of live numbox you can skip the extra pattr object (as you are anyhow not exposing the param for automation, it's merely a design question).
@JAN are there any benefits to using the 'parameter_enable' attribute directly with for example native max number/flonum rather than using a pattr, other than using less objects? quite a lot of the UI stuff is native max objects, but i'm using a patcher with all the pattr's for the random function, purely for tidiness, but could easily adapt it.
@MARKMSB I don't see any other benefits besides having a few object's less in your patch.
I'm coming late to this discussion, trying to understand if something isn't working properly. parameter_enable for Max object is 100% by design. Adding new "Automate" parameters, or changing their secret _parameter_(attributes), to a Max for Live device _will_ cause problems. New "Hidden" parameters shouldn't be an issue, and "Stored Only" is probably OK, too, but not encouraged.
Best, Jeremy
Thank you for the clarification @JEREMY! If I understand you right you right, temporarily setting "parameter_enable" to 0 on a "Stored Only" param/object is a viable workaround for temporarily hiding a parameter from the Live undo history. Could you elaborate what you meant by "it is not encouraged"? Do you see any possible problems with that, or is there something that should be taken into account (i.e. making sure that the parameter is enabled before a Live Set is closed?).
Can you think about any other solution to save a Parameter with the Live set but exclude it from the Live undo history? ... and last, is there a possibility that there will be an "official" feature in the future to exclude Live params from undo?
THX, Jan
All good stuff, and interested to know answer to Jan's questions also...
By "Adding new "Automate" parameters", do you mean scripting them into existence? They're not automatable it seems, but that said, are there any other problems with doing it? (i'm quite happy to not have them automatable)
The ability to exclude stored parameters from undo is a long-standing feature request from many Live users, and from C74, but hasn't materialized yet. There's a technical feature on the Live side which makes implementing this ourselves impossible, unfortunately. I am not sure if there's a plan to add this to Live in the future.
As for eliminating stuff from the undo history, I think that temporarily disabling Parameter Enable sounds like a horrible idea. :-) It's a hack, and has some amount of overhead (there's a lot involved in enabling the parameter features for an object). Also I would never do that for Automated parameters.
However, I can't think of a better solution to this problem at the moment. Sorry!
Jeremy
Thanks for the clarification Jeremy, I think i'll take out the 'randomise all' parameter, unless there are any cool alternatives? Thanks
Hey everyone, I just stumbled upon this thread while trying to figure this out myself.
I’m working on a simple timer patch, and I want it to store time from one session, and when it is re-opened, pick up where it left off.
If I use a [live.numbox], each bang of the counter gets added to lives undo history... if I set the parameter visibility to hidden.... the value doesn't get saved with the live set.
I thought one way to do it would be to have the counter feeding into a regular max msp numbox with a [prepend set] and then having that connected to a [live.numbox]. Then I'd have a [closebang] on the integer, so when the set is closed that number gets banged to the [live.numbox] and get saved - but unfortunately it looks like [closebang] doesn't work with max for live.
I also tried to use a regular integer box with a pattr, but I get the same problem of having to have it set to hidden if I want it to not add to the undo history.
The only solution I can see that’s not a huge hack is to just have a “check in” button that bangs the value from a hidden live.numbox to one that is stored, but I’d prefer to have no user input with this device.
Can anyone think of a better way to do this? Here’s the patch with the closebang method
Apologies, here's the code.
This is the same problem, more or less. Closebang does work in a Max for Live device, but it comes too late in the device destruction process to be of use here.
Just to be really clear:
@JEREMY
"The ability to exclude stored parameters from undo is a long-standing feature request from many Live users, and from C74, but hasn’t materialized yet."
Does "stored parameters" in this case also means: "any kind of stored data within the Live set (done by your m4l device)"?
Or better:
is there ANY way to save, let's say, an integer with the Live set, while excluding it from the Live undo (bypassing the parameter system)?
@Yurki -- no, there isn't at this time. Everything which isn't hidden is part of Live's undo system.
Thanks!
Meanwhile I just noticed something odd:
I have a pattrstorage storing around 100 parameters and a live.number attached to the pattrstorage
to recall presets. When I recall a preset in the interface with my mouse, I notice that all 100 parameters
are changed under one undo event. But when I automate live.number in Live, all 100 parameters are recalled
separately adding 100 long undo history events which also glitches the audio for a moment.
It makes me wonder how that is even possible, given the limitations of the Live undo system.
Is it possible to recall a pattrstorage preset with automation the same way?
I'm thinking if I can make an acceptable workaround with a dict in parameter mode storing 100 parameters * amountOfPresets...
...and no solution for this Live undo problem so far, in 2018???
+ 1
@JEREMY
Any news on this topic since Live 10 / Max 8?
Sorry, there's nothing new to report. Please file a feature/support request with Ableton.
Well some news live now stores undo history.....an eye opener! after a few session of furious knob twiddling Iive had amassed 50gb+ of undo data filled my drive and crashed out among the files were some 4gb+ that sublime failed to open.