Hy everybody,
At first the question: Is there a way to use the linkpoints, when some of them were skipped by using the bookmarks?
The situation: We use the mobilesheets pro app in our orchestra. So one song contains different sheets f.e. 1st to 3rd, bass and drums. Each voice in this song may got more than two pages, so I need to use the linkpoints for page turning. The problem is... when I play the 3rd voice and in the 1st and second one are linkpoints, the linkoints in the 3rd voice won't work until I use the previous one. Is there a way to change this behaviour, so I can use the bookmarks in the correct way without the need of skipping through all voices and linkpoints until I reach the voice I want to play?
Many thanks for your help and greetings from germany,
DerGraefliche
I'm not sure I completely understand the nature of the problem, but it seems to me like the easiest solution would be to just create a copy of the song for each instrument and have different link points/bookmarks set up for them.
Thank you for your reply
Because of your answer I think you got the point. But... there are 950 songs with at least 3 instruments in my library... A splitting of the instruments will cause an very high effort. Too high in my opinion. ^^
I forgot to metion that we all use a pageflip cicada to turn our pages. So the two pedals are set in the app with previous page or previous linkpoint and next page or next linkpoint (I don't know the exact english expression beause I use the app in german).
So... when I turn the page with the pageflip I have to skip through all other instruments and their linkpoints until I reach the right instrument.
I'm looking for a way to "mark" linkpoints as used in their order, when I skip them by using the bookmarks.
Maybe another hint is usefull: I open the song and turn the first page with my finger. When I use my pageflip after this, the page turns, but the linkpoints (which should work with the pageflip too) won't work anymore until I tap one with my finger.
Maybe now my problem is a little bit clearer?
Many thanks for your help,
DerGraefliche
I understand the problem, but I'm not sure what the right answer is. One approach would be, if you use a bookmark to jump to another page, the code could try to find a link point on that page to set as the current link point, otherwise it could use a link point on the following pages as the next. While this would work in your scenario, I could also see this as being confusing if another user thought the link point processing would maintain the original ordering. I could also do something similar if you turn the pages manually with your finger, but the tricky part is, if you turn forward, then turn backward, should I be constantly updating what the next link point is (if both pages happen to have link points)? If pages have multiple link points on them, figuring out which one to use in that scenario would require seeing which link point on the page is closest to the current link point in terms of numbering.
Mike
Mike; Would it work to identify which of the 2 was primary with a switch, off or one or the other [off = default, as is]?
Skip, I'm not sure I understand your suggestion. When people set up the ordering, they may link from page 2, let's say, to page 4, then from page 5 back to 2, then from page 2 to page 6. Two link points would be on page 2, but I don't think you would want either to be "primary" or "default". You just want MobileSheets to recognize that you've already activated the first link point on page, so the next time you are on that page, it should use the other link point. If you manually turned the pages with your finger from page 5 back to page 2, for example, MobileSheets would recognize that you already advanced past the first link point on page 2, so it should use the second link point once page 2 was reached. The logic would be a little interesting though, as I have to re-evaluate which link point should be the next one to be activated with every page turn, so if a tap was used to turn from page 5 to 4, then 4 to 3, then 3 to 2, at each page my code would be seeing if there are any link points on those pages that should be primary instead of the link point on page 5. In that simple example, I can't see the logic getting messed up by that. If there were link points on every page though, some of which came after 5, the current link point would be jumping all over. I would have to make sure that the logic always picked the most reasonable link point on the currently viewed page if the pages are turned by tapping or swiping versus with a pedal. It's definitely a lot more complex than the way it currently works.
Here's I was thinking of, selecting bookmarks as primary lets the bookmarked 1st page set the 1st link number to 1, the same thing happens with when linking is selected, which is what happen currently as I think about it. So a user selecting bookmarks as primary they could then make bookmark-1, the initial location/start page, then use linking as required to the other needed pages/locations, with the links beginning with 1. The user could also make bookmark-2, a different page/location, and since the link numbering would always starts with 1 on a bookmarked page, could start with 1 again. This should allow the OP to select 'bookmarks as primary', mark '1st instrument[1]', then link all instrument[1] locations with links starting with 1, the, mark 'next instrument[2]' and then needed links also starting with 1. I'm not sure what would be the best thing to do with these marks/links when bookmarks as primary was not selected, probably ignore, or a warning maybe, 'further entries will erase all prior entries, do you really want to do this'.
Please do not clutter MSP with complicated code to support a strange and complicated workflow that is only relevant for a special user.
As far as I can see from the original problem description, separate songs for the different instruments/voices is the way to go.
Maybe we can propose a practicable way how that can be changed for many songs.
@DerGraefliche: feel free to contact me in German
Basically, MSP works well and performs its design objectives very well and I have to agree with itsme on this.
Writing complicated code to achieve something, that few would want or need, merely makes it harder to use for the majority and more prone to unexpected bugs creeping in.
It's too easy to ask the author of a program to re-code it when, with a little thought and experiment, the existing program can achieve the desired result. As I see it, the problem here arises from DerGraefliche trying to do something that was never part of the original design brief. More importantly, it's probably solved most easily by having separate parts (as suggested by itsme) not by re-writing the code.