Astra-assisted Dorico MCP tests: successful edits, but questions about score access

Dorico
1

I’ve now tested the third-party Dorico MCP server discussed here, using the Astra model through OpenAI’s Codex desktop app and disposable scores in Dorico 6.2.30. I thought the results might help move this discussion forward.

What prompted these tests was my experience using Astra for music tasks. Its ability to read notation, identify possible discrepancies, and reason about musical details has felt substantially stronger than that of previous models I’ve used. That is my practical impression, rather than a formal comparison, but it has made AI-assisted score checking much more useful to me.

The next question was whether those capabilities could translate into reliable, verifiable corrections within Dorico.

The initial MCP integration needed repairs, including connection handling and some command definitions. After those changes, we successfully demonstrated pitch changes, articulations, dynamics, a crescendo, saving and reopening, and Undo.

The remaining difficulty is reliable musical targeting and verification.

In one controlled test, Astra, operating through Codex, visually selected a starting note and then used MCP commands to navigate to another bar and note. It changed that note from D5 to D6 and restored D5 through MCP Undo. Dorico’s display confirmed both changes.

However, the getstatus and getproperties responses were identical before the pitch change, after it, and after Undo. Those queries therefore could not independently verify the pitch correction.

This seems closely related to the earlier discussion about accessing score data through the Remote Control API. Could the Dorico team clarify:

  • Is there a supported way to read a selected note’s pitch, instrument, rhythmic position, and event IDs?

  • Can a client reliably select an event by flow, instrument, bar, and beat, without first selecting it on screen?

  • If these capabilities are not currently exposed, could they be considered for future API development?

Our tests do not prove that every possible approach is unavailable, and I would welcome guidance on anything we may have missed. Some problems clearly belonged to the third-party server and were fixable without changes to Dorico.

There is a practical efficiency issue here, too. Our current hybrid approach still needs visual selection and checking, so we have not demonstrated a speed advantage or measured any reduction in AI subscription usage. Reliable targeting and readback could allow reviewed corrections to be applied and verified in batches, potentially reducing both time and repeated AI interactions.

For now, AI-assisted auditing followed by manual correction appears to offer the best balance in my workflow. But Astra’s musical understanding, combined with these successful editing tests, makes me hopeful about what a more capable integration could accomplish—with the musician reviewing the judgments and retaining control.

An official MCP server would be welcome, but a documented interface providing precise musical access would also let independent developers build dependable tools. Even richer read-only score access would be a valuable first step.

I would be happy to provide the disposable examples, command logs, and before/after query comparisons.

Martin Wolk

2

I can make these answers brief:

No.

No.

Possibly. Though the Remote Control API is not intended for generalised access to and automation of editing in Dorico: it is instead targeted at providing access to Dorico’s command system, for triggering commands, and managing UI state. It’s more useful for devices like the Stream Deck than for general interaction with the software.

3

Daniel, thank you for the straight answers — they settle a question I had measured from the outside and were not sure of.

I am building an application for orchestral template work around Vienna Ensemble Pro, and its relationship to Dorico is exactly the one you describe: Dorico is the clock and owns the playing; my side only ever follows it and triggers it. Today I follow it by reading the window title (flow and project, which is more than enough for cue-grain work) and I trigger it through MIDI Learn on the command tree. Both work well, and the Remote Control API as you describe it — commands and UI state — is the surface I would rather trigger through, since it needs no virtual MIDI port and cannot double-fire against a control surface. So this is not a request to turn the API into a score editor. It is two small read requests on the UI-state side, in the order I would value them.

1. A read of the current selection. Not the score — just what the user has selected on screen: the flow, the instrument/staff, the bar and rhythmic position of the caret or the first selected item, and the pitch(es) if notes are selected. This is UI state in the same sense the existing status frame’s inPlayback is: it describes what the user is looking at, not the document. For a follower it turns “the composer is in flow 3” into “the composer is at bar 42 of flow 3”, which is the difference between preparing the right cue and preparing it at the right moment.

2. The playback position in the status stream. During playback, the current bar and beat (or a timeline position in seconds) pushed at whatever rate is cheap — the way inPlayback already flips. This is the one thing a follower cannot get any other way: window titles do not move during playback, and MTC needs a third-party plug-in in the project. A position field beside inPlayback would make the existing status frame a complete answer to “where is Dorico now”.

Neither touches the document, neither selects or edits anything, and both are pure reads of state the UI already holds. If either is on the “possibly” list, a word on which, and roughly when, would help me decide what to build against. And if the answer is that neither fits the API’s purpose, that is a useful answer too: I will keep following the window title, which has served me faithfully.

With thanks for Dorico, Emmanuel Cambier

4

Thank you, Daniel, for the clear answers. That helps me understand the intended scope of the Remote Control API and where our experiments reached its boundaries.

Thank you also, Emmanuel, for articulating the narrower requests. I particularly support read-only access to the current selection’s musical details: flow, instrument or staff, bar and rhythmic position, and pitch.

In our test, Dorico visibly confirmed a pitch change and its restoration through Undo, but the status and property queries could not distinguish those states. Selection readback would help verify supervised edits, even with the musician establishing the selection on screen.

I appreciate that any extension needs to fit the API’s purpose and the team’s development priorities. If richer selection information can be considered within its UI-state role, it would be a valuable step for this workflow.

Thank you both for helping clarify the possibilities.

Martin Wolk

5

I would be very much interested in hearing in detail about what exactly you were able to do with these methods beyond casual experimentation. In which way were you actually helped with musical work in a meaningful way?

My curiosity is genuine, but full disclaimer: I am deeply sceptical about the capability of such models to evolve towards any applications that are in any way even just adjacent to making informed expertise decisions.

6

Dear Alexander,

Thank you for asking. Your distinction between experimentation and meaningful assistance is a fair one.

I am not a professional engraver. I have used Dorico extensively for about five years as a hobbyist and flute player, playing in duets, chamber groups, flute ensembles and low-flute ensembles.

My initial aim was personal: to enter music from my library into Dorico so that I could study it and play along with Dorico/NotePerformer. Notation entry and correction have always been the bottleneck.

I have tried several OMR applications and settled on PlayScore 2. It can produce excellent results, but its output still needs substantial checking. Until recently, my attempts to use AI for that checking had not been dependable enough to be useful. My experience with Astra over the past week has been markedly better, although I would not claim that it reads perfectly or replaces informed musical judgment.

Here are the practical results so far:

  • Checking OMR output against a PDF. It has compared MusicXML with scanned parts and produced correction lists identifying the part, bar, original reading and proposed correction. Findings have included wrong pitches and accidentals, octave errors, missing or shortened notes, and missing or incorrect articulations, dynamics, slurs, hairpins and expression text. Approved corrections were then applied to separate MusicXML copies, with a change log. This gave me a specific, reviewable list to work through.

  • Checking arrangements and transpositions. In a low-flute arrangement, it helped distinguish intentional octave changes and redistributed phrases from discrepancies needing attention. It checked instrument transpositions and ranges, and examined proposed substitutions against the simultaneous sounding pitches in the other parts. I retained responsibility for approving those musical choices.

  • Analysing engraving style and preparing settings. It examined a reference scan’s typography, spacing and notation details, proposed available-font approximations, and generated .doricolib files from an existing library. We subsequently applied and checked settings in Dorico and created reusable project templates. I would describe this as assistance in approximating a style, rather than exact identification of the original fonts or a substitute for an engraver’s eye.

  • Checking the results of import and export. We used structural checks and musical comparisons to look for altered pitches, durations and markings after processing. This proved useful because an apparently successful import did not always preserve everything: expression text and some hairpin endpoints needed further attention. The work has produced usable Dorico scores and parts, rather than stopping at advice or a demonstration.

There have also been significant limitations:

  • Human review remains necessary. Some source readings were ambiguous, and I had to resolve them. I have also corrected the model’s readings. A structurally valid MusicXML file is not proof of an accurate transcription.

  • Direct interaction with Dorico has often been extremely slow. Screen-based selection, dialogs and macOS accessibility behaviour have required repeated attempts and sometimes my intervention. In those situations, making the edit myself would have been quicker.

  • The Remote Control API does not provide the musical access we hoped for. Daniel’s clarification establishes why our command-based tests could make edits but could not independently read back the selected pitch or target an arbitrary musical location.

  • Engraving still needs visual proofing. Generated library settings can be overridden by project-specific formatting, and successful import of a library does not establish that every page looks right.

The meaningful benefit to me has been the combination of detailed checking, explicit correction records and preparation of files and settings I can inspect and use. It has reduced the amount of work I have to begin entirely from scratch. I have not conducted a formal accuracy comparison or measured an overall time saving, and some automation attempts have plainly consumed more time than they saved.

Your scepticism about informed expertise is understandable. My narrower observation is that this model has become useful to me as a supervised assistant in real music preparation. That is already a substantial change from my earlier experience, even though its limitations remain apparent.

Best regards,

Martin Wolk

7

There was a recent post on Reddit claiming that Astra is very good at OMR. I tried the free version of chat GPT on a couple of pdf files (piano pieces by Ives and Schoenberg) and was not impressed. Has anyone had OMR experience with Astra?

8

Dear Stephen,

Would you be willing to share a single, high-quality scanned page from either piece? I’d be happy to test Astra on it directly and attempt to produce an editable Dorico file.

I would share the resulting file and an account of any errors, ambiguities and manual corrections required. That would give us a concrete example to assess against the original scan, whether the result is successful or exposes limitations.

Best regards,

Martin Wolk

9

Thanks Martin - here is a page of Schoenberg’s opus 25. Yes, I’d be really interested to hear how Astra does with this!

4-SchoenbergOp25-Gavote.pdf (752.4 KB)

10

Hi Stephen,

Thank you for sharing the page. The first test has been encouraging!

Astra read the scanned score directly and generated MusicXML, then used Lua scripts to import and format it in Dorico. No separate OMR application was used.

On reviewing the first result, I found only beaming, stem-direction and clef-placement issues. A second pass corrected most of these, including the beam spanning the system break. The rolled-chord beaming and stem arrangement in bar 4 still need attention, so this is an editable working draft rather than a publication-ready reproduction.

The attached ZIP contains the Dorico file, MusicXML, process notes and examples of the Lua corrections. A round-trip check confirmed that all 110 pitched notes retained their pitches, positions and durations through the Dorico workflow. That checks preservation during import and editing—not independently the accuracy of the original transcription.

The recorded first-pass work span was about nine and a half minutes, followed by about twelve and a half minutes for corrections and verification. These are elapsed working times, not measured model compute time.

One useful lesson: Dorico’s import settings were ignoring explicit beam and stem information. We have now added a separate visual inspection of beams, stems, clefs and system breaks to the process.

I’d be very interested in your assessment, especially anything I have missed.

Next up is to create a doricolib file to get closer to the original engraving style. I don’t have time to do that now, but I will post when it is done.

Schoenberg-Astra-v3-forum-files.zip (1.6 MB)

Best regards,
Martin

11

I’d like to start with expressing my gratitude for your willingness to let us have a very close look at your workflow. It really is appreciated, and I would be very interested in continuing this discussion for a while longer, on this hands-on level.

That being said – and I apologise for my biases being very much on display here, without any subtlety – …, at any point during what appears to be a quite deliberately structured review process, did you have an impulse to, well, just check the pitches against the source? By which I mean (and again, I do not intend to be rude, but with all the explicit steps listed in your documentation, it seems like such a weird omission…), did you at any point just proof-read the resulting notation against the original PDF, instead of trying to once more run chatbots and scripts on it?

12

I’m extremely interested in this discussion, though my use case is a little bit different. A friend of mine who is a coder has been helping** me write a program that compares a completed PDF (exported from Dorico) against a scan of the original source material to check for errors and deviations.

**”helping” is doing some heavy lifting here. I describe what I want, and he writes it. It’s great to have smart friends. :smiling_face_with_sunglasses:

My understanding is that he’s using machine learning for this, though the particulars are beyond me.

13

Alexander,

Thank you. Yes, I did compare the pitches and rhythms against the original PDF. I neglected to say it, but improving notation accuracy during my PDF > Dorico process has been my primary objective.

In fact, one of my first experiments with Astra was to recheck a score I had prepared using my usual process:

PDF > MusicXML with PlayScore 2 > Dorico > proofreading and engraving adjustments

Astra found the errors I already knew about, as well as several additional errors I had missed.

Of course, one page and one human review are not a rigorous evaluation of OMR accuracy. I hope we will see systematic testing by OMR researchers, perhaps by Jorge Calvo-Zaragoza and the Pattern Recognition and Artificial Intelligence Group at the University of Alicante.

If Astra is available on your account, I would be very interested to learn what you make of it from a professional engraver’s perspective.

Best,
Martin

14

Sorry for the late reply - many thanks for this project Martin. One of the reasons I’m interested is because of the opening question I asked in the August 1 Scoring Notes podcast last month, whether you could hold up a page of music to your computer’s camera and have an AI transcribe it for you, with accurate and beautiful playback. It looks like we are really getting closer.

I don’t imagine that this is possible with a full orchestra score anytime soon, but I could be wrong. Just for the heck of it, if you have time, would you be willing to try the first page of Schubert’s Unfinished Symphony?

Schubert_Sinfonie_Nr._8_h-moll-page1.pdf (97.2 KB)

15

I fed the Schoenberg page above to Claude Cowork Sonnet. It said it could convert it but well over 20 minutes later — ie, far longer than it would likely take to copy the page accurately by hand — it was still thinking. I stopped Claude.

16

Stephen,

Astra was able to complete the challenge in two parts. I first asked it to create both a musicXML file and a LilyPond file from the PDF, which it did in about 6 min.

Since this is the Dorico forum, I asked it to continue and import the musicXML file into Dorico. It ran into some minor formatting issues and took 16 min to complete the task because it has to interface with Dorico through “computer use” - literally taking control of the mouse and using screen capture.

I have attached all relevant files, including a README.pdf which was originally a README.md file generated by Astra in the first part of the exercise. I also created a full transcript of the chat and description of Dorico’s methodology here.

README.pdf (21.3 KB)

Native import proof.pdf (41.7 KB)

Schubert Unfinished - first page.musicxml (70.5 KB)

Schubert Unfinished - first page.dorico (1.5 MB)

Schubert_Sinfonie_Nr._8_h-moll-page1.pdf (97.2 KB)

17

Thanks Martin - very impressive! When I played it on NotePerformer, the strings used solo samples instead of section players. But everything else looks good, there are part layouts and it seems like the transposing instruments are handled correctly.

If you have time could I ask for one more attempt? I’m curious about the transposing instruments, so here’s the opening of the second movement. No worries if you don’t have time to mess with this, and thanks again!

Schubert8-opening-of-mvt-II
Schubert8-opening-of-mvt-II1920×1366 513 KB

18

Stephen,

The pasted image resolution was too low for Astra. I downloaded the movement II score (same edition) from IMSLP and extracted the page (attached). Same steps -

Part 1
PDF reading → MusicXML → LilyPond/PDF → comparison and corrections

Part 2
manual importing of musicXML file into Dorico. I made no changes. Playback seemed OK.

I typically work with flute ensembles, so I don’t know if the string sections were done correctly.

The Dorico step is too expensive for me now, so I chose to do it manually for the purposes of this experiment. Although Astra can plow through it, it takes too long and results in a clunky back and forth with requests to me for manual mouse clicks and actions that it doesn’t have access to.

I’ve also found that Astra’s work with the Engraving mode is sub-par, costly, and not worth it for now. I does fine job outside of Dorico by generating doricolib. files which I can apply manually, but does not do well with computer use in Engraving mode or in Layout and Engraving options dialogs.

So, my workflow will change. Until Dorico enables better control (which, I take from Daniel’s response, will be a long time or never), I will adopt the workflow of this particular experiment for my next arrangement.

I am a hobbyist. I don’t have an editor other than myself and I continually spot overlooked errors in my existing files. The workflow of this experiment represents a dramatic leap towards more accurate future editions of my adaptations and transcriptions.

Keep me posted on your efforts.

Martin

Symphony in B minor, D. 759 — II.dorico (1.3 MB)

README mvmt II.pdf (27.0 KB)

Schubert Unfinished - first page mvmt II.pdf (98.9 KB)

Schubert Unfinished - II bars 1-14.musicxml (79.4 KB)

Schubert Unfinished - II bars 1-14.pdf (56.7 KB)

19

Thanks again Martin - indeed, the transposing instruments are working perfectly. And for whatever reason, now the strings are playing with section, rather than solo, sounds. Really impressive!

20

Claude Sonnet is not for complex tasks. I have barely scratched the surface on this, but I’m frankly amazed at what the higher-level Claude models can convert from music to … well, anything else I want. You simply need to pay :wink: