Consistent behaviour for sendBankToSynth by avoiding direct updates from user banks - #358
Consistent behaviour for sendBankToSynth by avoiding direct updates from user banks#358salzaverde wants to merge 2 commits into
Conversation
| midikraft::ListInfo info = {activeSynthBankId, ""}; | ||
| auto activeSynthBank = std::dynamic_pointer_cast<midikraft::SynthBank>(patchView_->retrieveListFromDatabase(info)); | ||
| if(!activeSynthBank) | ||
| return; |
There was a problem hiding this comment.
Currently relies on the user having loaded the corresponding synth bank first.
Instead of aborting with an error, we could call "Librarian::startDownloadingAllPatches" for that bank and perform the update in the finished callback. Thoughts?
There was a problem hiding this comment.
if I understand correctly you force a download of the bank first in case it hasn't been downloaded? That would work, my main concern was that you could accidentally overwrite patches in the synth that have never been downloaded, so you'd have no backup of them.
As some synths are really slow to download, the user could be surprised in that a lengthy download operation is started, but I think as this is abortable that's probably ok.
There was a problem hiding this comment.
Right, that's a problem. On a higher level the idea was that this could work similar to Git, where there is a local state which can be modified and then pushed to the synth:
- The synth banks in the database represent the local synth state
- Before sending anything to the synth, the local state needs to be up to date with the remote state - if it's not, you need to import the corresponding bank from the synth first
Since this would be a rather fundamental part of the design, we should probably implement it in a more general place, though.
Then, how we solve the bigger problem of managing deduplication will have an impact, too (didn't find the time to think about it yet but there are some ideas). We could let this simmer for a bit until we have a clearer plan including the bigger picture.
No description provided.