Musescore/Hauptwerk questions I can't answer for myself -- Implementors?
Please see the "Questions" at the end of https://musescore.org/en/node/270844 and answer here if you know the answers to any. @Jester Musician, this means you in particular (hasn't responded to site email), but others who have touched this, or are familiar with the total content of MS, might be able to help.
Comments
Like all smug presenters, I have (after research and experimentation, though), answered my own questions, and they raise issues about what, if anything, we should say in the Handbook about "Hauptwerk and MuseScore". While, in fact, MS MIDI output certainly can drive a MIDI-eating program via loopback, the amount of Hauptwerk customization needed is daunting. The reason JM's (@Joker Musician, hasn't responded to email) "method" is as simple as he originally described (of late fleshed out by me) is that the punch line is massive customization he performed behind the scenes, whose end-state he captured in the Hauptwerk Backup File (.gz) that he provides (but doesn't elaborate).
Well, what he apparently has done is reorder the channels of the manuals and pedals to correspond to the order in the XML file (something easily done in the same Hauptwerk dialog by which you connect hardware MIDI controllers to them), and, and this is the kicker, assigned numbers and a nonstandard (but available) control mode to all the stops and couplers .... oops, stops and couplers in what instrument? St. Anne's, Moseley, of course. And it works. And it happily seems to be so that reassigning them doesn't lose the built-in settings for playing midi files (which also implies that you can't play a midi file of the "hacked" MuseScore on the instrument).
But if you wish to support some other organ, you have to reconfigure all of its stops and couplers to comply with whatever ordering you invent for your XML file. None of this is undefined or impermissibly tinkering with Hauptwerk internals—Hauptwerk provides all this flexibility, but this is a complex and lengthy process that requires a large amount of explanation that JM didn't hint at. At any rate, "First, reload this .gz HW backup I provide", as JM claims, "just ain't so" , unless St. Anne's is your sole destination.
On the other hand, if you're willing to forgo score-directed setting of stops and couplers, you can forgo his .gz and reroute the manuals yourself (not particularly hard, and can be readily documented) and set registrations by hand, which gives you the added advantage that the "Reset vs. Note Entry" problem is solved: you will be able to hear notes as they are entered. But there is no particular advantage to playing a complete score, registered, from MuseScore as opposed to a recording of it (although changing registrations in real time is much harder with a mouse than with two hands, although HW or instrument-native simulated pistons can help).
So I am sort of in a quandary about whether this "hack" is worth explaining at all. It's pretty neat to hear the St. Anne's as you work on a score, and you don't need my private midi-file-processing tools, but I'll take my midi-processing tools over this solution as the best means to a finished performance.
Note also that there is a now-reported bug whereby using MIDI connections with MuseScore, on Mac at least, causes it to crash on exit.
In reply to Like all smug presenters, I… by [DELETED] 1831606
So there are really levels of using the JM technology:
How many of the last three should be documented?
And if that wasn't enough for one day, if you're not concerned about score-directed registration (setting and changes), you don't need his or any XML file at all, and if you can set up the manual/pedal routings in the "Keyboards dialog" yourself, you don't need his saved environment either. And by virtue of those freedoms, you're not limited to St. Anne's (although she has a pretty good organ fugue)! That is, once you have enough understanding to execute this process knowledgeably, you don't need JM's magic at all. You can set up any single-channel instruments in the right clefs with no transposition, (e.g. oboe, oboe, cello), make sure in the mixer that they really go to channels 1, 2, and 3, (or 1, 1, 3, or 2, 1, 3 depending on hand disposition) and go to town, even hearing notes as you drop them because there's no general reset. Of course, you do have to set up the loopbacks/IAC buses, and point Musescore and Hauptwerk to them, and, like human organists, set up your registrations. But no special files are needed. The big advantage bought by JM's files is UI-easy score-directed registration control (not a small thing), but the extension of that to any other instrument is the duplication of his work for it.
This needs an entirely different documentation strategy, and I hope to follow it. Simply controlling the keys and pedals of a multi-channel Hauptwerk (or Grand Orgue) instrument in the new (2.2-up) MuseScore is not difficult; you configure the VPO app to listen to MS-compatible channels (which can be easily explained), and arrange your MuseScore staves in that order, and in MS3, fiddle, as it were, with the Mixer Channel setting, and set initial registrations manually, no special files or instruments needed. But if you want to put registration and manual-switching controls in the score, you will need to define a "supplementary instrument" XML file with named "MIDI actions", and to configure the stop controls in the VPO to concur with it. What we provide is a sample XML file for St. Anne's at Moseley, and a compatible saved Hauptwerk environment with these configurations made (so you can inspect the Hauptwerk control dialogs in question), and they all work together. No matter what you do, you will have to learn to create and manage MIDI loopbacks with Apple's utility applet or the third-party Windows tool, and lash MuseScore and Hauptwerk together with them (and watch out for and suffer current bugs in MS in this area).
I will re-document this this way.
The only way I can think of to achieve any sort of portability in score-directed registration is to use pistons, one of the few features common to most organs. If Hauptwerk allows control of pistons using MIDI, it's likely that the default settings for all organs use the same MIDI command to activate pistons, which would mean you'd need only one instruments.xml file to control all Hauptwerk organs. You'd still need to set the pistons on each organ the way you want them, but you wouldn't have to punch the buttons as the file plays, and Hauptwerk has more piston capacity than I can imagine anyone needing in a single piece and, if I remember correctly, the ability to save and reload those settings easily. You're still restricted to the number of manuals on the smallest organ you want to use, but using (for example) a choir to great coupler with all the stops for the great closed is a potential workaround in at least some cases.
This idea won't help me (I won't bore you with the details of why), but something I -- and many others -- would find very useful is to set the MIDI actions property of staff and system text arbitrarily (see https://musescore.org/en/node/103761). This would allow me to control the one organ I actually need to control (Hauptwerk makes creating my arrangements more pleasant, but isn't strictly necessary) far more easily than altering the exported MIDI file in an external editor.
In reply to The only way I can think of… by nhampton
Organ registrations are not, in general, no pun intended, portable to start with. In the real world, organists must not only adapt the seeming sections of a piece to the resources on hand (and foot) in a particular organ, but decide whether the piece is playable at all on that instrument. For instance, many small instruments do not have the 8' and 4' pedal reeds necessary for many cf-in-pedale chorale preludes. I have three major Hauptwerk instruments, representing different eras and styles of organ building. Certain pieces are appropriate for each. Specifying an organ suitable for all classical organ repertoires is extremely difficult and rarely achieved.
Although some of the instruments available for Hauptwerk are classic, old, instruments without pistons, Hauptwerk provides its own pistons (including of some novel types, e.g., "scoped"). I'm not sure whether you can set pistons from MIDI, but I hope not, although I know they can be called from MIDI. I have set some of the pistons on the virtual instruments I have for combinations I need often, and use them manually. I would be deeply upset if running a MIDI file, even my own, mangled my piston settings in any way.
I don't see what kind of portability you want, or is desirable. Organ music cannot be rendered on an organ unless an organist has studied the music and the particular organ and decided which, if any, registrations are best by his or her taste; it is not portable.
In reply to Organ registrations are not,… by [DELETED] 1831606
I think all of the questions I had when I started this thread are obsolete; I figured out everything I needed and wrote the cited section on VPO/MuseScore use to the satisfaction of all, including is originator, @JokerMusician. Any MuseScore or other platform score with instructions for a VPO platform must be for a particular organ on that platform; there is no notion of "generic", and no notion of portability.
I also have a set of home-brew python tools that can add registrations to a midi file, directed by an appropriate "schedule", for performance by Hauptwerk/GO, but there is no notion of portability at work at all. I suppose I should post them to GitHub at some time.
In reply to Organ registrations are not,… by [DELETED] 1831606
Actually, I agree with almost all of this, though I lack your in-depth understanding of the questions involved. I expect that I was unusually clumsy in my language. What I had intended to say is that, while organ registrations are unique to each instrument, the places in a given piece where one might wish to change registration are not (necessarily) instrument-specific, and that one could use MIDI to 'push the button', so to speak, at appropriate places, which would mean that one would not necessarily need to do so during performance, one of the options you listed for managing the problem. Creating an entry in an instruments.xml file which had only the function of activating -- not altering -- a piston in Hauptwerk would allow one to use a single score to operate two virtual organs which were both suitable for a given piece of music. The same MuseScore instrument could also be used to manage a different piece which was suitable for a different sort of organ, allowing one to avoid the work involved in creating separate MuseScore instruments for each virtual organ. My use of the term "portable" was more in the sense of how it is used as a technical term in computer science, and probably ill-advised.
And music can be rendered on an organ without study of the music and the organ. It just can't be done well. :-)
In reply to Actually, I agree with… by nhampton
I understand what you're saying now, and the idea is pretty reasonable --- for instance, taking a Franck chorale full of "Ajoutez Haubois" here and there gets turned into some kind of virtual "abstract registration" that gets specified somehow, and varies by virtual instrument --- Hw piston not the right way --- but there are the principals [sic] of a good idea there .... there is need for a new table negotiated with the virtual instrument. Pistons are not right because whatever pistons it (the MS setting of the piece) arrogated to itself, you would have to set up correspondingly, assuming you had solid ideas for the "virtual registation". But the idea is in the right direction.