Apps by Arlomedia

In Set List Maker, you can add unlimited databases for no additional cost. In BandHelper, you can add unlimited accounts, but you have to pay separately for each account. To make the two products more comparable, I'd like to add support for multiple databases inside of a BandHelper account. Does it make sense to call them "databases"? Or should they be called "bands" or "projects" or something else?

To clarify, you would be able to create separate databases inside each account, to segment your songs, set lists, etc. This would allow someone who does a solo act and also has a band to manage the two projects separately without having to buy two accounts. As a bonus, a song could be designated to appear in multiple databases, so you could add the same song to your solo set lists or your band set lists without having to maintain two copies of the song.

The pricing would still be determined by the total number of users in your account, so if you had two bands with four band members each, you would need a 6-20 user account (which is the same price as two 2-5 user accounts).

Quote from: arlo on January 21, 2015, 05:31:49 PM

I'd like to add support for multiple databases inside of a BandHelper account. Does it make sense to call them "databases"? Or should they be called "bands" or "projects" or something else?

It's a great idea, and I could certainly see myself wanting to have that functionality somewhere down the road. Bandhelper has relieved me of the two biggest headaches I've had where bands are concerned - set lists and patch changes onstage. With those problems gone it'd be a lot easier to get involved with a second project.

I cast my vote for "projects" but at the end of the day I really don't think it matters.

I have multiple projects, and would like to keep them organized (schedules, repertoire,etc) as unique.  that seems like either unique DBs.  Highly likely another column for "association/group";  A Table space (like custom fields), you could plot multiple groups within the same DB.   Then multiple groups/associations can touch a single data source. 

You understand where I'm going with that I'm sure.   I have one table for  Tunes, and then a linkage to which 'group(s)' have it in their view(s).   Likewise, multiple groups could touch a single instance of 'venues' and the like.   That seems like less physical (DB) space, as 5 groups with the same song are 5x the table space.    This seems like an easier way to scale.  Then you can manage your head count like you already do...through login IDs/pricing model.

it would fit perfectly to the current needs of my band! :D

We do have our own repertorie and tour, but we've been just booked to be the backing band of a New Zealand artist for some european dates this summer.
So we just started dealing with two totally different repertories, two (or more) setlists; and two schedules to be merged into one! :P
I can manage it all with SetListMaker. Except for the schedules... each of them is managed and merged "old way" with Outlook and/or Excel.

This functionality is now finished in my development environment. I named it "projects" according to the poll results above. :-) This will be available in iOS version 2.3 and Android version 1.3 in about 10 days, depending on Apple's review time. Here's an excerpt from the release notes:

Added support for multiple projects within each account. You can navigate to Account > Projects in the web interface and add a new project to enable this functionality. Then you can edit any item and select the projects you want to use it with. For example, you could add a project for each band you play in, and enter different songs for each project, but share a few songs across both projects. If your account contains more than one active project, you can switch between projects in the web interface by hovering over "Your Account" in the header menu and clicking a different account. In the app, a list of available projects will appear when you open an account.