Cloud sharing for Sibelius scores with multiple copies

Sharing a Sibelius score with Cloud Sharing (in Sibelius 8.7 and later) is quite straightforward. You can see a description of the process with examples in this Scoring Notes blog post.

Cloud Sharing identifies a score using a hidden file ID that is created when a score is saved or exported in Sibelius. It uses that file ID to determine if a score can be updated (Pushed), reusing its original URL, or if it need to be shared from scratch, generating a new URL.

It is important to understand that if you make a copy of a score outside of Sibelius (using the file system copy commands), the file ID will not change. Both scores will have the same file id, and if you try to share or push either score, it will be assigned the same URL and will overwrite the previous shared score. If you want to share variants of the same score, make the copy in Sibelius (with File > Save As), which will generate a new file ID.

I will discuss two cases where multiple variant copies of a score are generated from a single score, and how to use Cloud Sharing with such a score. The two cases are Extracted Parts (not dynamic parts) and scores created by the Rehearsal Recordings plug-in, which ships with Sibelius.

As of Sibelius 8.7.2, each extracted part file will have a unique file ID which is different than that of the original score. This allows you to share the full score and its parts as separate files (at present you cannot access dynamic parts from within a shared full score).

Rehearsal Recordings has an option to generate volume-modified scores that are clones of the original score. Each such score will have its own file Id and will generate a unique URL when shared.

Making updates to shared scores

In both cases, initially sharing these scores is straightforward, but you cannot update them using Home > Cloud Sharing > Push if you extract parts again or run the plug-in again, because the file IDs in the scores will have changed.

There are two reasonable ways to update these kinds of scores:

• Delete the original shares for the scores (from the Dashboard, if the score is selected the text “Delete” will appear), and then share the newly generated ones. This will generate new URLs.
• If the changes are small enough, you can hand-modify each original part file or score (which preserves the file id), rather than creating new scores, and then use Push to share the scores. This may be useful if you have already shared URLs with users and would like to update the scores without having to send out new URLs. It is, of course, tedious if you have a lot of changes or a lot of parts.

Distinguishing among multiple shared copies of a score

If you are sharing multiple copies of a score, you will want to be able to tell which shared score copy you are looking at in the Cloud Sharing Dashboard, and in the score displayed by the URL.

Identifying a score in the Dashboard

In the Dashboard, scores are identified by the title, which will be the score.Title field (the Title field in the File tab) if present. If that field is empty, it looks for text with the style “Title”, and uses the first one of these it finds, even if not in bar 1. If it finds none, it will use the file name with extension but no path. It does not look at title text on title pages.

In both our examples, all the extracted parts or generated scores will have the same title as the original score, and you will not be able to tell them apart in the Dashboard.

The cleanest way to fix this is to put a unique name in score.Title for each of the scores. If your score already uses the \$Title\ wildcard you will have to change that to either use a different wildcard, or no wildcard, or else use what is now in score.Title as the title.

If you know you will be sharing scores, it is easiest to set the score.Title and Title text to be something that works well with Cloud Sharing from the start.

One identifier that would work in these cases is the filename, which would be unique for each file. Unfortunately you cannot use a wildcard in a File > Info field, so you can’t just use \$Filename\ in score.Title. The text will need to be hard-coded. You can type the file name (or possibly the original title with an appended part name) into the score.Title of each score, and you will need to remember to do this each time you recreate these scores.

You can use the downloadable plug-in Store Data for Wildcard to automate some of this. It will derive the values for a number of fields, including file names and dates, and put them into the File > Info field of your choice such as score.Title. These values will be hard-coded, showing the values at the moment the plug-in was run, and will not change automatically if the score changes, so you will need to run the plug-in again if anything changes. If you run the plug-in from Run Plugin On Score And Parts (included in Run Plugin On Folder of Scores), you can set all the parts at one time.

Identifying a score on-screen

Extracted parts will identify themselves on-screen by the use of the Part Name in the upper left-hand corner of the score, and this is most likely adequate for telling the parts apart.

For scores generated by Rehearsal Recordings, the simplest thing to do would be to just have the Title text use the \$Title\ wildcard and have it pick up whatever identifier you have put in the score.Title field, especially if you have already altered it to be unique for the Dashboard. If you do not want to change the title itself, you could add a piece of system text that includes the part or instrument name (which Rehearsal Recordings generates as part of the file name), or use the file name itself in such text, or as part of an added footer. Be aware that the \$Filename\ wildcard does not render in Cloud Sharing, so if you use the file name you will have to hard-code it.

I personally like to include the date and time the score was created, so it is easy to see if you have the latest version. That data could be added to any of these locations.

Minimizing the size of shared scores

There are limits to how much data can be shared with Cloud Sharing, so it is useful to strip out all Versions except the current version, and also to delete parts in a full score before sharing the scores. The downloadable plug-in Export Scores With No Parts (category Batch Processing) can do both these things for a score or folder of scores. Note that it makes a clone of the original score, so it will have a different file ID, and you will not be able to use Push to update the resulting score.

Click tracks in shared scores

As of this writing (February 2018), Cloud Sharing does not support the playback of a click track, even if the click track is audible in the original score. The downloadable plug-in Add Simple Click Track (category Playback) will create a new staff with a woodblock instrument that can serve as a click track. The plug-in can hide the staff, or you can use Layout > Hiding Staves > Focus On Staves to hide it before sharing the score. If you add this click track to a full score, Rehearsal Recordings will generate a separate score that emphasizes this instrument, and you will likely just want to discard that score.

The Rehearsal Recordings for Cloud Sharing plug-in

I created a variant of the shipping Rehearsal Recordings plug-in to make it easier to use when Cloud Sharing. Rehearsal Recordings for Cloud Sharing (category Playback) is available for free download/install,  and is available only in English. It addresses the issues of identifying shared scores and removing versions and parts. Here are the differences between it and Rehearsal Recordings:

1. By default, the export option is set to export scores, not audio files (you can change this in Export Options).
2. The generated scores will have any parts and versions stripped out to reduce storage size.
3. The generated scores will remain open at the end of the plug-in to make it easier to share the scores. (Plug-ins cannot currently access any of the Cloud Sharing mechanisms, so sharing will need to be done manually.)
4. To uniquely identify each generated score in the Cloud Sharing Dashboard, score.Title is modified to be the title (as described below) plus the Instrument or Part name that the plug-in adds to the generated file names.
5. The plug-in creates a non-hidden Text object with the Full Score part name followed by the Instrument or Part name that the plug-in adds to the generated file names, followed by the local date and time when the score was generated, to identify the score on-screen. The date and time are hard-coded, not using wildcards, to avoid time zone changes.

Details and motivations for this plug-in

Title

Cloud Sharing will use whatever is in the score.Title field as the title it displays in the dashboard. If that field is empty, it looks for text with the style Title, and uses the first one of these it finds, even if not in bar 1. If it finds none, it will use the file name with extension but no path. It does not look at title text on title pages.

The plug-in thus wants to put something unique in the score.Title field. It looks for the title text, as described above, and then appends the Part or Instrument name that the plug-in adds to the generated score file name, and places the resulting text in the score.Title field.

If the score had used a \$Title\ wildcard, then the generated score will have the new contents ofscore.Titleas the title. This may or may not be desirable. Similarly, if the Title text had been hard-coded it will not change. Again, this could be good or bad. My feeling is that since these scores are really generated for playback, not publication, this is not a big deal, and a user could take advantage of this behavior, as long as it is understood how it works.

I considered always replacing the score title, if any, with a \$Title\ wildcard and having this be the identifier on screen as well as in the dashboard. I turned away from that because there are a lot of possible things people could have done with the Title and I suspected that modifying it might cause more layout problems than it solved. (I also wanted to add the date and time to the identifier, and this would be hard to do with the Title text). I also thought that once people got used to this, they could decide to use the \$Title\ wildcard or not depending on how they wanted to generated scores to look. The original score title is never changed.

Identifying the score using Instrument name at top left text

Since Rehearsal Recordings always uses the full score, and that name field is hidden by default, I created a new piece of visible Instrument name at top left text at the start of the score that reads Full Score – <instrument or part>. I also added the date and time that the score was created as part of this text, so it would be easy to see if you had the most recent version.

I did not want to modify the existing hidden Instrument name at top left text in case it had been changed by the user, so this just overlays the usually hidden text.

If the text is too close to the Lyricist text, you will need to drag that text down manually.

Could there be options?

Rehearsal Recordings is a shipping plug-in and I do not have the rights to modify it. I designed the changes so they could be applied to all the existing language versions of this plug-in without requiring any translation, which makes it more likely that Sibelius may accept this to be a future update to the existing plug-in. Adding options would require adding text that would need translations so I avoided that.

Conclusion

This plug-in is far from a perfect fix to the problems of sharing these scores, but it should at least simplify the process of sharing the multiple copies and identifying them uniquely.