It’s a 2018 Mac Mini. Again, this has been a thing that has happened 99.9% of the time only on the Mac OS across various Mac Minis, OS versions, and Chrome browser. Repeated transfer attempts will also sometimes blank out the E1, and then the next time the updated preset transfers OK.
I just put this out there in case anyone else ever runs into the same thing. It’s never completely prevented me from making updates and working on a preset
Martin - ok I loaded up 4.0.0.r. Ran my program to store three different configs to the same table as in this video and it worked fine. But when I reload the preset in the editor (or just repower the EL1), the recalls are all zeroed out.
I put your test print in there and on loading the preset again after running it I see my table data. But doing a recall and assigning to the controls does not change them. The recall in this case is not working even though the table prints ok.
I made the preset “Multi Presist-Recall” public for you to run. Change the 6 dials and then select StoreUser1, do again and StoreUser 2 and again and StoreUser3. Then you can press GetUser1, GetUser2 or GetUser3 to restore/recall the values and works fine. Reload and table seems to be there - but pressing GetUser buttons that should do the recall does not work.
15:22:06.242 ---- START ----
15:22:06.286 lua: – table already persited –
15:22:06.287 lua: {
15:22:06.287 lua: user3 =
15:22:06.287 lua: {
15:22:06.287 lua: macro1 = 127
15:22:06.287 lua: macro5 = 127
15:22:06.288 lua: macro2 = 127
15:22:06.288 lua: macro4 = 127
15:22:06.288 lua: macro6 = 127
15:22:06.288 lua: macro3 = 127
15:22:06.289 lua: }
15:22:06.289 lua: user2 =
15:22:06.289 lua: {
15:22:06.289 lua: macro1 = 57
15:22:06.289 lua: macro5 = 71
15:22:06.290 lua: macro2 = 70
15:22:06.290 lua: macro4 = 59
15:22:06.290 lua: macro6 = 52
15:22:06.290 lua: macro3 = 65
15:22:06.290 lua: }
15:22:06.291 lua: user1 =
15:22:06.291 lua: {
15:22:06.291 lua: macro1 = 13
15:22:06.291 lua: macro5 = 12
15:22:06.291 lua: macro2 = 21
15:22:06.292 lua: macro4 = 17
15:22:06.292 lua: macro6 = 10
15:22:06.292 lua: macro3 = 13
15:22:06.292 lua: }
15:22:06.293 lua: }
I gave it a try and I could see that only one parameter was changed: IR2.
I can see, however, that your preset is using message type NONE for almost everything:
The NONE messages are not stored in the paramaterMap and therefore their state cannot be saved. Note, it is an intentional feature that allows dynamically processed or stateless controls be excluded to prevent data clashes, etc.
the IR2 is VIRTUAL. It seems to be saved and loaded ok.
Ah. I use none because there is no CC or anything else attached to it - it’s a call that directly does something on the target as EaganMatrix uses custom 14-bit CC formats I have to build up internally from CC and PolyAT messages. Maybe I can change it to something that is saved but does not output anything to the target that might confuse it. But perhaps persist/recall is the better way to go anyway.
Martin
I think the problem is that the internal initialization is zeroing things out.
So that initial recall can’t be done unless you know a valid JSON persist is in place.
Is there a way to know the JSON file has been created so you can recall it into your current table?
I tried taking your example and integrating it in, but can’t get it to work.
Thanks
Rich
Rich,
If you use VIRTUAL for the controls you want to save in the snapshot and NONE for those that you do not want to be saved (eg. momentary pads that control logic of the preset), snapshots should work just fine for you.
I have taken a look at your Multi Persist-Recall preset (Electra One App)
I made one adjustment to it and I’d sat it works ok now:
Your Store and Get buttons had values defined for both on (127) and off (0) states. That means that 1) The function will get fired twice on a button tap - for the initial tap and for releasing the button. 2) The function will be called when the preset is initialized - because the buttons are initialized at the off (0) state. Leaving the off value empty resolves both issues.
With this change I am able to use Store user1, Store user2, and Store user3 buttons to capture state of the macro faders. Get user1, Get user2, and Get user3 recalls saved values.
This seems similar to what I reported some days ago about my (large) mixer preset. Uploading sometimes fails. And is successful after a few tries (2-4).
Martin. Thanks! I was wondering why the control was zeroing out the table. When you document the feature please add all these little “gotchas” in there.
Martin - 4.0.0 testing report. Good news. So far, all my 3.6.x Electra One Mk2 presets seem to be running fine under 4.0.0. And I confirm that the persist/recall works fine now that I know to blank out Off value in controls that call the functions.
Did you ever add a function that allows onLoad (or another function) to deterministically reinitialize things after all the “under the hood” initialization is performed?
Great. Most of you (who took part on testing) confirmed that it works. I will prepare an official release and will start with the documentation updates.
yes, I added onReady() function. Check this preset: Preset Initialization, especially the comments in the Lua code.
Ah - onReady() - I saw someone mention that - Fantastic! Thanks.
@martin - trying to implement a basic persist()/recall() thing. If I have a very simple table (in other programming, it would be an array of character strings) like this:
userNames = {}
userNames[0] = "name 1"
userNames[1]="name 2"
and so on
I get an error: invalid key to ‘next’ trying to call persist(userNames)
Is this because it is a 0-based array?
Any chance you could take a second look at this?
@martin, i’ve been running tests. Reducing the size of the data to be saved in the file, recall function works correctly and loads the table in a new session.
However, i can only load 3 program banks (8 kb), because if I try to load 4 banks (11 kb), an error occurs when calling recall. I assume it’s the size limitation, even though I’m using less than 20kb.
i suggest you consider increasing the file size limit, this would give us the opportunity to implement interesting user configurations in presets: hardware program names, preset behaviors, customizable colors…
If it’s not too much to ask, i believe 100/150 kb would be good for storing complex and longer tables with different configurations.
Wow. I was adding a bunch of controls and swapped two banks and all of a sudden controls got renumbered, controls telling duplicates, etc. on a page that has nothing to do with what I was doing and everything is totally screwed up now. I thought control numbers were automatically generated to be unique. Swapping pages didn’t swap it seems. It tried copying things and controls all got messed up (maybe my not realizing what swapping pages operation is. But all the ref #s for controls on my first page got renumbered on me that had nothing to do with the pages I was manipulating.
But the bad thing is if I get out of the editor (I have not saved anything to the Electra yet) if I go back into the editor and select the original preset it does not go back to what it was - it keeps the screwed up configuration. The editor must be storing a configuration and remapping it when I was not expecting it to. Nothing I do in the editor should ever be stored to the actual preset until I load a new version down to the Electra One. I also really need a way to print out a list of all the control numbers as I use them to do things and its impossible to figure out with a many page preset what all the control numbers are. Is there a way to do this.
Maybe this is all operational error - but reference numbers once set for a control should never be reassigned on you on a page not related to one you are changing.
It even renumbered pages with a duplicate page number on me?
I am traveling and have limited access to the computer. The editor has a version control built in:
You should be able to get there previous working version. The ref numbers should never change . I guess something went wrong there. I will review that when I am back home.
Wow - I never noticed this. Thanks. It’s a lifesaving feature! Now I have to determine if what happened to me trying to swap a page with another by dragging one page to another page’s position (I thought it worked like that before) can totally restructure everything for me like it did is a 4.0 bug or not.
I’m using 3.6 and have had this happen to me. I now avoid swapping page locations and do it item by item if I need to rearrange. Have not figured out what causes the control number duplication.
But I’m loving onReady(). This to me was the single biggest issue that needed addressing and it’s so nice to be able to set an initial configuration with ease now. Thanks for adding this important feature!! Can this be called within the program to reinitialize or is it only meant for initial initialization (which is fine).
Hey Martin, not sure if this is getting buried here or not. Were you able to reproduce this?
