AR kit save behavior?

Hey Nauts. Help me understand this, because I find it super confusing: If I save a kit, using the quick save combo or the save command in the kit menu, whatever edits I’ve made are not reflected in the kit if I load or reload it. - UNLESS - the project is also saved. This seems somewhat counter intuitive to me. Why is there a kit save command at all, if the project save command is required to make kit changes persistent? It would seem that just using project save would be sufficient, except that project save does not save the kits!

I actually find the AR structure to be really convoluted. The OT is a breeze for me compared to the AR. Go figure :thinking:

Just kit save should be enough. No need for project save. Are you sure you re not doing any other actions that might throw things off?

Agreed that the AR structure is not the most user friendly, and i m a tech savvy Elektron veteran…

Tested this many many times last night. A kit save alone is doing nothing without project save. I’m on 1.50A, and I don’t remember it being a problem prior to that, but I could be mistaken.

Try this and let me know your results: Make a pattern and associate it to a saved kit. Save the project. Tweak that same kit. Save the kit. Now don’t save the project, but just load the project again. Are the tweaks to the kit being recalled? For me they are not.

Saving a project does not save the kits. If you save kits but not save the project those saved kits won’t reload with the project as they were saved after the last project save… Saved kits without project save after will remain after power cycle but won’t remain after project reload, again because the kits were saved after the last project save so the project reloads to a point before you saved the kits…

3 Likes

Right. Makes sense in that kits are essentially stored with the project, not independent assets on the +drive. But, oh how I wish they were. OS decisions like this (a command appears to execute successfully but then is fundamentally ineffective unless a different command is executed) are always going to seem strange to me. I can groove with plenty of weird Elektron design decisions, but the AR makes me bang my head against the wall. Cant give it up though. Love that sound too much.

2 Likes

Yes I see how that can be confusing. But when you keep in mind that patterns and kits are part of a project and stored in it, then it becomes clear that that project has to get saved before loading another project or reloading the same.

I too lost work before i got the project structure right. I m not even sure i completely understood the sample and sound pool management at this point…

@cuckoomusic did his best at exlaining things in this 1h13min (!!!) tutorial.

Elektron, if such thing is necessary to explain just the data structure of your instrument, then something is wrong :wink:

1 Like

I’ll test a bit when I get home. I was messing around making a new set last night and got caught out with a pattern change/kit reload error.

That surprised me a bit - I kicked myself for making a rookie mistake, but maybe something has changed after all.

BTW I’ve been hammering away on the MnM too, and that thing is brutal if you slip up in workflow. Make sounds, change pattern to test transition, forgot to save, -phhhhffff- there goes all that work!

I actually like the way it is. You save kits when you want them in a permanant state and save the project if you want the saved kits in the project. The way it is you can freely tweak all your kits while jamming and still be able to save the project if you made new patterns you want to keep. If it saved all kits when saving the project and you have tweaked many of them away from what you want them saved as, you’d have to remember what kits you changed and go through and reload them all before saving the project, hoping you got all of them.

Elektron saving structure seems meant for freely tweaking things away from saved point and being able to return to saved point easily. It’s like they’re designed in mind that you’ll be tweaking away and want to return to a saved state instead of wanting to keep every change you make. Great for jamming and messing things up, then you start over at your home base.

1 Like

Yeah, I was thinking about this reasoning, and it definitely has its own logic. The way it’s set up, you can tweak 5 kits, then “save kit” on 2 of them, then save the project, and only the tweaks in the two kits are made permanent. But I’m still having trouble wrapping my head around the concept of a command that by itself does nothing. Wouldn’t it make more sense if “save kit” was instead “save kit to project”? After all, if you’re hitting “save kit”, chances are you want your kit changes to be permanent, right?

It does save the kit to project. But saving the project itself is a separate thing. Most people don t switch projects often. For me it s a workspace in which i create many different tracks. I only save the project now and then to create a back up. Or when i m trying something completely different in another project.

Not following. Like I said, “save kit” does nothing (except making your changes persistent through a restart), unless the project is saved as well. I too only use one project. But- I (re)load it all the time.

Why?

Load the project? Because I like my patterns in a saved “home base” type of state, like Open_Mike mentioned, where I can experiment and make pattern changes, and always be able to go back to my saved default project state.

By not saving them directly to the project you still have a chance to revert to the saved project versions or you can decide to save to a new project slot and have your older versions and the newer ones…

1 Like