Notation Software Users Forum

Notation Software Users Forum (http://www.notation.com/vb-forum/index.php)
-   Other (http://www.notation.com/vb-forum/forumdisplay.php?f=2872)
-   -   Cruly brackets (braces?) impinge on other staves (http://www.notation.com/vb-forum/showthread.php?t=34244)

dj 02-12-2018 03:23 PM

Cruly brackets (braces?) impinge on other staves
 
4 Attachment(s)
Hi, Reinhold:

I've encountered this today.

In the two attached screengrabs (from two different files), you'll see that a "Pno" curly bracket (brace? -- which is it?) is appearing at the beginning of each system. However, it shouldn't be there.

The Piano system, with its curly bracket, is below each of the staves shown. It is definitely not attached to any other staves.

This appears to be happening to single staff systems which are above the curly bracket. This doesn't appear to be happening to staves below the curly bracket system.

This is new behaviour, of course. I've rebooted my system and tried again and the behaviour persists.

Now, both of the files in question were created with one or more of the new betas. I've tried a couple of older files and they don't seem to show the problem. So, I think it may have to do with changes to the .not format made for the new betas.

I've also attached the two .not files in question. As this is new behaviour, it may just be me.

David

Reinhold H. 02-12-2018 07:15 PM

Re: Cruly brackets (braces?) impinge on other staves
 
David,

Thanks. Should both files show your observation after opening them?

I tried both files and both files look good to me. The format change of the .not file was in a totally different area, and if the format change may create an issue, the files cannot be opened at all. The handling of the brackets is untouched in this version.
The only bracket stuff is related to MusicXML export and import due to the MusicXML protocol needs. But this area is just using existing calls where there has been no change underneath. So, I have no idea what might have caused this strange behviour. Has there been a certain handling before?
Any more ideas would be helpful. I do some more playing with these files tomorrow.

Reinhold

dj 02-12-2018 09:15 PM

Re: Cruly brackets (braces?) impinge on other staves
 
Hi, Reinhold:

I should have specified that the behaviour only shows up when the Part for the individual staff is displayed, in both Page and Window view.

So, if you look at the file This Is The End.not, the Conductor's part comes up as default. Select Clarinet, Flute, Trombone, Trumpet or Tuba parts and you'll see the incorrect bracket.

Oddly enough, Voice, which is above the Piano curly bracket, doesn't have the incorrect bracket.

Nor do the staves below the Piano system.

David

Reinhold H. 02-13-2018 06:37 AM

Re: Cruly brackets (braces?) impinge on other staves
 
David,

Thanks. The advice of the drop down list is very helpful.
As part of the drop down list fixes I had to introduce a file format change in version 3.0.6-059 on June 26th, 2017 which was before the beta test has started. This change probably causes the issue. I know now where to start the investigation. Very good that you found it now before the new version is released :)

Reinhold

Reinhold H. 02-13-2018 11:23 AM

Re: Cruly brackets (braces?) impinge on other staves
 
2 Attachment(s)
David, Sherry,

He is the analysis.

For the Band-in-a-Box feature the part list becomes essential because it will contain the "Biab Takes" which are parts which belong together. A Biab Take is a kind of a package where various staves belong to each other similar to a dedicated arrangement. Generating various Band-in-a-Box accompaniments after another always creates a new Biab Take which is being handled as a part. Selecting certain Biab Takes and compare them is very easy just by selecting the part of the according Biab Take. Also it is very nice now to use the Undo/Redo feature to toggle between the various Biab Takes and compare them.

You probalby ask "why is this feature related to this bracket behaviour?"
The answer is: "this feature requires that the part list is clean and accurate."

My personal opinion is that the part list and in particular the drop down part list never really worked perfect. Up to today, deleting, adding, moving staves and/or parts did not result or not always result in an accurate part list. Dependant on how many changes had been made to the score, the part list showed a status that wasn't accurate or at least accurate enough to be usable for the new Band-in-a-Box feature.

Therefore I added in 3.0.6-062 an audit program to synchronize the part list to the existing staves. This audit or clean up program in principle does:
  • (1) In case a staff exists but no according part, automatically create a part just for this staff
  • (2) In case a part exists where the staff does no exist anymore, simply delete this part

This audit or clean-up program is ONLY executed if a file from a former version (former version <= 3.0.6) is being opened the first time in 3.0.7.

So far the theory. However, the clean-up of the cases (1) and (2) is very tricky because it needs to cover previous situations and is done to a certain extend at a best guess where I know that there is a slip which requires a manual fix.

Actually, here we do not have a new file format for this audit feature. A new identification was introduced with 3.0.6-062 to clearly identify whether the above mentioned audit program should be executed ONCE or not, and never anymore.

The issue with these files in a nutshel is that the audit program could not fix the above mentioned mismatch and a manual fix is required. This is very easy:

  1. Select the Clarinet part from the drop down list (where the two bracket are displayed)
  2. Open Staff/Setup dialog and you see that the Piano RH is at position 1 where as the Piano LH is below (att# 1)
  3. Move the Piano RH down next to the Piano LH (att# 2)
  4. OK
  5. Save the file

and all is OK now. Opening the file in 3.0.6 or before in 2.6.3 shows the accurate part list. This correction can be made in any version.

I have tried to create a situation to build such old file with an inconsistant part list but I was not successful. David, if you have one of these files available which was not yet opened in 3.0.6 beta, I would love to investigate why the cleanup did not capture this situation.

All in all, I believe there is nothing serious here. Nothing is broken but only in a very certain situation the audit program does not caputure the cleanup completely, but only ONCE.
Therefore and because we have this audit program in place through the complete testing and beta testing since 8 months, I will not postpone the release. And, because the part list ever never really was perfect.

Again, David if you have the file from before 3.0.6 beta available this would be great to investigate why the audit program did not caputure this certain case.

Please let me know your opinion.

Reinhold


All times are GMT. The time now is 11:49 AM.

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Notation Software Germany GmbH www.notation.com/Imprint.php