MobileSheets Forums

Full Version: Title format dialog box- limited to fields shown?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi,
In the Title format dialog box, are we limited to the fields shown? I.e., no way to add the "Collections" field?
I can always add additional fields if they will be useful to people. I guess I didn't consider the possibility that people might want to use collections in the song titles. I will add it in a future update.

Thanks,
Mike
I was able to insert one field, 'Orchestrator', but I want to insert more custom fields as 'instrument'. Is there a way to do that?
A general way to add custom fields would be appreciated.
I only support one custom group. My current design is not really set up to allow for any number of custom groups. This would add a large amount of complexity to certain parts of the application. If enough people want this, I could look into trying to add it in the future, but it would take a fair amount of time and effort.
Instrument and mode(as in myxolydian) are two fields that I could use.
(06-25-2015, 01:08 AM)Jan Hankel Wrote: [ -> ]I was able to insert one field, 'Orchestrator'
I am using "custom group" to record the instrument. I can enter "D Whistle", "C Whistle" and so on but I can't change the words "CUstom" Group" to "Instrument". Should I be able to?
Settings>library settings>Custom Group Name. This names the only custom group. If you want to see this in the main songs tab, settings>library settings>Song title formatting and select %custom groups% on 'caption format', and check 'show caption'.
(06-25-2015, 03:29 AM)Zuberman Wrote: [ -> ]I only support one custom group. My current design is not really set up to allow for any number of custom groups. This would add a large amount of complexity to certain parts of the application. If enough people want this, I could look into trying to add it in the future, but it would take a fair amount of time and effort.

Mike, would it be less complex to allow existing tabs (Artists, Albums, Genres, etc.) to be re-named?  I suspect many of us don't use them all for their intended purpose - I only use four of the 14 provided - and if they could simply be re-named, that would probably be enough for many people.
GraemeJ- Thanks for the info.
(09-22-2015, 09:19 AM)GraemeJ Wrote: [ -> ]Mike, would it be less complex to allow existing tabs (Artists, Albums, Genres, etc.) to be re-named?

This would work for me.
What are the custom and custom2 fields for?
I have plans to add four new custom groups at once. It will just require a fair amount of redundant code due to the way my current model is implemented. As far as renaming existing fields, I could certainly add support for this, but it requires that in every message I have in the application (and every label) I have to add code to replace the group name. It's do-able, but it will probably take more time to do that than to just add a few more custom groups.

Mike
Fair enough - it was just an idea Smile .
@Marlan: Custom and Custom2 are two additional metadata fields to be used for whatever you find helpful. The difference to "Custom Group" is that the fields "Custom" and "Custom2" only can be edited per song whereas every new entry in "Custom Group" is added to its selection list. And a tab for "Custom Group" can be shown on the library screen titled with the name that you have given to "Custom Group".
@Mike: more custom groups are great and being able to give significant names to the fields "Custom" and "Custom2" also would be helpful.
And I would appreciate having %Filename% and %Path% tags for "Title Format" and "Song List Format". I would use them mainly for exporting song lists. Using them in "Caption Format" (the second line of the song lists in the library) could be helpful for mainting chart files.
I'll see about modifying the custom/custom2 labels. This is something I can do, it just takes a little effort to coordinate the change between the tablet and the companion app. As far as displaying file name/path, I currently cannot support this as I don't read out all of the file information from the database at startup. I avoid doing this because I want the application to load faster so I reduce the amount I query from the database to the bare minimum needed and it also uses more memory to store all of the file information from the database (as I read out a lot more than just the file path information). If it's really important for people to have access to the file path information, I could look into changing this in the future.

Mike
Pages: 1 2