The beautiful thing about FOSS is that it can be forked if the maintainers make things too annoying. And any piece of software that’s valuable enough will generally be forked to remove these annoyances.
Maintainers are aware of this too, so they have two options: (a) limit annoyances to a bearable amount, (b) go closed-source but then improve its functionality so drastically that people still prefer it over the annoyance-free fork.
So what I’m saying is, Muse Group have already been applying pressure. But only as much as people are willing to bear. So far, they’ve struck a delicate balance between true open source spirit and upselling people on their subscriptions. They may misjudge users and throw off the balance in the future. Or they may remain smart about it. For now, I’m happy enough with all the improvements that clicking away the nag dialog every once in a while seems like an acceptable trade-off.
But if it becomes unacceptable, we can still keep all of the improvements up to this point. We’ll just lose proprietary add-ons, which hopefully you’re minimizing in the first place so you have the option to easily make a switch later.
@jofemodo, further to your useful post, about available open-source editions of notational apps, I have tried to install Librescore on Win11, and it doesn’t manage to start correctly the required PowerShell service (updated to latest), therefore it doesn’t install.
After a bit of Internet research, I discovered that there are qualms, about the security of this sort-of parallel fork of MuseScore, basically originated from some kind of institution sponsored by the Chinese government, as it seems, and sharing a significant part of the code with the parent software Musescore.
Users report that has been prone to takedowns, and also to aggressive requests of compensation from certain Chinese actors (?).
I don’t know if all of this is truthful or web babbage, but I clearly decided on the spot to steer away immediately.
I’m now using the 3.7 AKA evolution, thanks to the link from @jofemodo . @Aethermind , i wonder, would it not be useful with a small Romoral keypad for writing notes instead of the qwerty keyboard? How are you going about it? I guess i’ll will automate the “key” key-positions after some usage, but i think that i would find it pleasing with a small dedicated keypad with symbols for note lengths on each key and so forth. One or two encoders could be usefull as well if you could scroll up/down the staff and click to enter note…
EDIT; This is possibly off topic, I’m unsure if one should start a new topic for something like this, or maybe go to another forum. Let me know what you think?
As of now, MuseScore 3 is not implementable directly on Zynthian, but nothing prevents us from using it on a Raspi4 or 5 on Raspberry OS, if the goal is to load the notation app on a Raspberry SBC that usually runs a Zynthian.
Should that be the case, an excellent workflow might indeed be an HDMI touch screen married to a keypad with encoders (like Romoral’s) or a Steam Deck. I am not sure if MuseScore could be operated entirely through cursor keys and rotary encoders, but a probably working solution might be two keypads, with enough keys for key-bound function shortcuts.
I did not think about Musescore running from inside Zynthian, but i can see the beauty in that proposal. I was just thinking about connecting the keypad to my laptop or whatever machine i was writing on, and in that case the mouse and normal keyboard would be available.
A keypad with a game-pad like mouse pad would probably be the ideal companion if normal mouse/keyboard was not available
In my varied experience, writing notated music on a computer has always been a precision-intensive digitising task that requires very accurate pointing, especially in classical music, which often involves complex rhythmic and melodic control of many concurrent parts, aka polyphony, under some capacity.
Using on Dorico or Sibelius a Romoral-like programmable keypad - and possibly also a graphic digitiser with a pointing pen - as an alternative to keyboard and mouse, is a fascinating option which I honestly never considered. I will try and see how it comes together: thanks for the suggestion @core.east.
Ah. no thank you @Kirtai. I ventured a few times in the hardly pleasurable chore of editing something (already written) in Lilypond, and even at this basic level it was slow, exacting and unreasonably time-demanding.
I mean, not that there isn’t an implicit vintage flair, in learning to program your score as if you were working on Music V in the 1970s, but honestly there’s too much valuable to do and learn already, to waste time on a totally outdated notational workflow, that requires you to write your music longhand on paper before (unless you do score digitising of XVI century motets ).
for my part i would need some playback mechanism so that i can here that whatever i entered sounds right, mainly in regards to note length and other rhythmical challenges that i struggle with to learn to write notation. I’m so far really happy with the Musescore 3.7 fork (or whatever it is called)
Indeed @core.east, I agree that immediate visual and audio feedback is essential nowadays, for any kind of music engraving tool that aims at being considered professional.
Personally, I don’t feel any ethical obligation or technical prejudice, to adopt preemptively and unconditionally either the commercial or open-source domain of a given software. Both can be perfectly fine and legitimate, and while sometimes an open free app or tech is hands-on better than its paid counterparts, the opposite can also be true.
Thus, I am totally happy with what MuseScore has given and is giving us generously until now, as a notation program, and use it gladly with excellent results. Nevertheless - on objective bases - is no realistic competitor (yet) for highly developed software like Dorico or Sibelius. This is just a dispassionate appreciation of its technical features, irrespective of how dearly I and we love open software solutions free for everyone.
Far out! Thanks for the info-I had never heard of it before. Here are some links if you don’t want to go through a disambiguation process (I do what I can):
I like the ability to produce output in TeX format.
I don’t know exactly what you mean by “seriously”. Text-based music editors are a fascinating remnant of the early times of information technology, when graphic interfaces where resource-demanding and thus hard to implement, and pointing systems to video positions were rare and expensive. From this standpoint, Lilypond and ABC are operationally similar, with the latter (which I didn’t know about, nice software by the way!) benefiting from a more immediate and stilistically refined graphic feedback. The problem which stands, with this kind of music compiling based on letters and alphanumeric function codes, is that they don’t lend themselves evenly to every genre of music writing.
Composition, by intrinsic nature, requires accurate control in the horizontal domain (time) of the harmonic combinations determined by the concurrency of events, along the vertical axis of the frequency domain (notes). This means that, unless one is working with highly abstract series of mathematically generated and/or freely colliding notes (which is entirely possible, but not exactly a very widespread method), typesetting music with text editors requires that the composer has previously laid out her work manually, or in another digital environment.
In a nutshell, you cannot write a multi-part score with a text-based notation software, because the grammatical and syntactical rules of the piece would be impossible to control vertically and diagonally while entering notes.
In fact, Renaissance composers wrote their intricate polyphony in score, i.e. with interacting voices visually superimposed on the page, but used to release it as separate stripes of autonomous lines, similar to the contemporary orchestral parts. This depended anyway on a combination of performance habits (choirbooks and partbooks), practical reasons (music handwriting and early print technology) and professional concerns (they didn’t want the competitors to discover their highly guarded compositional secrets).
Therefore text-music editors are undoubtedly an interesting resource for music education, and could be employed conveniently to write procedural music generated by automated code, but as a lightweight open-source solution for many kinds of traditional composition they would be quite cumbersome and ineffective.
The thing about ABC notation is that it was not originally meant for software, it’s hand written notation.
It was invented as a way to note down folk music using nothing but a pen and paper. No computer, no special paper with staff lines, nothing but something to write letters with.
So yeah, its use case isn’t for when you’re sitting in front of a computer but rather when you’re out and about and hear or think of a melody that you want to write down right now but don’t have notation software or the like to hand.
Turning it into conventional scores & midi, editors and other tools all came after the fact.
I knew of course of the front-end graphical monitor of Lilypond, named after the famous XVII century organist, harpsichordist and madrigalist from Ferrara.
I used it a few times, to edit Renaissance music, and can confirm that its graphical output delivers neat and elegant scores. The same, and probably more judging from the attached videos, could be said of the ABC notation app.
My only qualm is that when writing highly structured genres of music, that imply some degree of syntactical constraints, having a non-interactive graphical output doesn’t afford you to move things around, across and between parts, as it is generally necessary in developmental monothematic music, like orchestral, chamber and choral works.
These kinds of composition demand a layered visual arrangement (originally the music paper), where you can modify, replicate and migrate entire elements (not just single notes) in a very architectural way, until they meet your expected structural and expressive goals.
Unfortunately, this approach to composition is not strictly sequential, in that you cannot complete it part by part one at a time, but to a certain extent requires you to weave the musical fabric of all voices almost simultaneously.
To this end, writing music on an interactive planar workspace, with immediate acoustic feedback, is a sort of workflow which classical composers would very unlikely be ready to revert from.
Oh, I agree that you shouldn’t use them for composition but for transcribing and “Oh no, I need to write this down right now” tasks, they do wonderfully
Oh wow, I need to defend LilyPond as a tool for composers! I have many years of experience using graphical score editors, and I still recommend MuseScore to music theory students, just because learning LilyPond takes a lot of work and time. But for writing my own music, I strongly prefer LilyPond (via Frescobaldi or just Emacs). Once you learn it, it actually feels closer to the musical concepts themselves than staff notation: you can write what you hear and imagine, without having to worry about how it will be laid out on a staff.
It’s at its best working with music that pushes against conventional notation. E.g., an unmetered Baroque prelude consisting of a single “voice” rolling up and down across the keyboard. In MuseScore and every other program I’ve used, you have to do weird things to achieve this—the music on each staff is interwoven with invisible barlines and rests. In LilyPond, you just write a single stream of notes, rests, and articulations—exactly as it sounds. Then you tell LilyPond how to display it. The music comes first, the notation later. That feels much more correct to me!
… and it lets you define and modify music in whatever arbitrary “chunks” you want. I find it much easier to
modify, replicate and migrate entire elements (not just single notes) in a very architectural way
using a well-structured text representation, compared to a visual score! I definitely understand that it’s not for everybody, but to call it “a totally outdated notational workflow, that requires you to write your music longhand on paper before” is pretty unfair.
There wasn’t on my part any harsh criticism aimed at text-based music editors, of which I openly acknowledged the potential functions in specific use-cases:
Sometimes a step of disambiguation would be needed, for what we approximately call “music” or “composition”, over-generalising their specific meaning under the umbrella of widely encompassing nouns.
For example, as a counterpointer I can tell you that I am fascinated by the idea of laying down a strict or enigmatical canon using only textual strings, that contain the subject and its codas, and maybe this workflow could be stretched with some limitations to writing a fugue, but in both exercises you should have extremely clear ideas (and arguably side notes with schemes) about what you’re going to compose.
I can certainly see the same potential degree of effectiveness for serial pieces, or music consisting of
, and definitely
and existing period works in general.
Thus, it is all down to the application scenario, and to the most useful means for the end of a functional workflow. Undoubtedly, there is also a whole dimension of procedural aesthetics, that is the cultural values implicit in the choice of a given set of tools, but this would expand the boundaries of this topics too much .
. I ventured a few times in the hardly pleasurable chore of editing something (already written) in Lilypond, and even at this basic level it was slow, exacting and unreasonably time-demanding.
).
