• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Quick links
I use the question mark feature quite a lot (hit the question mark at the bottom of the alphabet to get a random choice from the list) as a way of generating random playlists on the fly - client requests a genre of music which we filter for and then we hit the question mark after each piece to get the next piece. What might improve it for us is to be able to get a random selection without having to go back to the library. Perhaps that could be one of the options for touch settings - e.g. tap the bottom left corner and the random piece dialogue pops up.

Another feature I would like to see is the ability to jump to a piece or to a setlist from whatever song happens to be selected. That way when we need a piece/setlist in a hurry (e.g. the processional at a wedding or first dance at a reception) we can go straight to it without having to search or go back to the library then go to the setlists tab, then select the setlist. That could also be a touch option or perhaps a smart button (albeit one that could be on the screen for every piece, which I guess would make it the same as a touch option).

If these features are already there or if anyone has a handy workaround then please let me know.

Also if there were an option to change 'song' to 'piece' I would totally use it. After years trying to get students to only use the word 'song' for pieces which are actually sung I still cringe a bit using 'song' for non-songs.
(09-11-2020, 10:42 AM)Oz Cello Wrote: Also if there were an option to change 'song' to 'piece' I would totally use it. After years trying to get students to only use the word 'song' for pieces which are actually sung I still cringe a bit using 'song' for non-songs.

+1  Hear! hear !
Il ne faut pas rouler vite... il faut freiner tard
I've added a feature request in my bug tracking system for a touch/pedal/smart button action to load a random song from the last viewed list on the library screen. Also, don't forget that you can set up a setlist with all of the songs in your library, then change the sort order to "Shuffle" to get a random list. You can reshuffle the list in the overflow menu if needed.

There are already options for quicking loading a song (but not a setlist). If you tap the bottom right corner to bring up the quick action box, long press the right icon and change it to "Find and load song". You can then tap that icon to quickly find another song in the library and load it. That same feature is accessible through the circle at the bottom left corner of the song overlay.  You can also use a smart button to load any song in the library. Create a smart button and choose the "Load or Go to Song" action and you will see the option to select the song. If you are in a setlist, you can temporarily add a song to the current setlist in the setlist window by tapping the + icon at the bottom right. You can also tap the "Pause Setlist for Song" icon at the left side of the setlist window to load a song, but once you hit the back button, it will return you back to the setlist. If none of these will work for your needs, I'm going to need more details on what exactly you require. If loading a setlist is critical, then I will have to add a separate action for that, or revamp the current "Find and Load Song" dialog to also include the ability to load a setlist (some kind of toggle would switch between what is being searched for, and I would have to change the name of the action).

As far as changing "song" to "piece" or another variant like "score", that is extremely difficult for me to do. The reason is that the word for "song" is contained in a huge percentage of all of the translated entries used in the application. Every single place where "song" is currently used would have to be changed to be dynamic in terms of what word it looks up and uses (and this is not an easy change to make). This includes all of the user interfaces that have labels with the word song in it. I can certainly look into doing this, but it will require some pretty extensive changes, as whatever I do has to work for all 15 languages the application supports. I also don't know if you swap "song" out for another word in other languages, if the translation still works properly in all sentences.

Hi Mike, thanks for the quick reply.

I like the idea of the shuffle sort - hadn't thought of that. It can't be used with the filtered library (is there a reason for that?) but I'll start using groups instead of just filters. It might still be nice to have a random choice option somewhere in the song view (perhaps as one of the options for the programmable icon in the quick action box) but the shuffle sort should work for me.

I think the need for the quick link to a song/setlist might have been created by the way I've been using the app. Most of our bookings are for wedding ceremonies so I've been filtering the library to the kind of pieces they want played before the ceremony (say, light classical) and then using the question mark to choose them at random, then when the ceremony starts I've been using a setlist for the pieces they've requested during the ceremony. To get to that setlist I've had to get out of the song I'm in back to the library, go to the setlists tab, kill the filters (because they act on the songs in the setlist so some of the songs might not show), then select the setlist. That all took longer than I wanted. We've got a wedding today so I'll try creating a shuffled (pre-filtered) setlist for pieces before the ceremony, as well as the setlist for the pieces played during the ceremony. That way when the processional starts I'll just have to go back to the first setlist, then back to the list of setlists, then choose the second setlist. I won't have to kill the filters because they will have been pre-applied to the setlists. The e-Ink tablets are slower than regular ones but hopefully that will be quick enough.

I'm very happy to keep using the app with 'songs' instead of 'scores' or 'pieces' - it's a really good app and I happily recommend it to any muso who'll listen. If at some stage you end up with time to change that then that would be great but other changes that you have scheduled (in particular versioning but also the ability to control which filters are shown) are way more important for me, and I imagine the iOS version will have to be high up on your list too. Having said that, I think the kind of casual pedantry that makes me reluctant to use 'songs' for pieces that aren't sung is fairly common among classical musicians and I know that when I first started looking at the app and saw that you were calling files 'songs' my first thought wasn't that the app might've been aimed at singers or people working primarily with sung songs, it was that it might not be a very good app (a fear that was allayed a bit if I'm honest by your use of the Chopin as the sample score). I hope it doesn't stop some people from using the app.

Thanks again for your help. Guy
Hi Mike.

I use 4 Max 3 tablets for string quartet gigs. I've been loading the parts for each instrument for every piece into the main library, then for each tablet I have a library just for one instrument with the parts for all the other instruments deleted. To delete the excess parts I do an 'exclude' filter on the instrument whose parts I want to keep, select everything that remains, and click delete (unticking 'delete pdf' in the confirmation dialogue). It takes a long time to delete all the excess part, always freezes the app, eventually bringing up the dialogue saying that the app isn't responding and asking whether I want to wait, and then sometimes crashing the app. Luckily when I re-start the app I can just go back to deleting from where it left off. Just wanted to let you know in case there's something you can do with the app design or a different way I can pare the library back to just one instrument's parts without freezing/crashing the app.

Cheers, Guy
When Mike gets to do his versioning feature (which will be some time in the future though) I guess all this stuff will be obsolete.

But why do you work with different libraries and deleting stuff?

Isn't it easier to keep all the PDFs on the tablet and just assign the parts of the instruments to a group like collections?
You can sync this between the tablest without the extra work. You can assign sheets to a collection with a filter as easy as you
select them for deleting.
Hi BRX. I use the different libraries so that when I use the master/slave feature each tablet loads the right part for the instrument using that tablet. All the tablets can have all four libraries (one for each instrument). Each player can use any tablet by choosing the library for their instrument. When one player has the master tablet the piece they load up will be the right part for their instrument and then each slave tablet will load the same piece but with the right part for their instrument.

Mike had suggested using the custom sort title instead. Each tablet would have the whole library but then each tablet would be assigned to an instrument and would have a the title copied into the custom sort title field just for the part for that instrument. We could then use the custom sort title option in the master/slave dialogue. That method did work but it would mean that the library wouldn't be the same on each tablet - rather than just keeping one backup of the whole library I would need a backup for each instrument. That seemed like it would defeat the purpose a bit. Also the custom sort title isn't editable through the companion app which means I would need to copy the titles over one by one on the tablet - with nearly 3,000 parts loaded already that would take some time, particularly on the e-Ink tablets we use. Even with the wait time for the delete it still seems easier to do it the first way.

You're right that this will all stop being a problem when the versioning feature comes out but it sounds like that is going to be a while off and I wanted to check whether there was something I could do about the freezing in the meantime.
@Oz Cello

I don't really understand what you are doing but it sounds as though you have 3000 odd songs in your backup (possibly 12000 if there is a different version for the 4 instruments).
Each tablet is given the full backup and you then delete the unwanted songs/parts.

This means that you are deleting 3/4 of the entries each time. Processing long lists on a pc is time consuming and it also depends on how the deletion process has been coded. Typically, coders process the list from first to last because that is the way we would do it manually) whereas the quickest way on a pc is to do it from last to first (this minimises any shuffling of records because you only shuffle the records you want to retain). Note: I've no ideas how Mike codes it.

You also talk about deleting the songs; this implies that you are deleting physical files. Again, a long process when there are many files. I suspect your tablet stores the files in alphabetical order so performance also suffers if files are deleted from first to last. In this case, it is worse than deleting from the database as each file involves one or more calls to the filing system with a "shuffle" after each deletion  (that is a lot of shuffling)

What can be done about it?

If Mike is deleting from first to last, he should consider deleting from last to first.

If you are deleting the songs then you should try to experiment with removing them instead e.g. one delete songs from the main Songs tab but one can remove songs from a collection or setlist (removing would eliminate the time spent performing physical file deletions).
Note: I've no idea whether this will work with your way of synchronising the different instruments; it is just something that may help you improve the operation.

One other way you could consider is to use a separate library per instrument (I know it breaks your one backup goal) and store these in the cloud. Each tablet could then sync to it's instrument of choice. As someone who manages the database, this would involve more work in switching between libraries, backing them up separately and ensuring that the song metadata was consistent across the libraries.

I hope the above helps.
Stay safe
Samsung Galaxy Tab A6
Another oddball thought. I not very savvy with the master/slave feature. But wouldn't it work if all tablets have the same collection and song name?
Or are there more checks involved?

Because then it could be possible that you make separate collections on each tablet for each instrument coll1, coll2, coll3 and another one e.g. just "coll"
for the master, alle the same on each tablet. But after each sync you just delete (or rather unassign) the content from coll from the master and assign the content of the respective instrument (e.g. coll1) also to this coll. So every tablet has the right songs in the same collection "coll" with the same names.

Wouldn't the master/slave function work this way without your elaborate deleting with a quick assignment to the collection?

Just a thought and I hope it's clear what I mean.
Hi Geoff. Thanks for the info and advice. Interesting to hear how it all works. I think I'll have to take your suggestion of backing up the instrument libraries in separate backups. I imagine that will save some time in the long run.

Hi BRX. Thanks for the suggestion. I did try that (but using instrument groups instead of collection groups) and the master/slave feature will quite happily pick from outside the group unfortunately so it doesn't work. Mike did explain why at one stage - I think it was that it only tries to match on a couple of attributes (title and file name I think?) rather than trying to match all the attributes. When I have some time I'll give it a try with collections just to be sure but I think it will produce the same problem - I have a feeling that the unwanted parts do need to be out of the library altogether to be sure the right part will load.

Thanks again
Yeah, if it matches the file name then there's the problem.
Maybe if you use the same filenames from different folders to circumvent a filename check 
(if there's not a path check, too).

Well, Mike has to chime in or you have to try.
Deleting thousands of songs at once can take awhile, but it depends on a variety of factors, including:

1) Are you using local storage or a removable SD card? Local storage is usually much faster on most devices. If you use the default application storage location on a removable SD card, then it should still be pretty fast. If you use a custom storage location, due to Google's "Storage Access Framework", each file deletion is going to be horribly slow. So if you are encountering issues with the application not responding, this could be part of it. That's still a bad sign though, as it means I'm not deleting everything in a background thread, so I'll have to update the code to properly handle that.

2) The amount of information being deleted from the database. I use a single transaction per deleted song, but this is also bad, as it means changes will be committed to the database after each song deletion, which is going to be slow for thousands of songs. I will need to update the code to use a single transaction. This could speed things up dramatically.

So I'll go through an update the code to help make this a lot faster. As far as the ordering of deletions with files, with solid state memory, this really doesn't have a significant impact, and if you use the default settings, MobileSheetsPro uses a different folder per song, so there really shouldn't be file shuffling. I also don't sort things based on file paths, so the order would be difficult to determine anyways.

As for the library matching, I don't support matching on multiple fields beyond the primary selected field and file name if there happens to be multiple matches. If necessary, I can try to update the logic to look through additional fields in the case that there is an exact match for both the primary field as well as file path. I would probably compare collections first, then custom group, then the other fields. 

Mike, thanks for the explanation. I'm using local storage and the app is set to manage my files and create subdirectories for songs. Sounds like handling deletions in a background thread might resolve the freezing, and changing it to a single transaction could be good too if that's not too tricky.

If you were to add additional fields to the matching for cases where there are multiple matches on the primary field and file path then the order you've suggested would work for me, but a complete versioning feature would be better. I initially assumed that the matching would try and match every field and tried to work out how I was going to use the app based on that assumption but it makes sense that that wouldn't be the case and now that I have a better idea of how the matching works I can use the app accordingly.

Can I check that I understand how the custom sort field works? It's a field that can be used for matching but it also overrides the title/formatted title for sorting purposes. When it's used for matching the field itself is all that's matched and not formatted titles. Is that right? There isn't much in the manual on it and I think when I was first messing around with matching I thought that using the custom sort title as the matching option would match formatted titles but it didn't?
That is correct - it will match just on the custom sort title value as shown in the song editor. There is no option to match on formatted song titles at the moment. I can certainly look into adding support for that though if you would like. I can just add a checkbox to control that behavior in the settings below the dropdown that lets you pick which field to match on.

I like the idea of being able to match on formatted titles because it seems like it would be more accurate (avoiding clashes that might come up with songs with the same title) and because it could be a powerful tool as a workaround for versioning. For example for use with a string quartet I could have one library with all the parts on all four tablets and then to use a tablet for a particular instrument I could do a quick batch edit to add an identifier to the formatted title for all the parts that belong to that instrument. As long as the identifier made the formatted title the same as the formatted title on the master tablet then that should bring up the right part on each tablet. That would make a few things easier for me.

Having said that, I don't think I've had any problems with clashes in matching yet (presumably the file paths are different even if the titles are the same) and I would prefer a full versioning update rather than a workaround. But if the versioning feature is a ways off and adding matching on formatted titles wouldn't take long then it's certainly something I'd be really keen to try out.

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

Users browsing this thread:
1 Guest(s)

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.