Note Range Bug in Staff Style Window

Background- I like to create custom staff styles for each of my first+third party orchestral instruments so that I can cleanly export parts straight from Logic. 

One aspect of that is to assign the correct note ranges for each staff, so that it won't display any Key Switch notes (the "dummy" notes that you push to change articulations on most 3rd party instruments). 

 

The Bug- In the Staff Styles window, if you duplicate a staff, and change the Hi and Lo note ranges BEFORE assigning it to a track's staff style, then Logic will dump those values and return to the default C-2 G8 range. 

 

You can only assign the note values *after* you have assigned your new staff style to the track. 

 

Very frustrating, and a bit of a time waster, since you have to leave the Staff Style window, assign it, then come back, find where ever that new style jumped to alphabetically, then reassign the note range. 

Also, the Staff Styles window is just generally erratic when entering hi and lo values. It seems to only happen on certain staff styles. At times, you can double click to change, at other times, upon hitting enter, it will attempt to rename the staff style instead of editing the Hi and Lo note values.

The Bug- In the Staff Styles window, if you duplicate a staff, and change the Hi and Lo note ranges BEFORE assigning it to a track's staff style, then Logic will dump those values and return to the default C-2 G8 range. 

 

I have experienced this on occasions but it always works if I enter the value the first time instead of click-drag.

Once that is done it is fine.

Eric, thanks for the reply. Are you duplicating a staff style or creating them from scratch?

 

I'll see if I can narrow it down to a repeatable problem.

Steps to reproduce:

 

1) On a software instrument track, open the Staff Style Window from the Inspector.

2) Select a current staff style (i.e. Trumpet in Bb) and Duplicate it.

3) Set the Lo and Hi note ranges in the newly duplicated staff style to something other than defaults.

4) Assign the Staff Style to the track. 

 

The Note ranges will now have defaulted back to C-2 and G8. 

 

Also, if you attempted to type in the note ranges and hit enter, it will actually open the name of the Staff Style for editing, instead of accepting the entered value. 

Hey SRF,

 

Sorry to report that I followed your steps-to-reproduce and couldn't duplicate the bad behavior you described. I also tried your example of setting the hi/lo range before duplicating the style, and everything worked as expected. Also didn't experience the strange naming issue you described.

 

I tried this both in the embedded score editor as well as an independent score editor window, with the same normal results. 

 

Wondering what might be different about our systems such that there's this discrepancy in behavior. That's a rhetorical question, and not to suggest that I don't experience weird staff style behaviors from time to time!

 

Troubleshooting suggestions:  

 

1) Start with a completely empty project (FIle > New > Empty Project) and see if you get the same behaviors.

 

2) In a copy of the project in which you're experiencing this behavior, purge unused staff styles: Select Unused, followed by Cut. Now try creating a duplicate staff style of any of the remaining types and see if the bad behavior still occurs. The idea here is to purge unused staff styles that might have gotten corrupted which can potentially interfere in the way the staff styles editor behaves.

 

Hey SRF,

 

Sorry to report that I followed your steps-to-reproduce and couldn't duplicate the bad behavior you described. I also tried your example of setting the hi/lo range before duplicating the style, and everything worked as expected. Also didn't experience the strange naming issue you described.

 

I tried this both in the embedded score editor as well as an independent score editor window, with the same normal results. 

 

Wondering what might be different about our systems such that there's this discrepancy in behavior. That's a rhetorical question, and not to suggest that I don't experience weird staff style behaviors from time to time!

 

Troubleshooting suggestions:  

 

1) Start with a completely empty project (FIle > New > Empty Project) and see if you get the same behaviors.

 

2) In a copy of the project in which you're experiencing this behavior, purge unused staff styles: Select Unused, followed by Cut. Now try creating a duplicate staff style of any of the remaining types and see if the bad behavior still occurs. The idea here is to purge unused staff styles that might have gotten corrupted which can potentially interfere in the way the staff styles editor behaves.

 

Screen Shot 2017-10-16 at 3.08.57 PM.png

Oh hey Ski, thanks for the follow up. 

 

Well then, it sounds like I've got some system specific problems. A little weird though because it happens on both my desktop and laptop. (2011 iMac and 2015 Macbook Pro)

 

I'll try it in a blank project in the morning and report back.

My first inclination is to think that it's not so much system-specific as it might be project corruption -- maybe a project file common to both your iMac and MPB. But I'll look forward to reading your follow-up on this. Strange stuff! 

Alright, I'm awake and have coffee. About to start from a blank template to see if I can reproduce it. 

 

In the meantime, here's a video of the problem. It consistently reproduces across both machines.

 

Hi SRF,

 

Interesting. I think this points to a corrupt logic preference file (the .plist file). One thing you might want to do is make a copy of your existing .plist file in your main user account. Then initialize the preferences by way of the key command window. This will certainly mess up some of your favorite/preferred settings, which I'll get to in a separate post if necessary. But the idea is to initialize the prefs and then try out the behavior in a brand new blank project.

 

If that doesn't do the trick, you might want to try actually trashing the prefs. Quit Logic, go into the Preferences folder and delete the .plist file. Re-launch and test the behavior.

 

If neither of those operations result in correct behavior, the problem may lie within the user account settings.

Hi SRF,

 

Interesting. I think this points to a corrupt logic preference file (the .plist file). One thing you might want to do is make a copy of your existing .plist file in your main user account. Then initialize the preferences by way of the key command window. This will certainly mess up some of your favorite/preferred settings, which I'll get to in a separate post if necessary. But the idea is to initialize the prefs and then try out the behavior in a brand new blank project.

 

If that doesn't do the trick, you might want to try actually trashing the prefs. Quit Logic, go into the Preferences folder and delete the .plist file. Re-launch and test the behavior.

 

If neither of those operations result in correct behavior, the problem may lie within the user account settings.

That's the weird part. Just by opening Logic in the other user account, it actually fixed it in the main account as well. 

 

I went back and tested in multiple templates and new projects. 

 

I don't quite know why that fixed it, but it did.

Hey SRF,

 

I'll add this to my bag o' tricks for future troubleshooting.