What would you expect? If you add a key change mid-score, then go back and change the initial key signature, that new key stops at the key change. Similar, if you add a staff type change, then go back and change the initial staff properties, I expect that to stop at the staff type change.
Perhaps you were thinking that using Staff Properties on some subsequent measure would be the way to make the property changes for the staff type change element itself? It isn't. Use the Inspector for that. Staff Properties always affects the global staff properties, and those are only in effect until the first change.
I now understand how this works. The way I would expect it to work. If you use staff properties to change the number of lines, the staff is adjusted and the inspector overrides staff properties. It's unfortunate that I have create issue reports to understand how some things work in version 3.
When the first alpha came out I made some bug reports I was certain were applicable and not previously reported. I used the technology preview forum to comment on the alpha release and I think one of my forum posts got a response. Among those reports was a bug that the person who finally submitted it a couple of days ago was shocked that no one had previously reported it. This was only because no one had in any way responded to my forum post.
I understand your frustration. I remember the posts you mention, there was a lot of good information there, and much of it has already been taken into account, but I'm sure some things fell through the cracks, because the forum just isn't as good as the issue tracker for, well, tracking issues :-). So indeed, do keep using the issue tracker to report bugs. But no, I would not say you have to - or should - create issue reports to understand how something works. The forum remains the better place for that. Nothing has changed in this regard - issue tracker to report bugs, forum to ask questions.
Of course, it's possible some questions you asked in those posts weren't answered, that could be in part because no one reading the forum actually knew the answer. Sometimes only Werner, or perhaps some contributor who added the code a couple of years ago but doesn't hang out in the forums, is the only one who really knows. But gradually we're figuring things out. I'd say at this point I have a pretty good idea about how most new things work, and I'll be putting together some starter documentation over the next few days. Meanwhile, just continue to ask on the forums if you want to know how something works, and I'll do my best to make sure all such questions get answered.
Comments
What would you expect? If you add a key change mid-score, then go back and change the initial key signature, that new key stops at the key change. Similar, if you add a staff type change, then go back and change the initial staff properties, I expect that to stop at the staff type change.
Perhaps you were thinking that using Staff Properties on some subsequent measure would be the way to make the property changes for the staff type change element itself? It isn't. Use the Inspector for that. Staff Properties always affects the global staff properties, and those are only in effect until the first change.
I now understand how this works. The way I would expect it to work. If you use staff properties to change the number of lines, the staff is adjusted and the inspector overrides staff properties. It's unfortunate that I have create issue reports to understand how some things work in version 3.
When the first alpha came out I made some bug reports I was certain were applicable and not previously reported. I used the technology preview forum to comment on the alpha release and I think one of my forum posts got a response. Among those reports was a bug that the person who finally submitted it a couple of days ago was shocked that no one had previously reported it. This was only because no one had in any way responded to my forum post.
I understand your frustration. I remember the posts you mention, there was a lot of good information there, and much of it has already been taken into account, but I'm sure some things fell through the cracks, because the forum just isn't as good as the issue tracker for, well, tracking issues :-). So indeed, do keep using the issue tracker to report bugs. But no, I would not say you have to - or should - create issue reports to understand how something works. The forum remains the better place for that. Nothing has changed in this regard - issue tracker to report bugs, forum to ask questions.
Of course, it's possible some questions you asked in those posts weren't answered, that could be in part because no one reading the forum actually knew the answer. Sometimes only Werner, or perhaps some contributor who added the code a couple of years ago but doesn't hang out in the forums, is the only one who really knows. But gradually we're figuring things out. I'd say at this point I have a pretty good idea about how most new things work, and I'll be putting together some starter documentation over the next few days. Meanwhile, just continue to ask on the forums if you want to know how something works, and I'll do my best to make sure all such questions get answered.