grame-cncm / guidolib

Guido project - music score layout engine - music description language
http://guido.grame.fr
Mozilla Public License 2.0
152 stars 34 forks source link

Fix staff/system size with more notes #172

Open Fr0stbyteR opened 1 year ago

Fr0stbyteR commented 1 year ago

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

Fr0stbyteR commented 1 year ago

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?

arshiacont commented 1 year ago

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 ] }
dfober commented 1 year ago

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?).

Fr0stbyteR commented 1 year ago

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?

dfober commented 1 year ago

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

Fr0stbyteR commented 1 year ago

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.

dfober commented 1 year ago

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.

Fr0stbyteR commented 1 year ago

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

arshiacont commented 1 year ago

@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?!

Fr0stbyteR commented 1 year ago

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.

arshiacont commented 1 year ago

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

Fr0stbyteR commented 1 year ago

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.

Fr0stbyteR commented 1 year ago

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

dfober commented 1 year ago

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.