The way I think of an accident type or class is that there is also the possibility of using a “CustomAccidental”. Nothing prevents that. The Notenames will always be the same, even if you choose a different tunning (not A=440hz).
Your example is a good one, and we can find more than one solution to work with that kind of music.
Nowadays we don’t have a problem with representing those symbols in MusicXML or LilyPond. With LilyPond, one can use the ekmelily extension. And Standard Music Font Layout / SMuFL is also quite good, the Bravura font is used by Dorico and other softwares.
Dorico does not indicate ‘double-sharp-down’. I think this is OK, because I think ‘c with double-sharp-down’ should be notated as ‘d with natural-down’. So my new function will do this automatically when entering pitches by MIDI note pitch numbers, as in the example code above. Please let me know if these notations are acceptable. If not, I could change it, or write a subfunction to decide the enharmonic spelling by looking at the next pitch.
Thanks again! I think writing some classes with methods will not be too difficult once the basic things about pitch notation and rhythmic notation are fixed.
Although I think the rhythm part still needs some work to have the basic functionalities as the pitch materials. There’s where some tricky things start to appear.
Let’s keep this conversation going on here or GitHub (or zoom?) with some people that do some work along those lines.
Thanks for pointing that out! I will correct my example with a comment and thanks to you!
Glad to hear it.
That is my intention! SC users do not need to know MusicXML. My intention is to let sc-users create their own score using events and arrays according to the notation guidelines. My function (or later my class) will convert it into a musicXML file, and the sc-user can see his score in his preferred notation software!
What I need to hear might be the convention of the notation guideline from different perspectives.
Yes, the rhythmic part should be reworked.
I intend to implement triple dots. (Dots, Double dots are currently implemented.)
I think the easiest way is to write the music in ‘senza-misura’ and then let the notation software rebar the music. Otherwise, the user can copy and paste the music into the bars defined by the time signature.
But simply adding triple dots is not enough!
Could we discuss this on this forum first?
Zoom may not be as productive as my English is not that fluent, especially in listening and speaking. Github is also a good place to do it, but I think a draft of some classes should already be done for it. I will try to attend the next developer meeting, even if my English is not good enough. Let’s talk about moving to gitHub around the next developer meeting! I think a draft of the classes will be ready in a few weeks.
I’m busy with other things, but I have fun playing around with similar things in Haskell. I’ve been experimenting with different approaches around the same exact problem you’re working on.
One of the solutions for durations is something like
type Division = Integer
type Dots = Int
type Rq = Rational
data Duration where
Duration :: { _division :: Division,
_dots :: Dots,
_multiplier :: Rational}
-> Duration
deriving (Eq, Show)
makeLenses ''Duration
class HasDuration a where
_duration :: a -> Duration
instance HasDuration Duration where
_duration = id
dotMultiplier :: Dots -> Rational
dotMultiplier dotCount = n % d
where
n = 2 ^ (dotCount + 1) - 1
d = 2 ^ dotCount
durationToRq :: Duration -> Rq
durationToRq d = (1 % (d ^. division)) * dotMultiplier (d ^. dots) * (d ^. multiplier)
The division is the note value. The number of dots alters the duration according to the dotMultiplier function. _multiplier is there to be used when the duration is contained inside a tuplet.
Logical ties, used to duration such as a quarter-note tied to a 32th-note, for example, is another case we need to take care of.
I’m not 100% sure how tuplets work in MusicXML, but I believe it should have a tag, and would work just like a span, such as a slur. Right? The difference is that it will be a sort of container that will alter the _multiplier for each duration. That’s one of the solutions.
Some fun edge cases are nested tuplets and metric modulations… (Lilypond supports the former nicely but I had to write some functions to display and perform the metric modulations !)
IIRC Lilypond will not automatically break up notes to flow across barlines - if you type a4 a4 a4 a2 for example it won’t split the final half note into two tied quarters.
If you are curious to play around there is an online editor for Lilypond here: https://www.hacklily.org/
Yes, I know that. But it would be nice to come up with a model that will work well with Lily ad musicxml. Maybe Abjad did a mistake mirroring LilyPond data types. As a matter of fact, MusicXML can’t be forgotten.
Right now I’m trying to figure out if MusicXML is capable of doing all those things. It’s a bit arcane and weird, and very messy. But probably not impossible to do it.
Some of my experiments (just the first sketches) are already doing the basic job, but there are always “edge cases” when we mix logical ties and tuplets.
Thanks for a lot of information.
I am ashamed that I do not understand Haskell, but I will try to learn what I can take from it.
I feel it somewhat strange that sc-users do not make the libraries to get scores for sclang, but for other languages…
Anyway…
Yes, it is!
I have implemented simple tuplets and nested tuplets. In Dorico and Finale, both are decoded and appear as expected. In MuseScore, nested tuplets are not decoded and displayed correctly.
I think the basic features are done, but I am still not sure if the way of notating the score is good enough. I have other simpler ideas to notate them… but still not sure…
I started using sclang and lilypond 10 years ago, but never felt the need to expand it into a complete system like music21 and other huge projects. I’ve been also using a pipe between sclang and openmusic, and from there I export music segments and materials into finale. I’ve composed several works this way as well
My experiments with Haskell are kind of recent, I felt that it can offer something different, how to represent it, how I can manipulate the material, and so on, and so on.
The most interesting part, and you should know this, is precisely after that, how to manipulate these materials. I’m always thinking of new ways, it has nothing against the sclang language. )))
To be honest, I have not seriously used computer-aided algorithmic composition in my work, although many parts of my work tend to have an algorithmic character.
I did try something in OpenMusic, but that was just an experiment.
I did it several times for research, and the following is one of them: hommage à l'impressionnisme
In these experiments, I thought it would be nice if I could get a score from these codes instead of a spectrum in an audio file editor.
The reason I want to implement this in sclang at the moment is firstly for my students who are not musicians.
When I finish implementing the musicXML file creator for sclang, I will be able to use powerful algorithmic composition for my own work!
I have used MIDI to transfer musical information, but I think musicXML is better.
If you think the abbreviation is not good, I will change the rhythmic part to be the same as in lilypond.
I find it confusing that the accidental notation follows lilypond, but the octave notation follows scientific pitch notation.
I have also looked at lilypond notation, guido notation and abc notation. None of them use scientific pitch notation octave numbers. I have no problem using Helmholtz pitch notation, but feel a bit strange using it with an English based programming language like sclang.
I am not sure if = used for combining duration, articulation etc. to the pitches is good…
Moreorver, q, e, x, t and i for rhythmic value do not seem to be understandable as 4, 8, 16, 32 and 64…