[GraemeJ]

On balance, I'm against any changes along the lines suggested.

MSP is already a very versatile application and it can already be used in many different ways. Most of the long-term users have invested much time and effort to tailoring their charts to their specific needs and would not be jumping with joy at the thought of having to re-do all that work. I think it would be better for the OP to adjust his workflow to fit in with MSP than to ask for a 'feature' that very few here would want or use.

[StuartV]

Thanks for all the replies.

I would never have guessed anyone would be importing 100s of songs in one PDF.

As a professional software developer myself, I certainly would not push for a change that would make lots of users lose a whole bunch of work.

At the same time, I imagine most of you can appreciate the feeling that, if the user opens a song and edits the custom page order, the page numbers referenced make the most sense if they are treated as referring to the pages the user sees, in the order the user sees them. E.g. if the user enters "4" in the custom page order field, it is most reasonable for the user to expect that to be used as referring to the 4th page displayed when the user pages through the song without any custom page order defined.

I think there is a fairly straightforward solution to this that would allow existing users to still do what they are doing with no new work:

When you edit a song and go to the Files tab, what is displayed is a list of files and a text input field for "Page Order".

This thread is really about how to interpret the Page Order field. What was not clear to me from just looking at the UI and using the app is that "Page Order" is a Per File setting. I looked at it and thought it was a Per Song setting.

For those of you who are using CSV files and importing one PDF with 100s of songs, am I correct in thinking that the result is you get 100s of songs in your Song list in MSP and each song just has one file attached (the imported PDF), with a Page Order that just specifies 1 (or maybe 2) page out of that PDF? I'm thinking of my Real Books where most (all?) songs are just 1 page.

It seems to me that the straightforward way to deal with this is that each file should have a "File Page Order" attribute, which would replace and take the value of the current Page Order attribute.

And each song should have a Song Page Order field. I.e. this would be the only "new" piece of data to be edited (by the user) and stored.

The files with their File Page Order would work exactly as they do now.

The Song Page Order is the only new piece of data and it would let you define a custom page order where each page number used refers to that page number as seen by the user as they page through the song (assuming no song page order defined).


I mean, in the grand scheme of things, using a field called page order just to let the user specify a page or two to use out of a 200 page PDF is not very intuitive or logical. But, it is what it is and there is a user base that should not be inconvenienced for no good reason. Similarly, telling the user that they can define a custom page order, but they can't use "2" in it, even though they just hit Pg Dn and viewed the second page of their music is also not very intuitive or logical. If this were being done from scratch, I would have suggested having a per-file attribute that just defines which pages to make available. I.e. if you import a whole Realbook just to create the song Blue Bossa, then you would import it and specify the page number for Blue Bossa. But, that would not be termed a page order. It would just be an attribute of that PDF that is one file component of that song. As it is, the app is using this one field, Page Order, for two different purposes. One purpose is simply to pick 1 or 2 pages out of a multi-hundred page PDF. I.e., it's being used as a filter. The other purpose is to actually have the app show the pages of the song where some pages are repeated and to define the number and order of those repeated pages. I.e it actually defines an ordering that allows repeats. Using one field for two different purposes is rarely an optimal software design.

And please don't take any of that as some kind of slam of MSP. MSP is awesome! I have wanted software like this for years and I am equally disappointed that it took me this long to find it and ecstatic that I finally have found it! I love it so much, I went out and bought a new tablet and Bluetooth page turner just to use with it. It really is fantastic! But, that doesn't mean there aren't possibly ways to make it even awesomer! :-)

[GraemeJ]

I think the real way to look at this is to understand that MSP is, essentially, a fancy PDF reader with exceptional sorting and ordering features. JPG files, although loadable, were really only intended for quick and dirty reference - the ability to take a picture of (say) a score from wihin the application was a useful feature, but I don't think anyone was seriously considering JPG's as a target format.

On the few occasions I have done this, I've always converted JPG's to PDF, in order to take full advantage of MSP's features. To my mind this is the way to go, not introduce an additional layer of complexity that will only be of use to a very small number of users.

This is no different from the original version (MS) - primarily a PDF reader with limited JPG handling. The only major format addition made was Chordpro files. It seems a lot of people actually use this format and there was a big demand for it to be added.

[BRX]

I think most of us are in agreement that MSP is awesome, and so is Mike (Zuberman). :-)

Thanks for elaborating on your suggestions even if most of us aren't in favour. I think most of us don't see a big problem/need, because the majority of the songs has only one file and use PDF anyway (at least in my collection).

I still think you would benefit from trying another workflow for your image import.
It's really much more comfortable to photograph from within MSP since you can click away and the images are neatly sorted in the file tab. I noticed that MSP counts normally like page 1/5 in the song view for these as well, so I still think a custom page order isn't necessary and it's intuitive as it is now.

You have a workable song already right now. But why not print this song to PDF at once with the built-in PDF printer and exchange this with the image file or import that? With a minute more effort you have a multiple PDF and all the benefits of the custom page order to crop, duplicate and order away.

And yes, the csv way of importing multi PDFs results in multiple song entries in the database which all refer to the (respective pages of the) one source file. That's one of the most appealing features of MSP to me so one does not to have to split real book collections etc.

Minor last item: The term page order is on point imho. You're just not thinking “PDF“. Initially it was for ordering multi page PDF e.g. for correcting a wrong scan order or to duplicate and rearrange page order for repeats, segnos and codas. The use for csv song creation came later and reused that functionality.

[Zubersoft]

Thank you everyone for your feedback and kind words. You definitely make working on MobileSheets a pleasure.

You make some valid points StuartV, and I certainly understand the appeal of having a song page order field when dealing with multiple image files. I agree that it might be a little more intuitive to have one field that specifies what pages to use from a PDF, and a second field that is the overall song page ordering that can be used with any types of files. As it stands now, there is already a fair amount of complexity when it comes to figuring out what each page of a song maps to, because the logic basically has to do this:

song page x -> file page y -> custom page ordering index y -> actual PDF page z

If I change it to a song ordering instead of a per file ordering, it becomes:

song page x -> custom song ordering index x -> file page y -> custom page ordering index y -> actual PDF page z

That assumes I still support some concept of specifying individual pages to use from a PDF in any order (whether I call it page order or something else). Without doing some analysis, I'm not sure how big of an impact it would be to add that additional layer. I do know that things could get a little crazy if a song ordering is specified but the user then changes the page ordering for a particular PDF which causes the song page ordering to become invalid. The same thing is true if a user removes one of the files in use. I think a lot of error handling would need to be added for this to always ensure the song ordering is valid.

I think it may be a little late in the game to make significant changes to the way the page ordering works unless it provides a great benefit to users and reduces the complexity of the application. I may revisit this after I tackle some of the other bigger, more frequent requests. I do appreciate the feedback you've provided, and if this issue keeps popping up with other users, I'll consider making changes sooner. I believe I could make those changes in a way that would not impact existing users, but the level of effort needed to update the current architecture, UI design and database would not be trivial.

[StuartV]

Thank you, ALL, for the civil discourse. I'm on other forums where posts like mine would have prompted virtual tar and feathers.

To the points about improving my workflow, I simply wanted to point out that not needing to make changes to workflow or spend an extra 1 minute (e.g. to convert a JPG to PDF) is what makes good software even better software. Arguments against changes that eliminate those requirements (for the user to change their workflow or spend an extra 1 minute on a task) are really only helpful if the proposed changes would have a negative impact on other workflows. The changes I proposed do not (I don't think) have any impact on other workflows, so I don't see why anyone would argue against them. Being handed sheet music during a rehearsal and wanting to quickly and easily snap a picture of each page and then use MSP with my BT page turner doesn't seem like an outlier use case. Not wanting to take an extra minute (or a few, for multiple pages) to convert them to a PDF, while the band is sitting there waiting on me to get ready, also seems reasonable. And wanting to be able to quickly set it to page correctly to handle a coda also seems reasonable. Sure, I can take the sheet music home, scan it to a PDF, and make it all nice and neat. But, that takes more time and I really don't like taking the band's sheet music home if I don't have to. It's just one more thing to keep up with - and one that would be outside my normal mental checklist for band rehearsal. I like only having to make sure I grab my bass, amp, and tablet.

Mike, I appreciate the time you take to consider my requests and I understand the cost/benefit prioritization you have to do.

One last point, I do still think there's a bug in this. Last night my band called a new (to me, anyway) chart. I have all the parts in PDF. In my chart (the Bass part), just after the beginning of the song, I have an 8 bar rest where the chart has just saxes with piano accompaniment. We don't have a piano player currently. So, I decided to pull up the piano chart to have the chords for that section and play along behind the saxes.

So, now my 1 song has 2 PDFs in it. What I need to do is see the first part of the Bass chart, then the first part of the Piano chart, then the rest of the Bass chart. Since we already covered how I cannot do that with a custom page order, I imported the Bass chart again, so my Files list has Bass, Piano, and Bass again (the same PDF as in the first Files slot).

What I need to do is select the first file (which is 2 pages), set the page order to "1", and crop it to only show the first part of the page.

Then select the second file (4 pages for the piano chart), set the page order to "1", and crop it to only show the middle part of that page.

Then select the third file (which is actually the same file as the first file), leave the page order as the default (1-2), and crop the first page to only show the bottom 2/3 or so of the first page.

There is definitely some problem with this. From what I can tell, the problem seems to be coming from having the same PDF in the Files list twice. It seemed to be confusing the Page Order setting between the two instances of the same file. The first instance should have Page Order of "1" and the second instance Page Order of "1-2". But, when I tap on each file in the list, it now shows "1" for the first file, "1" for the second file (the piano chart), and then still shows "1" for the 3rd file. But, it actually displays and pages through them all correctly - showing pages 1 and 2 for the second instance of the Bass chart.

Of course, if there was a Per Song Page Order field, I could have just imported the 2 PDFs and accomplished what I want with no problems. :-)

[AndyL]

I can confirm there is definitely something odd with the page ordering of multiple files. I tried a quick test adding a multi-page PDF twice. I added one file and selected a couple of pages (10-11). Then added the file again and selected another couple of pages (14-15). Using the arrows cycled through the four pages, but the page range never changes. It is stuck on the range for the second file. I also couldn't select the first file from the list (it never went green). So I suspect this may be the problem.

Regards

Andy

[Zubersoft]

I have never tried adding the same PDF multiple times to the same song, so it's very likely there are some issues there. I'll work on getting this fixed.

[AndyL]

I guess you should try adding the same JPG multiple time too :-)

Thanks

Andy