Hi, I attempted to upgrade OSMD to 0.9.5 and I'm seeing some unexpected behaviour that I think is new (but I'm not 100% certain). I think I happened to be on 0.8.7 before.
I'm trying to render MXML data to SVG with OSMD, go through the DOM and add some
The render() call is entirely synchronous, right? It is not having side-effects that show up later? Because it seems a bit like OSMD somehow does another render() pass or something, and re-creates the SVG elements without my custom attributes. But how can it possibly do that when this is all one long sync thread? This problem is weird :/
I'm trying to render MXML data to SVG with OSMD, go through the DOM and add some
data-* attributes to some of the SVG elements, and then immediately serialise with .outerHTML. The bug I'm struggling with is that sometimes the data-* attributes are present in the output - and sometimes they are NOT. There's some race condition involved, probably, but I can't tell what is causing it..The render() call is entirely synchronous, right? It is not having side-effects that show up later? Because it seems a bit like OSMD somehow does another render() pass or something, and re-creates the SVG elements without my custom attributes. But how can it possibly do that when this is all one long sync thread? This problem is weird :/
and yes render is synchronous
not sure what the relevant changes from 0.8.7 onwards could be
Seems to work better without autoResize! Maybe JSDOM isn't as synchronous as it should be? :)
Thanks A LOT (again) for that tip. No idea how much time I would have spent debugging this otherwise..
@sschmidTU in the sheet which has multiple instruments, can't we show one instrument system and hide other instruments? It would be great if we learn the single instrument and in the playback options we can turn on or turn off other instruments' sounds (as a member of the symphony).
hmm never seen that before
oh yeah
multi-measures don't have notes, so avoid checking cursor notes there
(I generated SVGs with some meta data to help cursor movement on the server, but I'm most likely moving back to running OSMD on the client because my poor cheap Heroku server didn't have a truckload of memory and kept crashing.. I'm not going to debug memory leaks that could be somewhere in my code or OSMD or Vexflow or JSDOM..well, anywhere. :/ )
But I might end up with a hybrid solution that prefers SVG from server if it is available, otherwise loads MusicXML and OSMD. :)
I didn't expect getSVGElement() to throw. Seems like a known condition you may want to handle by returning null or something? Don't know what the coding conventions around here are, but I'd expect exceptions only for stuff that's truly unexpected or wrong. If "no notes for a multi-measure rest" is a known thing, returning null and documenting this would make sense to me.
yeah, true that, we should return undefined for multi measure rests in getSVGElement().
@sschmidTU for example some variables
// protected zoomUpdated: boolean = false;
// protected needBackendUpdate: boolean = false;
// protected rules!: EngravingRules;
// protected sheet?: MusicSheet;
// protected graphic?: GraphicalMusicSheet;
// protected drawer!: VexFlowMusicSheetDrawer;
// protected drawingParameters!: DrawingParameters;and the private function reset
I create a class which extends the OpenSheetMusicDisplay.ts and need override some function and needs call these variable. It's wonderful if the lib change the private to protected for extend
for now at least for the variables you can use e.g.
(sheet as any).member to access them.
there is nothing private anymore in OpenSheetMusicDisplay.ts
you're welcome! by the way, it would be fantastic if you considered becoming our sponsor on github :)
https://github.com/sponsors/opensheetmusicdisplay
https://github.com/sponsors/opensheetmusicdisplay
I think I have seen a method with a promising name, but I ended up doing something like this:
let graphicalMeasure = osmdInstance.graphic.getGraphicalMeasureFromSourceMeasureAndIndex(
measure,
0
);
let rect = document.createElementNS(SVGNS, 'rect');
if (graphicalMeasure && graphicalMeasure.stave) {
['x', 'y', 'width', 'height'].forEach(prop => {
rect.setAttribute(prop, graphicalMeasure.stave[prop]);
}
svg.appendChild(rect);and styling the rect appropriately.
I'm sort of happy with the above solution, only complaint is that the lower border is below the bottom line of the system - sort of makes sense because you get the noteheads below the bottom line inside your frame, but it also looks a bit odd.
(This of course requires using the SVG backend too, I don't know how to do it if you use Canvas)
@sschmidTU I think I saw a "render until measure X" parameter mentioned somewhere. Would that be a step towards rendering parts at a time?