eDRUMin 1.6.1 BETA

[Rob]

https://www.audiofront.net/eDRUMin_Cont ... .6.1.2.zip
https://www.audiofront.net/eDRUMin_Cont ... .6.1.2.zip

Changes in build 2

• Added a confirmation dialog when updating firmware and device has unsaved settings.

[hang12]

Could you have had some unsaved settings that were lost during the update? I suspect that's the issue. I'll add a confirmation dialog in the next build that will show up if the device has unsaved settings.

Huh - uh, maybe this is me still being unaware of all the workings but I thought everything was auto-saved as one goes along...like every 5 minutes? I definitely didn't cut the power or anything after a last parameter change. In fact, when I power down my system (computer, hard drives, audio interface, etc.) the only items that are left on until the next session are the two eDRUMin's. Which is the case for this latest time as well (i.e. updating with the latest beta, both eDRUMin's were continuously powered up regardless of the last shutdown for everything else). Maybe I have an auto-save button disabled?

[Rob]

That would definitely explain things. Anyways, now if auto save is turned off and the settings are dirty, you'll get a confirmation dialog to prevent you from losing settings.

[hang12]

That would definitely explain things. Anyways, now if auto save is turned off and the settings are dirty, you'll get a confirmation dialog to prevent you from losing settings.

Dummy proofing will help immensely! thanks!!

But - I am confused - I just re-booted for curiosity sake and Auto save was indeed off.
Sorry - now that I'm paying attention - having the Save be highlighted in green or not green is sort of uh, a different paradigm - maybe a grayed out SAVE would be more iyf for NOT enabled?, or a separate label 'Auto-Save' with an ON or OFF status button. So many interface paradigms...ugh.

So I had since updated that pad's parameters with Auto-save off, shut down the system, re-booted and now the parameter changes are somehow saved. Both eDRUMin's remained powered. The changes were all made after earlier installing the build 1 beta and updating the firmware. I shut down. Re-booted, and all the changes stuck. huh. would have thought I'd noticed this 'save or not save' issue earlier on.

I have not yet installed the latest you have just posted - with the save change prompt. I will exercise it tomorrow.

[Rob]

It the device doesn't loose power during the reboot process, the settings will remain active. As for the control itself, I'm pretty happy with my implementation as is. I'm always fighting for UI real estate, so having two separate touch-friendly controls is a no go. What I will do is darken the 'Auto' label when auto save is off.
https://www.youtube.com/watch?v=owJZAknNymY

[hang12]

It the device doesn't loose power during the reboot process, the settings will remain active. As for the control itself, I'm pretty happy with my implementation as is. I'm always fighting for UI real estate, so having two separate touch-friendly controls is a no go. What I will do is darken the 'Auto' label when auto save is off.
https://www.youtube.com/watch?v=owJZAknNymY

The link was definitely informative, thanks. I re-scanned the manual searching for 'save' and 'auto' and the video certainly adds more insight. Posting more links like that may be helpful, if you have any.

The Auto-Select is grayed out, which is why I pointed towards that paradigm, but I now understand the Auto-Save is more multi-faceted.
So if I perform (save to) a Device Snapshot, does that (also) do an overall save to each or both device(s), or does it just take the current device settings and store them (each) to computer file(s), but leave the device(s) in an overall unsaved state (independent of each of the latest trigger parameter moves) - in regards to the Auto-Save state? I guess I'm kind of lost in the understanding between Save updates for individual presets, devices, and overall device presets (snapshots).
Since I have multiple eDRUMin's that adds one more layer to the question of what is an 'overall' Save.
For instance but maybe un-related, in a DAW, if you do a Save 'Session' the opened plug-ins are still independent - where a Save stores all of the current underling plug-in parameter states, but doesn't change the individual plug-in's preset memory (unless you go deeper and store a plug-in's state as a snapshot).

At the end of the video you recommend disabling auto-save for specific purposes. If I don't load a lot of presets, but am still trying to dial in optimal settings (just making a lot of little changes), what's the best approach for the unit's memory, and for me? A daily Device preset snapshot for each eDRUMin? thanks!

[Rob]

When you make a device snapshot, the device sends the active settings for each trigger and pedal input to the control application and the control application saves that to a file.

Here are some finer points

• Users presets and device snapshot always contain the active settings as opposed the last saved state.
• Device snapshots only contain settings for a single device.
• If the device was in an unsaved state when you make a snapshot, it should remain in an unsaved state,

I don't think you need to worry about wearing out your devices memory. It's pretty robust.

[monospace]

Control App crashed while unattended.

[Rob]

Thank-you. I'm obviously doing something macOS doesn't like, but I can't tell from that log because it's crashing deep inside the bowels of he OS. I'll post it online and see if some mac guru can give me some insight.

[Rob]

Control App crashed while unattended.

Can you try this build. I've combined two of my very low level threads for handling communicating with devices into one. I can't be sure if this will make a difference, but it's cleaner coding and certainly worth a shot.

https://www.audiofront.net/eDRUMin_Cont ... .6.1.3.zip