From: Niek v. d. B. <Nie...@in...> - 2011-06-22 19:34:32
|
All, I am trying to import a MusicXML file and found some strange behavior of the Pitch constructor Pitch::Pitch(char noteName, int octave, const Key &key, const Accidental &explicitAccidental, int octaveBase). When parsing the MusicXML file I find a A without accidentals When the key is C major the constructor creates the right pitch (69). However in C minor the constructor creates a pitch 68 (A flat). I would expect an A without accidentals will be an A in every key. An A natural will be an A in C major and a Ab in C minor or do I understand something wrong? How can I create a pitch representing a "real" A in C minor? Best regards, Niek van den Berg |
From: Arnout E. <ros...@bz...> - 2011-06-22 20:13:21
|
Hello Niek, I haven't looked at the code in detail for a while, but I think the comments below should be accurate. Haven't tested. On Wed, Jun 22, 2011 at 09:34:22PM +0200, Niek van den Berg wrote: > I am trying to import a MusicXML file and found some strange behavior of the > Pitch constructor Pitch::Pitch(char noteName, int octave, const Key &key, > const Accidental &explicitAccidental, int octaveBase). > > When parsing the MusicXML file I find a A without accidentals. When the key is > C major the constructor creates the right pitch (69). However in C minor the > constructor creates a pitch 68 (A flat). > > I would expect an A without accidentals will be an A in every key. I can see how that might be confusing. Right now I think the rationale here is: * when no explicit accidental is specified ('NoAccidental'), inherit the accidental from the key signature * when an accidental is specified, always honour this accidental. Note that this does not always mean this accidental is shown: when the specified accidental (DoubleFlat, Flat, Natural, Sharp, DoubleSharp) is consistent with the current key, it will usually not be shown in the graphical representation. Perhaps the above explanation should be added to the documentation for this constructor (or the code changed, of course :) - but I think it makes some sense ;) ). > An A natural will be an A in C major and a Ab in C minor or do I understand > something wrong? 'Natural' here really means 'Not altered', e.g. not flat/sharp. > How can I create a pitch representing a "real" A in C minor? Specify 'Natural' as the accidental. Arnout |
From: D. M. M. <mic...@ro...> - 2011-06-23 10:23:20
|
On Wednesday, June 22, 2011, Arnout Engelen wrote: > > How can I create a pitch representing a "real" A in C minor? > > Specify 'Natural' as the accidental. I'm curious about the specifics of the context in which Niek is using this ctor, and what he needs to accomplish. I'm mildly afraid that this could turn into one of those situations where you work around one known problem and end up creating more problems elsewhere due to an incomplete understanding of the original problem in the context of Rosegarden's complicated pitch nonsense. -- D. Michael McIntyre |
From: Chris C. <ca...@al...> - 2011-06-23 10:55:00
|
On 22 June 2011 20:34, Niek van den Berg <Nie...@in...> wrote: > I would expect an A without accidentals will be an A in every key. An A > natural will be an A in C major and a Ab in C minor or do I understand > something wrong? NoAccidental means "drawn as an A on the score without any explicit accidental sign being shown", i.e. following the key (A or Ab in this case). Natural means "drawn with a natural sign" (A♮), i.e. always A even when the key says otherwise. Chris |
From: Niek v. d. B. <Nie...@in...> - 2011-06-23 15:52:19
|
Arnout, Michael, Chris, Thanks, I now understand which accidental I have to use, NoAccidental or Natural. Now I can continue. Concering the curiousity of Michael, what I try accomplich is very simple, I just want to import a MusicXML file :-) (I decided to create an MusicXML import besides the extension of the export because it helps me to understand both MusicXML and the Rosegarden internals). In MusicXML an Ab is specified as: <pitch> <step>A</step> <alter>-1</alter> <octave>4</octave> </pitch> This is not that difficult to parse and results in some variables m_step, m_octave and m_accidental. Then I use Pitch p = Pitch(m_step, octave, segment->getKeyAtTime(t), m_accidental); to create a Pitch. And that was the location I went into troubles. I simple translater the <alter> -2 to DoubleFlat, -1 to Flat, 0 (default) to NoAccidental, 1 to Sharp and 2 to DoubleSharp but this might be too simple, I have to take the running key into account. So I have still some work to do... And Michael, I understand your concern. Incomplete understanding and strange work around will create a lot of trouble in the end. That's the reason I every now and then I will pop with some questions. Thanks to you all, I will continue with both MusicXML import and export and will come back with new questions or maybe a working im-/export. Best regards, Niek |
From: Chris C. <ca...@al...> - 2011-06-23 16:19:21
|
On 23 June 2011 16:52, Niek van den Berg <Nie...@in...> wrote: > Concering the curiousity of Michael, what I try accomplich is very simple, I > just want to import a MusicXML file :-) (I decided to create an MusicXML > import besides the extension of the export because it helps me to understand > both MusicXML and the Rosegarden internals). There is actually a rather old and out-of-date MusicXML import branch already: https://rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/musicxml done by Arnout Engelen. It has never been merged because Arnout wasn't entirely satisfied with the structure of the import process -- there may have been some discussion of it on this list, and it's possible I could dig out some other emails on the subject as well (I think I once asked him off-list whether he would like it merged). I'll see what I can find. But it might possibly be worth a look as well. Chris |
From: Niek v. d. B. <Nie...@in...> - 2011-06-23 16:57:43
|
On Thursday 23 June 2011 18:19:13 Chris Cannam wrote: > There is actually a rather old and out-of-date MusicXML import branch > already: > > https://rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/musicxml > > done by Arnout Engelen. Thanks for the hint. I certainly have a close look to it. Best regards, Niek |
From: Arnout E. <arn...@bz...> - 2011-06-23 16:41:15
|
On Thu, Jun 23, 2011 at 05:52:10PM +0200, Niek van den Berg wrote: > In MusicXML an Ab is specified as: > > <pitch> > <step>A</step> > <alter>-1</alter> > <octave>4</octave> > </pitch> > > This is not that difficult to parse and results in some variables m_step, > m_octave and m_accidental. Then I use > > Pitch p = Pitch(m_step, octave, segment->getKeyAtTime(t), m_accidental); > > to create a Pitch. > > And that was the location I went into troubles. I simple translater the > <alter> -2 to DoubleFlat, -1 to Flat, 0 (default) to NoAccidental, 1 to Sharp > and 2 to DoubleSharp but this might be too simple, I have to take the running > key into account. So I have still some work to do... Shouldn't translating '0' into 'Natural' do exactly what you want? The MusicXML specs ( http://www.recordare.com/musicxml/dtd/note-module ) aren't all that specific, but that's how I'd read it. Kind regards, Arnout |
From: Chris C. <ca...@al...> - 2011-06-23 16:47:19
|
On 23 June 2011 17:41, Arnout Engelen <arn...@bz...> wrote: > Shouldn't translating '0' into 'Natural' do exactly what you want? Oh, you're in this thread! Sorry, I was half-asleep. It was you who did the existing branch, right? Chris |
From: Arnout E. <ros...@bz...> - 2011-06-23 18:35:06
|
On Thu, Jun 23, 2011 at 05:47:12PM +0100, Chris Cannam wrote: > On 23 June 2011 17:41, Arnout Engelen <arn...@bz...> wrote: > > Shouldn't translating '0' into 'Natural' do exactly what you want? > > Oh, you're in this thread! Sorry, I was half-asleep. No problem .) v It was you who did the existing branch, right? Yeah, actually I didn't quite remember I checked this into version contol,, it sure has been a while :) I remember dismissing my approach (adding notes directly to the Rosegarden data structures while parsing the XML, SAX-style) when I found out about some of the more advanced MusicXML constructs. However I haven't seen Niek's approach yet, and certainly don't want to discourage him even when he's also going this rout - perhaps I just gave up too soon :) Regards, Arnout > > > Chris > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel |
From: Chris C. <ca...@al...> - 2011-06-23 19:12:54
|
On 23 June 2011 19:34, Arnout Engelen <ros...@bz...> wrote: > I remember dismissing my approach (adding notes directly to the Rosegarden > data structures while parsing the XML, SAX-style) when I found out about > some of the more advanced MusicXML constructs. However I haven't seen > Niek's approach yet, and certainly don't want to discourage him even when > he's also going this rout - perhaps I just gave up too soon :) Indeed -- and actually I have a vague recollection I thought your approach was workable for enough files to make it worth persisting with, even if there would always be significant classes of files it wouldn't support. Chris |
From: Niek v. d. B. <Nie...@in...> - 2011-06-24 06:30:20
|
> I remember dismissing my approach (adding notes directly to the Rosegarden > data structures while parsing the XML, SAX-style) when I found out about > some of the more advanced MusicXML constructs. I had a closer look to your code and I am on a similar route. File are parsed using SAX2 and the Rosegarden event are created on the fly. So far anything seems implementable. Just to inform you, the current implemented features are: - Midi instrument mapping - Partwise scores - support for <divisions> - Key/Clef import - Note/rest events - Most of the Rosegarden marks (like tenuto) - Tuplet [3:2, x:y although there might be some problems left) - Lyrics - Slurs - Most of the dynamics. Most of items are not fully implemented yet (as ALL marks, ALL text events) but more a "proove of concept". For now I concentrate on implementing several MusicXML constructs to see how far I get and fill in the gaps later on. This might save time when come to a dead and I'm forced to reconsider my approach. Next constructs to explore are multistaff instruments and voices (layers?). I am working parallel on both MusicXML export and import per feature although the export has a headstart. > However I haven't seen > Niek's approach yet, and certainly don't want to discourage him even when > he's also going this rout Don't warry, I am not that easy to discourage :-) Best regards, Niek |
From: Niek v. d. B. <Nie...@in...> - 2011-06-24 08:42:13
|
On Thursday 23 June 2011 18:41:04 Arnout Engelen wrote: > Shouldn't translating '0' into 'Natural' do exactly what you want? The > MusicXML specs ( http://www.recordare.com/musicxml/dtd/note-module ) > aren't all that specific, but that's how I'd read it. That part is not that clear but in the tutorial it is more explicit (http://www.recordare.com/musicxml/tutorial/pitch): "The pitch represents the sound, not what is notated, so an alter element must be included even if represents a flat or sharp that is part of the key signature." So when there is no <alter> (or it is '0') I have to to find out, based on the key, whatever I should use Natural or NoAccidental. When <alter> overrides the accidental of the key I need Natural, otherwise NoAccidental. Best regards, Niek |
From: Arnout E. <ros...@bz...> - 2011-06-24 08:49:24
|
On Fri, Jun 24, 2011 at 10:42:03AM +0200, Niek van den Berg wrote: > On Thursday 23 June 2011 18:41:04 Arnout Engelen wrote: > > Shouldn't translating '0' into 'Natural' do exactly what you want? The > > MusicXML specs ( http://www.recordare.com/musicxml/dtd/note-module ) > > aren't all that specific, but that's how I'd read it. > > That part is not that clear but in the tutorial it is more explicit > (http://www.recordare.com/musicxml/tutorial/pitch): "The pitch represents the > sound, not what is notated, so an alter element must be included even if > represents a flat or sharp that is part of the key signature." Ah, good. > So when there is no <alter> (or it is '0') I have to to find out, based on the > key, whatever I should use Natural or NoAccidental. When <alter> overrides the > accidental of the key I need Natural, otherwise NoAccidental. No, afaik this is consistent with how Rosegarden works. 'Natural' will not lead to a 'natural' sign in the display output if it is consistent with the key signature. Perhaps we should rename 'NoAccidental' to 'Inherited' or something to better explain it doesn't mean there's no accidental, but that the accidental will be determined based on the key? Arnout |
From: Chris C. <ca...@al...> - 2011-06-24 08:56:53
|
On 24 June 2011 09:49, Arnout Engelen <ros...@bz...> wrote: > No, afaik this is consistent with how Rosegarden works. 'Natural' will not > lead to a 'natural' sign in the display output if it is consistent with the > key signature. Hm, I would expect Natural to lead to a natural sign always -- otherwise there would be no way to force a cautionary one (for example against an accidental in the previous bar) if Rosegarden didn't manage to work it out for you. I don't think there is any way to force Rosegarden _not_ to draw an accidental if it thinks it should, but there are probably fewer cases in which you'd want to. I might be quite wrong about all this though (as usual). > Perhaps we should rename 'NoAccidental' to 'Inherited' or something to better > explain it doesn't mean there's no accidental, but that the accidental will be > determined based on the key? The most significant point I think is that in Rosegarden accidentals are basically optional, because the notes may have come from MIDI data which includes a performed pitch but no notation. So the default for any note is NoAccidental, i.e. this note has no accidental property associated with it at all, i.e. Rosegarden should do what it thinks best. The name NoAccidental is logical from that perspective (though I don't disagree that it is also confusing for the human reader without that context). The reason the function parameter is named explicitAccidental is in recognition of that confusion, though it evidently also doesn't do enough to eliminate it. Chris |
From: D. M. M. <mic...@ro...> - 2011-06-24 11:02:39
|
On Friday, June 24, 2011, Chris Cannam wrote: > best. The name NoAccidental is logical from that perspective (though > I don't disagree that it is also confusing for the human reader > without that context). Yeah, but calling it TakesItsAccidentalFromTheBestContextAvailable is _so_ hard to type. I find it kind of sad that this is the longest conversation we've had on the devel list in months, and I missed most of it, and don't really have anything constructive to add at this point. Alas. -- D. Michael McIntyre |