Posts: 9
Threads: 1
Joined: Mar 2014
Reputation:
0
Nearly a year ago we talked about the possibility of importing PDF bookmarks into Mobile Sheets.
I work with a large choir whose members are split between IPads and Android tablets. I believe this is a very common situation.
With the ability to import a PDF and pull in it's bookmarks, our IPad Users are able to work immediately.
Without this ability the android users are almost nonfunctional.
I hope you will please consider adding this ability soon.
It doesn't matter if it is on the android device or by using the companion PC app.
I would add also that pulling in bookmarks to the setlist would also be very useful.
Please consider adding this ability soon.
Thanks
Posts: 1,339
Threads: 99
Joined: Jul 2013
Reputation:
6
I don't find not having this feature that much of a problem. I just use a bit of software to split the big file at the bookmark points and then transfer the smaller files (either all or just the ones that I need) to the tablet. It's very quick and easy to do this.
I fail to understand why you would need to bookmark a setlist - surely a setlist is, by default, in the order you need it?
Posts: 9
Threads: 1
Joined: Mar 2014
Reputation:
0
I could split the files easily. That isn't the point. I am trying to distribute files to 30+ people on a weekly basis. Many of them are not by any means tech savvy.
When we are done with the music it needs to be removed.
I may have stated incorrectly with the setlists.
The point of the setlists is that it is important to be able to create a setlist based on the bookmarks within the files rather than linking to files.
Similar to this Thread - http://zubersoft.com/mobilesheets/forum/...hp?tid=282
I hope this clarifies what I was saying.
Posts: 1,339
Threads: 99
Joined: Jul 2013
Reputation:
6
03-28-2014, 07:58 AM
(This post was last modified: 03-28-2014, 07:58 AM by GraemeJ.)
Aha - now I understand what you meant about bookmarks in a setlist.
As for the other problem and given that MS doesn't work the same way as an iPad, wouldn't it be easier to just distribute the separated files?
Posts: 1
Threads: 0
Joined: Jul 2014
Reputation:
0
I see this is an ongoing topic, and am hoping some resolution is seriously in the works.
I love using this program ... However the inability to include bookmarks as set list songs is difficult.
My OCP Piano Accompaniment book has over 1,700 pages - while I can painstakingly copy / export one song at a time for weekly set lists, I would much rather have the ability to use all of the bookmarks in place as set list options.
Thank you for any help or advice ...
Posts: 13,280
Threads: 301
Joined: Apr 2012
Reputation:
234
narmani,
The way MobileSheets is currently designed, I really can't treat a bookmark as a song, because a bookmark doesn't tell you how many pages the song should be. I'm adding in version 5.0.0 a "snippet" feature which lets you cut out a portion of a song to create another song really quickly. So if you added a song with a 500 page pdf, you could open the song, and then use the snippet feature to just type in a name and a page range, and it would create a new song using that. You could repeat this multiple times to split up the PDF quickly. This is really just a more convenient way to use the copy/paste method that currently exists.
I have not yet added support for importing PDF bookmarks, but this begs the question - if I just import PDF bookmarks as bookmarks in MobileSheets, this may not really meet everyone's needs. If I import PDF bookmarks to try and create songs out of them, how long do I make each song? Do I just assume that the pages between each bookmark is how many pages that song should be?
There is another option that I haven't really thought too much about yet. The current model for a bookmark is just a named link to a page in a song. If I did away with this model, and instead treated a bookmark as an independent song with all the properties of its parent, but a different title, and a different page range (I would have to enforce page ranges for bookmarks), then I could support what you are describing. The only difference between a bookmark and a regular song would be that there is a flag in the database that specifies that the bookmark is a child song of another song. From a user interface perspective, there would a lot of little things I would have to add code for all over the place though... Because of this, I would prefer just finding a way to make the current architecture work by creating songs out of PDF bookmarks if that works for you. I'm definitely open to thoughts and suggestions about this issue, and how people would like things to work.
Mike
Posts: 249
Threads: 33
Joined: Apr 2012
Reputation:
2
07-24-2014, 03:59 PM
(This post was last modified: 07-24-2014, 04:00 PM by bumblebee.)
You might be able to think of bookmark import options like import with the assumption the next bookmark is the next song, no import of bookmarks etc.
Some publications will start a new song on a new page (the PDFs I prepare do this) and others with a song starting on the same page as one ends so an Edit mode would be useful to check and update once imported.
I find it very slow to create the individual song bookmarks from a PDF within MS so do it on computer.
Posts: 9
Threads: 1
Joined: Mar 2014
Reputation:
0
Bumblebee is right.
It works perfectly to assume that the page range for a bookmark is up until the next bookmark.
If this were implemented it would completely resolve our issues.
We are also working with thousands of pages and hundreds of songs.
Breaking all of these out into single files would be a nightmare.
Posts: 1,339
Threads: 99
Joined: Jul 2013
Reputation:
6
(09-18-2014, 12:35 AM)pspeth Wrote: We are also working with thousands of pages and hundreds of songs.
Breaking all of these out into single files would be a nightmare.
I don't think it's as much of a nightmare as you make out.
On the assumption the pages have been bookmarked, using software to split them into single files can be achieved in, literally, seconds.
Posts: 9
Threads: 1
Joined: Mar 2014
Reputation:
0
Respectfully and emphatically you are wrong.
There is much more than technical issues to deal with.
We have a large choir with both Ipads and Android tablets.
We have age ranges that go from 20 to 90.
I appreciate that you may not need this feature but I do.
You are now on record and not needing it.
Posts: 1,339
Threads: 99
Joined: Jul 2013
Reputation:
6
You may feel that you need this feature (and maybe you do) but the fact of the matter is that it does not exist at the present time, so you will have to start thinking about solutions that are achievable.
Splitting large PDF's, using existing bookmarks, is quick and easy. These can then be distributed to both iPad and Android users for loading into their respective softwares.
What you need then is a way of distributing the current setlist. This could be as simple as a typed list, distributed at a rehearsal, from which users create their own 'electronic' list on their iPads/androids.
I appreciate your comment about the technical ability of your users but, surely, if they have a tablet and this software, they must know how to use it? I would guess that most of them are email savvy as well and that would be another way of distributing the setlist.
Of course, since the iPad software already has this feature, you only really need to do this for the Android users.
Posts: 9
Threads: 1
Joined: Mar 2014
Reputation:
0
Your assumption is incorrect that because they have the tablet they know how to use it.
It is exactly because of these challenges that a number of user have opted out.
In addition we are striving to maintain our copyrights which means we are not simply sending these files out, but also asking them to remove them when we are finished with a season, or sometimes a single performance.
In an Ideal world there would be a folder that they could connect to and their local copies would simply be synchronized, but the is a whole new level of complicated from a development perspective.
I simply want the ability to let them work with packet files without having to recreate the bookmarks.
In the end, more than half the people who could be using android are simply not.
Posts: 1,339
Threads: 99
Joined: Jul 2013
Reputation:
6
If you have users who are not able to use a tablet and this software, then I'm a little surprised, as it's pretty self-evident how to use these things (I note that neither PC's nor tablets come with anything that could be described as a comprehensive manual, all in-depth stuff seems to come from third-party authors).
That said, it's not that big a problem and a short 'lesson', given by a more savvy member should suffice to bring those lacking such skills up to speed - at least to the point of using and maintaining MS.
Maintaining your copyright restrictions is another matter altogether and without a centralised and synchronised source, that is not going to be easy. Even with one, the more savvy users can easily make personal copies (f they so desire).
At the end of the day, what you are asking for is not currently a feature of MS. Until it is, you only have two solutions; 1 - everyone buys an iPad or, 2 - find a work-around until such a feature is available.
Posts: 9
Threads: 1
Joined: Mar 2014
Reputation:
0
I am successfully maintaining the works on the IPads because I am able to distribute the files as Packets. They are able to easily remove the packet files.
If possible I would like to keep this thread about suggestions that discuss the best way for this to be implemented.
There are many other great things that can be discussed in their own threads.
Let me know if you have any insights specific to this.
Thanks
Posts: 1,339
Threads: 99
Joined: Jul 2013
Reputation:
6
Not being an iPad user, I don't even understand the reference to packets .
I really can't add any specific solutions to your problem, other than to re-state the obvious - what you seek is currently not implemented in MS and you need some sort of work-around. My solution would be to split the files into separate PDF's, but you don't seem to be keen on that idea.
|