Support for multiple 'databases'?

AnthonyB

Hi Peter,

Just wondering if you've considered the idea of having a way to keep different groups of song/playlists/lyrics in different instances/containers/databases so that the current ST3 model of a single database doesn't blow out in size if you have multiple projects/bands that you work with?

I can already see the first argument against this would be 'what if you have a song you need in more than 1 'instance'? Then you are duplicating it while is wasteful." or similarly, what if you quickly want to pull up a song that is in another instance? Yep, sure, might happen.

The reason I throw this idea out there is that all the projects I'm working on use multitrack backing tracks. The size of the repositories, and full backup databases, is getting larger and larger, which also makes them harder/slower to work with. Yes, I could use Keywords and tag in Artist/Title to use as filtering mechanisms, but these feel like work-arounds rather than solid solutions.

I'm at the stage where I'd really like to be able to load different ST 'instances' (i.e. databases) where each one represents a different project/band that I'm working on.

If I need to access song from another instance, I can just export/import that song. Or maybe there could be an option to open another instance and import a song from that database.

The other scenario I was thinking about was a 'disaster recovery' scenario where I might have an Ipad I'm using for joining to a Host session at a gig to receive lyric files, and also has some local lyric files. But if my main ST iPad running the backing tracks fails, it would be great to be able to simply change instances on my iPad, and substitute it in.

I appreciate I can already do this by having multiple databases backed up on my iPad and just load the one I need. However making/restoring backups isn't as quick as simply having multiple instances available to you can switch between.

I'm sure there are going to be more pros and cons arguments, and 'you can already achieve this by doing A-B-C-D-E-X-Y-Z' type suggestions, which I do acknowledge. One of the main reasons for suggesting this is to make the functionality easier to use in the UI, and also then make any necessary changes to database structures.

Damir

AnthonyB perhaps a better use of HISTORY , let’s say you have multiple bands you work with , you create a playlist of all songs you need with that band and save that in to HISTORY , so now you have your normal playlist area to create all the future gigs and you have in history your starting point to choose which band playlist you need copy it to playlists rename it to the gigs name and presto you have a new gig with the appropriate bands songs , just rearrange the songs in the order you want to play them in you can easily remotely find next song selection if you need to skip to a different song , all you songs for all the bands are in the same database and easily fully backed up , copy this full backup to another device and you have a nice backup identical to the one you are using , and you can use this backup device or devices as a slave on stage. So every device can be a backup or slave or host as they are all the same . And you have every bands songs in HISTORY .
History at the moment is as useful as tits on a bull 😂
Yes it’s ok, but not great 😂
It could have a much greater purpose.
SONG mode is the overall storage of all songs .
PLAYLISTS are great for future gigs.
HISTORY should be for storing old gigs or a place for TEMPLATES to create future gigs.
Then history would be much more useful than it is now.

AnthonyB

Thanks both for sharing your thoughts.

Damir perhaps a better use of HISTORY

I've seen this use for History mentioned a few times, and appreciate it is not quite the intended use and therefore not an elegant solution. I've looked into this and struggle to make it work. Possibly because my play history is littered with so much data as I work on stuff, rehearsals, etc.

peter It would still store all files from all projects in the app. How else would it be possible to switch quickly between projects? And where should inactive projects be stored to not take up space?

Ah. Right. I had not considered the limitations of the tablet app model. Without an ability to 'offload' a project (database) for switching to somewhere else in a reliable and performant fashion, then this becomes a technical obstacle.

To you both, let me pose a specific scenario (again, may well be an edge case) that ultimately prompted me to create the original post in case you can advise a solution.

I have 2 iPads:

iPad 1 - My main backing track playback iPad with 100+ songs, 99% are multitrack audio (remainder lyric only), all with timestamped lyric sheets (except those 1% lyric only), and it hosts a session that band members connect to so that lyric sheets are pushed to them.
iPad 2 - My own 'lyric sheet iPad' that as a Guest, connects to the Host session on the iPad above, to receive lyric sheets.

Now, to date, I always kept iPad 2 with an exact copy of the ST database of iPad 1 in case of emergency (e.g. hardware failure). If such an emergency occurs, I can switch iPad 2 in to run backing tracks, and I'd just use an older/smaller tablet to replace iPad 2, or even revert to PDF lyric sheets on an Android tablet and just manually change pages.

Now, on iPad 2, what do I do if I now want to have some local lyric sheets for some of the songs?
Remembering that it already has all of the songs, as multitrack songs, with timestamped lyric sheets. Even if I create a lyric only version of the song, with the same title/artist (so it matches the song on iPad 1), then I still get the 'pushed' lyric sheet. Or, possibly it is matching the multitrack song before the lyric only song as it looks for a match in the local Song database?
Either way, I'm not getting my local lyric sheet that I attached to the lyric only version of the song.
The only way I could make this work was to delete (or change title/artist) the multitrack song so that it could only match against the lyric only song.
Remember, my goal was to still have a viable backup of iPad 1 for emergency swap AND be able to have local lyric sheets for some of the songs.

Without deleting/renaming multitrack songs on iPad2 (which breaks integrity of my iPad 1 backup solution) is there a way of doing this?

peter

@AnthonyB I'm not sure what exactly you propose as you explicitly mention the amount of space you need for the different projects. So if you want to keep projects small, the only way is by working with different backup files (that you could for example move to a USB stick when not needed). Because while it might be possible to change the database to have different projects which you could switch to (btw, this is already possible by using keywords for that purpose). It would still store all files from all projects in the app. How else would it be possible to switch quickly between projects? And where should inactive projects be stored to not take up space?

So I would really suggest using the keyword feature. Define a keyword for each of your projects and then enable the keyword filter for songs and playlists to only show items from the selected project. Don't worry about storage requirements as long as you have enough space on your device. The number of files or songs is not an issue from a technical perspective.

peter

Ah, I see your issue. I think the correct way to tackle this would be to to allow different lyrics for a song. So that the user could choose which one to show. But I am a bit unsure how to realize that.

AnthonyB

peter

Up front, I do want to acknowledge that this might be an edge case not viable to solve for. That's one of the reasons for my initial suggestion of being able to choose a 'database' so you could quickly and easily load and unload different databases. In this scenario, being able to switch from a 'full backup database' to a 'my local lyrics dabatase' was what I was trying to achieve conceptually.

If there was an attempt to cater for this in the existing single database model, and considering there are no different song types in ST4... Just spitballing ideas...

If there was the ability to load multiple lyric sheets per song (i.e. not just the current 'native' lyric vs PDF lyric), there could be some specific 'lyric prioritization' hierachy at global and/or per-song that let's you choose which lyric sheet takes priority - 'pushed' (i.e. Client joined to a Host), various named local lyric sheets (e.g. Master, Guitar, Drum, Horns, etc. that the user can name as they load them onto a song), etc.

So,

If you are not connected to a Host session, and only have 1 lyric sheet loaded on a song - it takes priority.
If you are not connected to a Host session and have 2 lyric sheets loaded, then the lyric sheet defined as 'Master' defaults to taking priority, unless (1) at a global level you say to prioritise the 'Drums' lyric sheet if it exists, or (2) on a per song basis, you choose (maybe this could orverride a global setting if selected) which lyric sheet has priority.
If you are connected to a Host session, currently in ST3 the pushed lyric sheet is what you see unless the global use local lyric is toggled, in which case if it finds a matching song it will use that lyric. That can stay same.
If you are connected to a Host session and have songs with multiple lyric sheets loaded, then similar to scenario 2. above, except 'Host' is added into the priority list.

peter

There will definitely be a way to switch between lyrics and pdf directly in the player view in version 4. That could theoretically be extended to switch between multiple documents. The idea with categorising lyrics is very good. I like that. But I will most likely not build this into version 4.0 as I have already too much on the plate for that version. But I will take care to be able to add such an feature later on.