grame-cncm / guidolib

Guido project - music score layout engine - music description language

Home Page:http://guido.grame.fr

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fix staff/system size with more notes

Fr0stbyteR opened this issue · comments

commented

Hi there,

I need to fix the size of a staff/system with \systemBreak off, even with a lot of notes in the staff. I understood that guido automatically shrinks the staff to avoid collision between notes, but is there a way (possibly in GR settings via wasm version) to disable the feature and allowing note collision in a staff that does not shrink?

Thanks

commented

With less notes, the size (SVG viewbox) is 622x161
image
With more notes, the viewbox becomes wider (739x161). Thus, the system looks smaller.
image

Are we able to fix that size?

looks like a distribution bug to me:

{ [ a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d a b c d ] }

Without \meter, the engine don't really know where to put line breaks. It also uses the default page format (which is A4).
You can either indicate another page format, put a meter or indicate line breaks manually (which you want to avoid isn't it?).

commented

In my case, I want everything fitting in one system that doesn't shrink, so I don't want to break anywhere. So why with the default page format it can still continue to enlarge its viewBox when putting more notes?

In this case, you can just use a very large page format (e.g. \pageFormat<w=1000cm, h=9cm>)

commented

Yes but I need a system that has a fixed size (width and height), or having a SVG viewBox that is consistent regardless how many notes I put in that system. Changing the pageFormat doesn't really do that.

I can't figure out how you can get a fixed size system regardless of how many notes you put in the system. Either you enforce the size and you potentially get collisions, or you have line breaks (automatic or manual, it doesn't matter) and the height will change.

commented

In software like Finale, the system size can be somehow fixed and collisions are allowed. It could be a nice feature to add then.
image

@Fr0stbyteR I am curious to know the use case for such a feature. I don't believe adding collisions is a feature (trying to solve them is and there are quite a few). :)
May be what you are looking for is elsewhere in the lib?!

commented

Yeah I'm involved in a quite particular case/project where I need to render a score from MIDI played by users. The score need to fit into another UI that has a fixed aspect ratio. So I need to align every score I generated and make sure that they has the same size. I don't care if the user plays too many notes, just need the scores aligned in the UI.

What do you mean by "aligned"? You want the same placement for measure bars for example for two different scores?

commented

One user generates one system of 8 measures each time, another UI will show all the generated scores from different users. I want same width/height/zoom per system each time so that I can align them in another UI properly.

If a user choose to play the MIDI keyboard with his face. I still want to generate a score with collisions, rather than a super small one with another size.

commented

With an extreme case we tested,
this is what I need (I got it by tweaking the SVG):
image
This is what Guido generates:
image

OK, I understand better now. Actually, the guido engine isn't really designed for that. In fact, it's more geared in the opposite direction: to avoid collisions. I think it must be complicated to introduce the type of constraint you need. However, you can probably solve this problem by scaling (a bit like inscore), which would certainly be less clean.
I don't have the time right now to look at possible solutions on the guido engine side. On the other hand, it's open source and if you want to try your hand at it... I could always guide you through the code.