Discuss Notion Music Composition Software here.
6 posts
Page 1 of 1
|
Hello
Newby here. I just imported a musicxml file, the score is in C minor but when imported it's showing accidentals on almost all the notes! for example, a C shows as a C natural. Am I missing something basic here? Thanks Dan |
danjacobs2 wrote...when imported it's showing accidentals on almost all the notes! Hello. I don't have any problems importing an xml file that is in the key of C minor. The source xml file would seem to be suspect if there's a problem when it's imported into Notion. ,Newberry  |
|
Several things might be happening to cause this; and I suspect it's something the more advanced music theory folks will be able to identify; but I did a few experiments with a C Major scale, and if I changed the key signature to C♭ (not C Minor), several of the notes had natural accidentals . . .
If I changed the key to B Minor, this also happened; and I also tried C Minor, but it didn't change the C notes . . . (1) What is the actual key signature? Does it have flats or sharps, and if so how many? (2) Are you certain the score that was exported as MusicXML actually is in the key of C Minor? THOUGHTS The various types of "tuning" and instruments affect the way notes are treated with respect to accidentals . . . I use "Concert Tuning", mostly because I do everything on treble staves and white keys on the piano . . . If I need to play a black key, then I add a sharp to indicate that it's not a white key . . . This way, I only need 12 notes and 10 or so octaves (two which most humans cannot hear) . . .  It's also important to understand that by default, NOTION 6 does not use standard "Concert A" (A4 in scientific pitch notation), which is 440-Hz; so you need to change the "Global tuning" value to 440-Hz if you want to use standard "Concert A" as the reference tuning frequency . . .  Lots of FUN! 
Surf.Whammy's YouTube Channel
The Surf Whammys Sinkhorn's Dilemma: Every paradox has at least one non-trivial solution! |
|
here's a screenshot.
The XML looks broadly right to me.
|
|
I created an experimental score and did the music notation exactly like the example you posted . . .
The primary thing I noticed is that every note has an explicit accidental in its respective measure so that even when there is no accidental for a note within a measure, there is an explicit accidental for the same pitch note before the note in the same measure . . . This means (a) that the key signature does not matter, because the notes are made explicit or absolute and (b) that the key signature does not affect the notes . . . In the second and third measures, there are some notes that do not have accidentals, but these notes inherit the explicit accidentals of the earlier same pitch notes in their respective measures . . . Perhaps the composer specified the notes this way intentionally to avoid any possibility of changing the notes automagically? THOUGHTS In software engineering, doing something like this is called "using magic numbers"; and (a) it's annoying; (b) it's difficult to follow; and (c) it's mostly done by software engineers who want to protect themselves from being replaced . . . It's also called "obfuscation", and it makes it nearly impossible to understand algorithms by simple inspection . . . And it's a major violation of generally accepted programming standards . . . Curiously, this type of code was great for me; since even though it takes a while, I can decipher it; and over the decades this mapped to some highly paid consulting work focused on cleaning up mazes . . . It's tedious and time-consuming work; but (a) I like money and (b) tedious and time-consuming work doesn't bother me when I am making a lot of money . . .  In programming languages that have a "GOTO" statement, there are lines of code like the following . .
Nevertheless, this does provide an important clue, which is that the code is a maze . . . If you rollback the clock perhaps half a century or more, there were programming languages that used "GOTO" statements legitimately (FORTRAN, for example), but folks soon realized that maintaining code that heavily uses "magic numbers" is extraordinarily difficult; and since then the practice is avoided diligently . . . The only thing worse than "magic numbers" is subclassing and multiple-inheritance, which includes frameworks . . . If you happen to conceptualize everything and think exactly the same way as the folks who created a framework, then great . . . It will make immediately intuitive sense, and everything will be wonderful; but if you do not conceptualize and think the same way, then it makes no sense and odd stuff starts happening for no apparent reason . . . Making it all the more annoying, operating system and programming language designers have regular team meetings where they devise new ways to change everything . . . I like low-level C and C++, and I give everything meaningful names so I don't need to remember everything I did . . . The greatest aspect of low-level C and C++ is that it's virtually impossible for the "changers" to break . . . When a new version of C and C++ appears, your code continues to work, which is fabulous . . . Fabulous!  With useful comments and meaningful names, someone who knows software engineering but nothing about a specific algorithm should be able to look at the code and understand what it is doing in a general way--perhaps in a precise and accurate way . . . This is all that comes to mind . . . Lots of FUN!
Surf.Whammy's YouTube Channel
The Surf Whammys Sinkhorn's Dilemma: Every paradox has at least one non-trivial solution! |
|
I found a simple solution, but continue to have no idea why this happened . . .
SOLUTION You will need to edit the MusixXML document, and you can do this in a plaintext editor (like "TextEdit.app" on the Mac) or with an XML editor like UltraEdit . . . I use UltraEdit, because it color-codes XML, which makes it easier to read; but wandering into UltraEdit is more of a software engineering activity . . . The problem with the MusicXML is that there are accidentals (probably just naturals and flats, but there also could be sharps). In the version you posted, there only are naturals and flats . . . This is the NOTION 6 music notation I used for the experiment . . . [NOTE: There were only rests in the Tenor Voice, and I generally do not input meaningless rests. The first measure is a "pickup measure", but to keep it simple I replaced the quarter-rest with a dotted half-rest, which made it possible to avoid reading the NOTION 6 user guide to discover how to notate a "pickup measure" . . . ]  This is how some of the MusicXML document looks, and the important information is the two "<accidental> . . . </accidental>" statements. There are a lot of them, but you only need to know the syntax in this solution . . . [NOTE: This the way the MusicXML looks in UltraEdit when it's color-coded the way I prefer. In a simple plaintext editor, all the XML will be black. This color-coding scheme works for me, because I have trained my visual perception to use it. It usually is not so easy for other folks to read XML when it's color-coded this way, but it works for me. The XML tags are important, but I want to focus on the parameters, numbers, and so forth, not on the XML tags; and this color-coding scheme does this once you get accustomed to it. For reference, "<accidental>" is an opening XML tag, and "</accidental>" is the respective closing XML tag. "XML" is the acronym for "Extensible Markup Language" . . . ]  If you want to wander into software engineering, you can download the demo version of UltraEdit and make sense of how it works . . . [NOTE: There are versions of UltraEdit for the Mac and for Windows . . . ] UltraEdit (IDM Computer Solutions, Inc) If you expect to encounter MusicXML problems frequently, then UltraEdit can be helpful . . . Otherwise, you can correct the problem with a simple, plaintext editor . . . This is how the MusicXML excerpt looks in plaintext in TextEdit.app on the Mac . . .  If there only are MusicXML statements for flat and natural accidentals, then what you want to do is the following: [NOTE: There is an exception to this, so you need to check for it. Specifically, it's possible that some of the naturals and some of the flats actually are needed. Hopefully, there are no sharps. If there are no special cases where a flat or natural actually is needed, then this solution will work nicely; and it's relatively easy to do. After you do this, listen to it and check it "by ear" . . . ] (1) Do a global replace of all the "<accidental>natural</accidental>" statements with a single space, which will be something like a "Find and Replace All" starting from the top . . . (2) Do a global replace of all the "<accidental>flat</accidental>" statements with a single space, which will be something like a "Find and Replace All" starting from the top . . . After doing the global replaces, there will be an apparently blank line everywhere there was an "<accidental> . . . </accidental>" statement, which is good . . . [NOTE: They are not blank lines, but instead are lines with a single space; so they appear to be blank but actually are lines with one space for each line . . . ] (3) Save the MusicXML document and be certain that the file extension is ".xml" rather than ".txt" or whatever . . . Now, import the MusicXML document to NOTION 6, which will create a new score; and then save the new NOTION 6 score . . . You can remove all the "empty lines" in the MusicXML by exporting it again from your newly saved NOTION 6 score and then importing this newly exported MusicXML to NOTION 6 . . . [NOTE: The "empty lines" don't do anything, and NOTION 6 ignores them. When exporting the score as MusicXML, NOTION 6 will discard the "empty lines" . . . ] When you have done the MusicXML editing, importing, and so forth, the resulting music notation will look like this, which is the way it should look . . .  THOUGHTS There is a way to clear accidentals in NOTION 6, but rather than actually clearing all accidentals, it does what one might call "smart clearing", which in turn means that you can't actually remove all the accidentals and then have the key signature provide the implied accidentals . . . In the universe according to me, clearing all accidentals (a) should clear all the accidentals and (b) make the actual pitches of the notes dependent on the key signature, so that the notes will be whatever the key signature indicates they should be . . . However, the drawback to this is that any flats, naturals, or sharps that are needed will be gone, and this has the potential to change the mode, mood, scale, and all that stuff . . . Whether absolute clearing of all accidentals makes sense is another matter; but in this instance it works for the measures in the example you posted--so long as (a) naturals are on notes that do not need naturals and (b) flats are only on E, A, and B notes, which in C Minor do not need flats, because the key signature flats them automagically . . . If there are sharps in the MusicXML, I think you will need to determine whether they are necessary . . . Since the key is C Minor, it is redundant to specify flats for E, A, and B . . . If there are other flats, then like sharps this will need to be examined, which in some instances probably is the case with naturals . . . For example, in C Minor, a "Middle C" note is not automagically flatted; but if a 'Middle C" note needs to be flatted and then in the same measure is followed by a "Middle C" note that needs to be returned to the key signature, the flatted "Middle C" will be followed by a natural "Middle C" to "un-flat" it; and in this example the flat is necessary and the subsequent (same measure) natural is necessary . . . The other way to solve the problem is to examine each accidental and delete it if it's redundant, which can take a while, unless it's not a long song . . . Lots of FUN!
Surf.Whammy's YouTube Channel
The Surf Whammys Sinkhorn's Dilemma: Every paradox has at least one non-trivial solution! |
6 posts
Page 1 of 1
Who is online
Users browsing this forum: No registered users and 2 guests