Runtime's behavior with stored data

    Jan 16 2013 | 12:44 am
    Hello, I wonder if this is a limitation with Max Runtime or I am doing something wrong: I'd need a patch in runtime to remember specific settings of a [function] object (function is nice for envelopes and seemed better that itable in this specific case). I have a [pattr] bound to it, but it won't remember any changes. Truth is also that a simple change won't activate the dirty bit flag (or whatever the terminology should be) I don't need much with my [function] object, just to fine tune its envelope over time. Still I'd need it to save the last state. all suggestions welcome, carloskleiber

    • Jan 16 2013 | 8:29 am
      There are three possible schemes: to open a patch with runtime, to create a collective, or to build a standalone. None of these allow for modification of the patch, so any modifiable data should be saved separately. In this case it should be the pattrstorage writing changes to a file. This file will have to accompany the patch/collective/standalone. More advanced methods are to store it inside a standalone or in the preferences folder of a standalone. Make sure to hide any existing pattrstorage preset file upon creating a collective/standalone, otherwise it will become a unmodifiable part of it.
    • Jan 17 2013 | 10:50 pm
      Hello, thank you for the answer, I guess I'll try to use static data in the Runtime - all I need is an envelope, once it is fine I won't touch it anymore, so this case doesn't justify the extra complexity of external files. If I check parameter mode in [pattr] it actually remembers the data. What I want to do however is to first find the right settings for a similar envelope in a M4L patch. Once the envelope is fine I'll copy the data and paste it to the patch that is to become the runtime. If pattr is in parameter mode it can open that kind of a "client window", where the Initial Value can be copied from. The problem is that even if I paste it to the Initial Value slot of my destination pattr, it won't overwrite the data itself on initialization. Sorry for the annoying explanations, I guess it doesn't make much sense for you guys owning MaxMSP. I only have M4L and make my runtimes for some cases.