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

Very large files do not render entirely in multi-page mode #50

Open
bel28kent opened this issue Apr 29, 2024 · 5 comments
Open

Very large files do not render entirely in multi-page mode #50

bel28kent opened this issue Apr 29, 2024 · 5 comments
Labels
vhv-viz-bug This issue concerns a bug in VHV visualization of kern.

Comments

@bel28kent
Copy link
Owner

bel28kent commented Apr 29, 2024

Files that are very large, like op64 and op66 do not render entirely when the user is in multi-page mode. The user must switch to single-page mode. This seems to be true for files that are more than 200 blocks; using ls -s:

for i in op*/*.krn                 
do
ls -s $i
done | awk ' { if ($1 > 192) { print $0 } } '
232 op64/scriabin-op64.krn
264 op66/scriabin-op66.krn

File that are less than or equal to 192 render okay.

@bel28kent bel28kent added the vhv-viz-bug This issue concerns a bug in VHV visualization of kern. label Apr 29, 2024
@craigsapp
Copy link
Contributor

Are you sure that you did not switch the meaning of multi-page and single-page terms? The default view in VHV is single-page mode, and clicking on the icon below the play button:

Screenshot 2024-04-29 at 11 08 37 AM

will switch to multi-page mode.

There is currently a limit of 100000 virtual pixels for SVG images. This is arbitrary and could be increased to, say, 500000 (this is also a problem for orchestral scores in general). (At some point single-page mode might be too computationally intensive for web browsers with very large SVG images), which is why it was currently conservatively set to 100000 pixels.

A partial solution is that if you shrink the notation size such that the generate SVG image is less than 100000 pixels, the entire work will be displayed on a single page:

Screenshot 2024-04-29 at 11 06 37 AM

In multi-page mode:

Screenshot 2024-04-29 at 11 07 20 AM

There is not a problem, since the smaller pages never get close to 100000 pixels.

Screenshot 2024-04-29 at 11 07 56 AM

In theory !!!verovio: condense auto could be added to the score to hide staves with only rests on a particular line, which would shorten the height of the single-page rendering, but condensing does not seem to be applied to this score (perhaps related a single part with four staves).

@bel28kent
Copy link
Owner Author

I use the terms that appear when the cursor hovers over the button.

When VHV first, opens the icon looks like a triptych and the label says "Multi-page mode" which is the mode in which the problem is occurring.

Screen Shot 2024-04-29 at 5 11 40 PM

When I click the button, I then get the icon of a page with arrows on both sides, and the label says "Single-page mode."

Screen Shot 2024-04-29 at 5 12 49 PM

@bel28kent
Copy link
Owner Author

Is it semantically possible to have a reference record that manipulates the VHV setting when the file is added to the text area, as in !!!VHV: Single-page mode or RDF? If not, then a more simple option is to just add a reference record as a "warning" to the user, as in !!!VHV: View in Single-page mode

@craigsapp
Copy link
Contributor

Is it semantically possible to have a reference record that manipulates the VHV setting when the file is added to the text area, as in !!!VHV: Single-page mode or RDF? If not, then a more simple option is to just add a reference record as a "warning" to the user, as in !!!VHV: View in Single-page mode

There is a way of starting VHV in multi-page mode by adding the parameter &k=p option to the URL. Example:

https://verovio.humdrum.org/?file=beethoven/sonatas/sonata01-1.krn&k=p

which will open up VHV in multipage mode:

Screenshot 2024-05-04 at 3 38 02 PM

Adding some embedded option for controlling VHV from a reference record may be possible, but the general problem is that it may conflict with a user's preferences. The page mode is remembered across sessions on the same browser, so if a user is away of the single/multi page modes and they prefer one or the other, then only have to change it once.

I added some user-interface enhancements to improve use and understanding of single- and multi-page modes:

(1) tooltips have been adjusted:

Screenshot 2024-05-04 at 2 49 36 PM

Extra space after page mode icon needs to be fixed.

When in multi-page mode:

Screenshot 2024-05-04 at 2 50 21 PM

(2) I added a help button to the right of the page-mode icon:

Screenshot 2024-05-04 at 2 51 05 PM

Clicking on this button takes you to the page mode documentation page:

https://doc.verovio.humdrum.org/interface/page-modes

Screenshot 2024-05-04 at 2 52 08 PM

So that will reduce confusion about these icons, and the tooltip in single-page mode gives hints that MIDI playback is better in multi-page mode.

@bel28kent
Copy link
Owner Author

bel28kent commented May 5, 2024

I added some user-interface enhancements to improve use and understanding of single- and multi-page modes:

Yes, I think the new labels are more helpful.

A partial solution is that if you shrink the notation size such that the generate SVG image is less than 100000 pixels, the entire work will be displayed on a single page:

When I try to recreate this, I notice that it only works if you do not used encoded line breaks. If line breaks are encoded and that option is selected, then the notation will only get smaller:

Screen Shot 2024-05-05 at 10 46 34 AM

Adding some embedded option for controlling VHV from a reference record may be possible, but the general problem is that it may conflict with a user's preferences. The page mode is remembered across sessions on the same browser, so if a user is away of the single/multi page modes and they prefer one or the other, then only have to change it once.

I'm worried about the use case in which someone who is new to Humdrum/VHV and found the corpus through a publication or word of mouth tries to view the corpus. If they scroll to the bottom and the file isn't rendering, they might assume that the kern file is broken or the software is buggy without thinking to click on the icons. But I don't know how frequent this use case would be when compared to someone who is an experienced user that wants their preferences remembered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
vhv-viz-bug This issue concerns a bug in VHV visualization of kern.
Projects
None yet
Development

No branches or pull requests

2 participants