Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key, clef and time signature overlap and scores start on top of them when using proportional rendering #91

Open
tilgwullfi opened this issue Sep 19, 2019 · 9 comments

Comments

@tilgwullfi
Copy link

tilgwullfi commented Sep 19, 2019

Tested library versions: v1.6.6 and v167
We are trying to display a single measure of scores but with the default layout settings the scores aren't looking very good:
default

But using different layout settings also doesn't yield a good result. Furthermore force and spring don't have an effect when proportional rendering isn't set...

examples:
force=400; spring=1; proportionalRendering=100
force400_spring1_propRendering100

force=400; spring=5; proportionalRendering=400
force400_spring5_propRendering400

force=1500; spring=2.5; proportionalRendering=100
force1500_spring2 5_propRendering100

@Wah0airo
Copy link

We have the same problem.

@dfober
Copy link
Member

dfober commented Sep 23, 2019

You're using proportional rendering, which is still an experimental feature. When proportional rendering is 'on' (non-null), the values for force and spring are ignored (since there is no stretching).

Instead, the value of proportionalRendering is used to determine the fixed distance between the smallest notes duration (as far as I remember). Note that there is no automatic line break in proportional rendering mode. Note also that elements that do not have a duration don't take place (and thus the collisions); it's up to you to solve them using dx parameters.

I do not recommend using proportional rendering.

@tilgwullfi
Copy link
Author

thanks for your suggestions, that will work too i guess (:

it would help (others) if this feature actually would be marked as experimental .. didn't notice that anywhere

@tilgwullfi
Copy link
Author

but it's still weird that spring and force (without proportional rendering) aren't havíng any effect ..

@dfober
Copy link
Member

dfober commented Sep 23, 2019

Right, the feature should be marked as experimental. Documentation is the weak point (although the language is now fully documented and that's a big step forward :-) I plan to do the same with the programmer documentation (as soon as I find some time).
Regarding spring and force, they do have an effect when proportionalRendering is set to 0.
You can experiment with that using the Guido Editor preference pane or using the 'Engine Settings' tab of the online editor (https://guidoeditor.grame.fr/)

@tilgwullfi
Copy link
Author

i did a bit more testing but couldn't get spring and force to work :/
do they depend on something else? it's just a single measure we want to display and the pagesize is therefore restricted to a minimum

didn't know that there is a online version of the editor, thanks!

@dfober
Copy link
Member

dfober commented Sep 24, 2019

you must use the following API to refresh the graphical representation :

GuidoUpdateGR( GRHandler gr, const GuidoLayoutSettings* settings);

try your example with the online editor: if changing the settings works, there's no reason why it shouldn't work in your application.
The expected values for the settings fields are described in GUIDOEngine.h (https://github.com/grame-cncm/guidolib/blob/dev/src/engine/include/GUIDOEngine.h)

@tilgwullfi
Copy link
Author

thank you very much! that was indeed the missing puzzle piece (:

@tilgwullfi
Copy link
Author

reopening because the issue is still relevant ..
our problem is solved though

@tilgwullfi tilgwullfi reopened this Sep 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants