Autosave removed Eden settings?

26 replies [Last post]
Tarekith
Offline
Joined: 07/08/2010

Was working on a tune and double tapped the home button to put NS in the background while checking email real quick. When I went back to NS, I got a message that it autosaved for me. Very cool. However it reset the Eden settings in my song, even trying to load one of the many Song saves I have of it will not restore the settings. I was working in the project bank FWIW. Do we have to manually save project bank presets, or are they supposed to be save as part of the song file? The drum pads saved and recalled correctly in this song.

Tarekith
Offline
Joined: 07/08/2010

Looks like just need to save all project bank presets manually, then I'm ok. Would becgrwat if these were saved when you saved the project too.

Blip Interactive
Offline
Joined: 04/05/2010

Yes you do need to manually save any changed preset.

I decided to do it this way because it's the way it's done on most synths - it's very easy to play around with your favourite sound as an experiment and then close the app down, effectively overwriting your favourite preset with some crap one.

Tarekith
Offline
Joined: 07/08/2010

But wouldn't it make sense that 'favorite sounds' would not be project specific, and would be stored in the global banks?

Just trying to make sure I understand this. If I'm in NanoStudio and working on a song, before I close that song or switch to another app (say to take a phone call), I need to save all 4 Eden synths and the drum pads as seperate presets, and then save the song too? Otherwise I'll lose all my settings for the synths, correct? No way to make this a little faster/easier for the end user?

Blip Interactive
Offline
Joined: 04/05/2010

All the current drum pad settings are saved when you save the song so you don't have to do anything special with those.

The golden rule is really : if you make a synth preset you like, write it. This is how my hardware keyboards have worked (not that that's a foolproof argument!).

I didn't want it autosaving a stored preset (project or global) with a 'work in progress' preset when the app was shutdown. It's no problem to add a preset autosave in future if people are after it, but the flipside is that some might get annoyed when their preset has been permanently overwritten.

See how you get on with the workflow for a day or two - then if you've got any better suggestions let me know!

Tarekith
Offline
Joined: 07/08/2010

Thanks for the clarifications, that helps.

In terms of the preset saving, I can see your point too, I don't want to seem like I'm bagging the app. It's really awesome. My only concern is that to me phone apps are all about convenience, having the ability to quickly get ideas down when on the go. So anything that cuts down on 'project/preset management' time is useful. I'm a hardware synth guy myself, so I can see what you mean about not wanting to overwrite something by accident. Personally I tend to always start a new song from scratch though (with new init presets), and my sequences and sounds are closely tied together. I know developers hate to hear it, but a global or song option to "save project presets with song" would be a huge time saver here. If I like a global preset and use it in a song, I'm going to save it to the Project Preset bank anyway, just to make sure everything is self-contained.

Anyway, at least now i know how to not lose my synth settings, which is what's really important. Everything else is working great, thanks a ton for all your work. It's summer here, and I've been dying for a more synth based solution for on the go music making, and this fits the bill perfectly.

skepsis
Offline
Joined: 07/22/2010

From a save space standpoint, the settings of each synth couldn't take up more room than adding a ten second sample to a TRG pad, could it? Maybe a preferences checkbox saying "Save Project Presets with Song" as Tarekith mentioned...

Blip Interactive
Offline
Joined: 04/05/2010

Each preset's tiny (takes up about 400 bytes) but it's not the memory that's the issue, it's more how/where it should be saved in such a way that it doesn't overwrite a preset that you wanted to keep.

The write button is really a confirm, saying 'I'm happy for you to replace the preset held in the bank wth the one in memory'. An autosave scheme would bypass that confirmation, which would run the danger of overwriting a favourite preset at any time.

Another factor is that the default controller positions (eg. XY pads) are also stored in the preset. If it's written without user intervention, these could change which could alter the sound of the preset drastically.

There is an alternative - on a shutdown/startup cycle, restore the modified preset back to 'memory' without actually changing the bank. This solves the problem of putting the synth into the same state as when it was shut down, but still requires to you write the preset at some point when it suits you. I'd prefer this method if anything.

KrisM
Offline
Joined: 07/22/2010

Heh, I was working on a layered up kick drum sound with three Edens last night, got a phone call, and then came back to "BLAT BLAT BLAT BLAT!" instead of "OONCE! OONCE! OONCE! OONCE!"

Your hardsynths weren't capable of their OS being interrupted by an incoming phone call, either ;) I suppose I could always decline the call, save, and then call the person back in the meantime, but ideally I would really, really like to be able to check a text message, take a call, check an email, etc, and when I come back to NanoStudio, the synth sounds I've been working so hard on are still there just as I left them.

Is it possible to have it work that way at least with how Apple impliments "multitasking" ( glorified save states...!)

Blip Interactive
Offline
Joined: 04/05/2010

Yeah that is a bit crap. I'll definitely look at how this can be improved for the first update. In the meantime I'll have to ask you to write the preset (generally to the project bank) as soon you've got something you like. Hardware synths don't take phone calls after all :)

musical.matthew
Offline
Joined: 06/27/2010

"There is an alternative - on a shutdown/startup cycle, restore the modified preset back to 'memory' without actually changing the bank. This solves the problem of putting the synth into the same state as when it was shut down, but still requires to you write the preset at some point when it suits you. I'd prefer this method if anything."

This method sounds good to me. Automatically make an edit buffer when a change is made and save to the buffer any time the preset is changed. It can be written to a permanent bank when editing is complete, but not lost in the meantime if a call comes in.

Blip Interactive
Offline
Joined: 04/05/2010

Yep sounds like the best solution. Ideally I'd need to make it fairly clear on the UI that the preset is modified one (ie. hasn't yet been written) when the project is reloaded.

I also wondered about a dialogue which asks you if you want to write a modified preset when you change to a different one via the +/- buttons. Trouble is that I can see this being annoying in 80% of cases and useful in 20%. If anyone's got any bright ideas about this I'd be interested to hear.

cloverstuck
Offline
Joined: 07/22/2010

There isn't really any existing indication of when a preset is modified, right? Maybe just a little "dirty" marker in the preset LED. I like the idea of a state buffer that gets maintained during app switching, however you go about doing it. Meantime, those of us using the iPod Touch don't have to worry so much because we won't be interrupted by that nasty Phone app. :)

Tarekith
Offline
Joined: 07/08/2010

Stupid phone app always messing up my iPhone..... Oh wait.

I like the edit buffer idea too, my only real issue with the way it is now is that it's not truly coming back from a background state correctly, which is the big draw of iOS4. I think that solves the main issue.

Blip Interactive
Offline
Joined: 04/05/2010

I think what I've got in mind will come back from the 'pre phone call' state correctly - ie. with the preset as you had it, but not yet written to the bank.

Will also try to look at iOS 4 background tasking at some point. I almost had it working for this release, but I had to change a load of code that I already knew was fully tested and decided in the end not to go there.

Tarekith
Offline
Joined: 07/08/2010

Sweet man, thanks for being open to suggestions, really appreciate it.

shannong
Offline
Joined: 06/27/2010

Tarekith - are you *this* Tarekith? http://tarekith.com/misc.html

Blip - I too like the "restore modified preset to memory on app close/restart" approach. It's still a useful fix for iPod/iPad users too, because we get interruptions like IM popups, calendar popups, etc. and we might unthinkingly hit the Home button to go respond...

Re your other question: I think it would be better to go with the 80% rule here. 80% of the time you are hitting the plus button to audition another patch because you just couldn't make the current one fit the context of the song and you're looking for something better. So 80% of the time, you *want* to toss out any changes you might have made, because you gave up on that patch for this go. If it's a 20% case where you think "gee I like this sound I've created, so I want to save it, but not for this song", you can always do a manual save to bank at that point before you go looking for a different patch.

So my vote is don't change the current behavior of the patch selector.

Tarekith
Offline
Joined: 07/08/2010

Yes, I'm THAT Tarekith.

Please don't hold it against me :)

shannong
Offline
Joined: 06/27/2010

I won't. Instead, I'll (virtually) shake your hand and give you a hearty "thanks" for all the great information you've shared. I've even quoted you and referenced your site in some wiki articles I've written for the Korg M3 and KARMA community:

http://karma-lab.wikidot.com/misc:setting-gain-levels-for-recording-and-...

http://karma-lab.wikidot.com/misc:choosing-a-sampling-frequency

Tarekith
Offline
Joined: 07/08/2010

Nice, thanks!

musical.matthew
Offline
Joined: 06/27/2010

an idea...

"Yep sounds like the best solution. Ideally I'd need to make it fairly clear on the UI that the preset is modified one (ie. hasn't yet been written) when the project is reloaded.

I also wondered about a dialogue which asks you if you want to write a modified preset when you change to a different one via the +/- buttons. Trouble is that I can see this being annoying in 80% of cases and useful in 20%. If anyone's got any bright ideas about this I'd be interested to hear."

Instead of doing this, why not just have an edit buffer for each preset that is modified while working on a project. That way presets can be changed and if you go back to the one you were working on you can get back to where you were even if you hadn't decided to write it yet. Since you said the way things are were more because of UI than memory it seems like this would work. The UI would just indicate you're in the modified version of the preset and provide A/B comparison.

This method would be especially nice if you try tweaking some global / factory presets but haven't decided for sure whether they will get included in the project or not. You can wait to write your changes to the project bank until you have decided for sure to include them in the project.

Blip Interactive
Offline
Joined: 04/05/2010

Good man - you've actually just reminded me of the original idea I had for the way the compare button should work but never got round to changing. It's like your idea but it only has a buffer for one preset (not each).

Currently the 'compare' buffer is cleared when you change to a new preset. But if I didn't do this, then the compare would always take you back to the last one you edited. So for example:

- You make some edits to preset 10
- You change to preset 11 and then think, shit, that was the best patch I will make in my life, I'm think I'm going to cry
- You tap compare
- You're back at the modified preset 10 and peace and harmony are restored

No UI changes need either. What do you reckon?

shannong
Offline
Joined: 06/27/2010

Re Blip's "what do you reckon?"... (which reminds me, do you prefer being called "Blip" or "Matt" here on the forums, lol?)

I really like the way that "Compare" always shows me what the last-written state of a preset sounds like. I use it a lot when tweaking a preset to hear the original sound as a reference point. So if you change its behavior as proposed above, what happens when you change to preset 11 and start making changes? Will the underlying code know to replace the buffer (that had 10's changes at first) with the last-written version of preset 11?

A lot of times I might start with preset 10, make a bunch of changes, still not like anything I've done, and go looking for a different preset instead. In this case, I don't care at all about the changes I made to preset 10. If I'd liked anything I'd come up with while tweaking 10, I'd have written it back to 10 or over to some new preset slot before moving on in search of some other preset to use or tweak.

Blip Interactive
Offline
Joined: 04/05/2010

I was thinking (in the above example) that as soon as you make an edit to preset 11, preset 10's changes will get lost. After that, the compare button takes you between the modified and unmodified versions of preset 11 as before.

Don't really mind Blip or Matt!

musical.matthew
Offline
Joined: 06/27/2010

"- You make some edits to preset 10
- You change to preset 11 and then think, shit, that was the best patch I will make in my life, I'm think I'm going to cry
- You tap compare
- You're back at the modified preset 10 and peace and harmony are restored"

This is close, but not quite what I had in mind. It would make the most sense to me like this:

- You make some edits to preset 10
- You change to preset 11 and then think, shit, that was the best patch I will make in my life, I'm think I'm going to cry
- You change back to preset 10
- You're back at the modified preset 10 and peace and harmony are restored
- You tap compare
- You're back at the last saved version of preset 10

This preserves 2 things. First, if you make a tweak to preset 11 before you think " that was the best patch I will make in my life, I'm think I'm going to cry" you will still be able to get back to it. Second, compare seems to intuitively compare an edit of 1 version of a preset to the saved version of the same preset. You're likely to want to be able to do this. Comparing an edit of 10 with the saved version of 11 doesn't really make sense to me. If I want to do this I will change the preset back and forth.

What do you think of this? It requires a little bit more memory but any UI changes would be minimal and it offers a lot of flexibility.

Blip Interactive
Offline
Joined: 04/05/2010

> Comparing an edit of 10 with the saved version of 11 doesn't really make sense to me. If I want to do this I will change the preset back and forth.

I was thinking that it would jump back to preset 10 at this point.

musical.matthew
Offline
Joined: 06/27/2010

Still doesn't seem intuitive to me that way but I'm just one guy with one opinion. Others might think differently...