Native vector drawing with musical anchors — prototype for official MuseScore integration #35243
Replies: 2 comments
|
I have continued improving drawing-mode responsiveness and compatibility with separate instrument parts. Smoother editing: point dragging, transformations, and erasing have been optimized. The latest installed build feels much more responsive in my manual use. The latest corrections preserve drawing proportions and intended placement in the individual parts while retaining the improved drawing-mode responsiveness. Broader testing with different scores and layouts is still welcome. I will continue refining the implementation and sharing the results. |
|
Download available The modified MuseScore build is now available for testing: Download the modified MuseScore build (Windows) This is an independent experimental build based on MuseScore Studio 4.7.5. Feedback on drawing tools, musical anchoring, score layout, and separate instrument parts is welcome. |
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone,
I would like to present a native vector drawing editor that I have been developing in a modified build of MuseScore Studio 4.7.5, and propose it for review and possible inclusion in an upcoming official update.
The idea is to draw directly on the score and connect those drawings to musical positions. A curve, arrow or other graphic can belong to a note, a rest or a rhythmic subdivision, so it can follow changes to the score layout.
This could be useful for contemporary and experimental notation, technique transitions, graphic instructions and other markings that need more freedom than a fixed symbol provides.
What is implemented
Drawing and editing on the score
Musical anchoring and layout
The reflow and continuation tools are implemented, but I would particularly welcome broader testing with different scores and layouts.
Text, symbols and normal score workflow
SVG selection and editing are handled by the drawing-mode tools. Outside drawing mode, SVG placement does not interfere with the normal score-editing workflow: notes and other score elements behind an SVG can be selected. In drawing mode, transparent or unpainted areas allow selection of drawings behind it.
The native implementation stores the embedded SVG artwork and its editable geometry/attachment metadata in the score's
.mscz/.mscxfile. It does not require a separate.musedrawproject or a separate plugin window.These drawings are visual notation; they do not automatically create playback instructions.
Video demonstrations
Freehand drawing
Freehand drawing directly on the score, creating strokes and curves across different staves. Guides show the musical positions available for attaching drawings.
01-freehand-drawing.mp4
Layout adaptation
As measures are rearranged across systems, attached drawings adapt to the new layout. This clip shows drawings splitting and continuing across system breaks.
02-system-reflow.mp4
Point editing
Adjusting an existing curve by editing its points. Individual details of the path can be changed without redrawing the entire figure.
03-point-editing.mp4
Normal score editing
Selecting and editing notes while drawings remain on the score. This clip shows switching between the drawing tools and the normal music-editing workflow.
04-normal-score-editing.mp4
Shapes and arrows
Adding geometric shapes and arrows directly to the score. These tools provide graphical markings that complement the musical notation.
05-shapes-and-arrows.mp4
Text and musical characters
Inserting and editing text in drawing mode, followed by use of MuseScore's musical character picker. Text and symbols can be combined with graphical score markings.
06-text-and-symbols.mp4
External feedback and file compatibility
I shared a build with a university professor, who tested it, gave positive feedback, and reported successfully opening a score saved with it in the official MuseScore Studio release.
That is an encouraging initial compatibility result. This external report confirms that the file could be opened; complete rendering and save/reopen compatibility with the official version still need validation.
The native vector editing and musical attachments belong to this modified build. Preservation of that additional metadata through an official-version save/reopen cycle still needs validation.
Current status
This is an experimental implementation with a compiled Windows portable build. A source patch against MuseScore Studio 4.7.5 is also available for evaluation.
Compilation and static QML checks have passed for the latest changes. I have also confirmed that text and characters work correctly in my manual use of this version. Development has included external feedback, but broader release validation is still needed. macOS and Linux builds have not been validated, and translation coverage outside Portuguese is incomplete.
The current output and parts status is:
I am preparing an update to fix compatibility with separate instrument parts and to broaden validation of that workflow.
With MuseScore Studio 4.7.6 in development, I can check and adapt the integration of these changes to that version, validating the relevant workflows so the implementation works well on the new codebase. The build currently available is still based on version 4.7.5; compatibility with 4.7.6 has yet to be ported and verified.
Proposal for official integration
Would the maintainers be interested in reviewing this implementation and considering it for the next official update, potentially 4.7.6, if it can meet the project's design, compatibility and quality requirements? I am available to work against the 4.7.6 codebase and verify the integration of these changes.
I would welcome feedback on the interface, the attachment/reflow model and the score-file representation. I would also appreciate guidance on preparing the work as smaller, reviewable contributions and on the appropriate release target.
This may complement the existing contemporary music notation palette proposal (#34929). A flexible drawing and attachment layer could support some related graphical workflows alongside dedicated notation objects.
A Windows portable build and the source patch can be shared with maintainers and interested testers. I would be glad to demonstrate the workflow and discuss how to adapt it for upstream development.
Thank you for considering it.
Breno
All reactions