[sciurius]

Exactly. And that is why I try to fit this feature as much as possible within the existing concepts so it will not get in the way of the 95% while 100% of the 1% (i.e., me ) can benefit.

[Zubersoft]

Actually, that's not what happens on restore. The backup contains all song files, and when you restore, it doesn't know what your intentions are. You may have done a factory reset of the tablet, and you do want those files restored. Or someone else may be restoring your backup, so the files need to be extracted. By default, the files are restored into the selected storage location in the MS Pro settings. If you select "Original File Locations", then it will restore the files back to the original file location if possible. If that location is not accessible, it will restore the file into the storage location.

So, as for your two enhancements, I think parts of #2 are already addressed, as the default behavior is b), and a) is what happens if you change the restore destination. c and d are enhancements that could be offered if a lot of people manage their libraries themselves and this would be useful to them. As for #1, if you don't want MS Pro backing up your files, I would suggest that you shouldn't even bother with creating a .msb file. Just make sure the "Expose Database File" setting is checked, and then you can backup just the database file yourself, which is all you would care about. If you want a hybrid backup file that contains some files but not others based upon whether the files resided in the MS Pro storage location or an external storage location, I could certainly do that, but I think it's start creating scenarios where people can easily shoot themselves in the foot. I used to provide an option in the original MS Pro to not back up files in the .msb file, and then I started getting emails from users who were confused when they restored their backup and didn't have any of the files from their library. If you give users the ability to do bad things, some will inevitably do it...

Before I make any changes in this regard, I need a lot of buy in from people as I don't want to change the way backup files work without some amount of consensus. If we are just talking about adding an option to determine whether external files are backed up (files outside the MS Pro storage location), that might be simple enough that people will want it and it will be pretty harmless so long as people understand the impact of not backing up all their files.

Mike

[sciurius]

By default, the files are restored into the selected storage location in the MS Pro settings. If you select "Original File Locations", then it will restore the files back to the original file location if possible. If that location is not accessible, it will restore the file into the storage location.

Clear.  
Do you use the selected storage location from the current settings, or from the freshly restored settings?

As for #1, if you don't want MS Pro backing up your files, I would suggest that you shouldn't even bother with creating a .msb file. Just make sure the "Expose Database File" setting is checked, and then you can backup just the database file yourself, which is all you would care about.

Unfortunately that's not quite true, since you'd be missing the settings. As of 1.2.x, the settings are included in the .msb, that's why I try to fold my ideas around the .msb.

... but I think it's start creating scenarios where people can easily shoot themselves in the foot. [...] If you give users the ability to do bad things, some will inevitably do it...

Unfortunately, that is very true.

If we are just talking about adding an option to determine whether external files are backed up (files outside the MS Pro storage location), that might be simple enough that people will want it and it will be pretty harmless so long as people understand the impact of not backing up all their files.

This would be a good start. We can assume that users who choose to manage the songs themselves are, indeed, capable of managing the songs themselves.

[sciurius]

On second thought, there may be a much easier and foolproof appraoch.

When I start MSPro for the very first time, it will create a default database + settings in the default location. On my tablet that would be /data/data/com.zubersoft.mobilesheetspro .

Suppose you could change this behaviour slightly:

• Upon the initial run, proceed as normal. Register the actual default location in a separate settings file (e.g., location.xml).
  
• On subsequent runs, use this location.xml to get the actual location.
  
• Provide a means to start MSPro bypassing this, and have it ask whether to use the last used location, create a new one, or use a location previously used. Register the last location used in location.xml.
  

This would be relatively easy to implement and cleanly separated from the rest of the MSPro functionality. It wouldn't make a difference to ordinary users (no foot shooting).

[jagny42]

I think this concept has entered the arena of the top 1%ers. If separate dbs are offered they probably need to stay as close as possible to the way the main db works as is feasible with few, if any, options. There are too many 'fiddlers' around thinking they understand options and they end up hosing their installation and losing data.
Maybe it would be better if a capability to import a database were included for those who have the expertise to use one, with no capability to manage/modify it beyond what's already available in MSP. Maybe that's what is being proposed for all I know. Or this whole capability could be developed as in-app purchase as it seems to be fraught with possibilities for the competent and danger for those with lessor abilities [95 % of us ].

I agree.  I like your way of thinking!

[Zubersoft]

That approach is very similar in nature to just letting the user pick a database file to use as the active library. Unfortunately, there is a little bit of a snag if I try to provide different application settings per database. Google completely abstracted access to these files, so that you aren't really supposed to know where they are kept. You just go through their SharedPreferences classes and get/set values. That means that I can't easily change where these settings files are stored. This is true regardless of the approach I use for providing separate databases. If I wanted to keep separate settings for each database, one approach would be to copy all of the settings files into a directory that has to live at the same level as the database file, so that when you switch to that database file, I overwrite the current application settings with those ones. This doesn't work well if one of your databases is the one in the default location though, as those settings would be overwritten, so I would also have to automatically back up those settings when you switch away from the default location. Ultimately, I don't think all of that really matters though, as why would you want different settings per database? Wouldn't you want the same settings applied to all of your databases?

The simplest thing in my mind is to provide an option to select a different database file, and if some of the settings are important, these can be saved alongside the database file. I think each of these database files should be uniquely named so maybe I would have to think about how to handle that. As new databases are set up, the user can easily switch between existing databases in a list. If "Manage my Files" is off, users can pick where they want the database to be stored for each library. If it's on, the user can only provide names for each library, but they will all be created in the default storage location.

Thoughts?

[Skip]

I think that, side by side dbs, is the way to go. It seems simpler and easier to manage. I also thought it is what was being discussed, basically.
In a music editing app I use, I just select an empty staff [new song] in which I had previously set up all my preferences and saved. I change the name 'new song' to what I'm doing and its done. Would making a copy of the base library db with empty entries and forcing a 'rename before save' work?

[sciurius]

Google completely abstracted access to these files, so that you aren't really supposed to know where they are kept. You just go through their SharedPreferences classes and get/set values.

So this is as far as we can get, then.

Ultimately, I don't think all of that really matters though, as why would you want different settings per database? Wouldn't you want the same settings applied to all of your databases?

I think it's a restriction I can live with...

The simplest thing in my mind is to provide an option to select a different database file, and if some of the settings are important, these can be saved alongside the database file. I think each of these database files should be uniquely named so maybe I would have to think about how to handle that. As new databases are set up, the user can easily switch between existing databases in a list.

Maybe an identifier to use as postfix, e.g. "mobilesheetspro_MyProject1.db" "mobilesheetspro_AnotherProject.db" and similar? The pick list would then only show "MyProject1", "AnotherProject" and "<default>".

[chrisss]

Just catching up on this + will add my 2 cents-

- the ability to load more than 1 library is very valuable to me.  Like others, I play in very different situations - jazz, irish folk, etc. Right now I use 2 different tablets to accomplish this.  Would be nice to be able to consolidate to 1.

- having the same settings in each library would be a very livable situation.  I use a few different settings in the different libraries but not nearly enuf to create real pain or even inconvenience.

And speaking for myself, I would also be fine if you make it an in-app purchase for a couple $.

thanks as always for a real fine app.

[sciurius]

Mike, is this still on your "to be considered" list?

[BRX]

Here's +1 for continued interest into that feature.

My database has grown really big, takes forever to load and also often has to reload (probably because of memory restrictions of Android 7) even if I just switch shortly to another app and back to MSP.

So having different smaller databases to work from and switch when the big one isn't needed appeals to me.

[Zubersoft]

Yes, it's definitely on the list. I wish I could work full time on this stuff so I could tackle these things faster, but at the moment, I'm just going to have to address them when I'm able.