View Single Post
Old 02-04-2018, 06:37 PM
Reinhold H. Reinhold H. is offline
Join Date: Jan 1970
Location: Utting am Ammersee, Germany
Posts: 362
Default Re: Vollume changes lost on XML export/import



The volume setup in Notation Composer - as well as other song parameters regarding sound - has been developed from the MIDI capabilities. The focus of our software always has been to provide good capabilities to optimize the user's handling for sound, pan, instruments etc. no matter how the notation score looks like. This concept is very special to our design. Notation elements are just extracted either from the basic event stream (which is based on the MIDI event stream) or in case of a new song such an event stream is generated. The GraphOverNotes feature manages this event stream. For volume changes the GraphOverNotes modifies the MIDI controller events which are totally independant from notes. A MIDI controller event sets the volume for a MIDI device to play the next tones in a certain volume. Notes itself have a velocity as part of the MIDI event NoteOn which can also be modified with the Velocity tab in Composer.

MusicXML is totally different. Here the music notation elements are the core or at least almost. From the MusicXML protocol's perspective there is indeed a MusicXML protocol element available to set a volume change independant from notes. But none of the other software programs which we use evaluate this element. We work with Finale, Sibelius, Dorico, Capella, MuseScore. The MusicXML protocol is designed to exchange sheet music among the programs. MusicXML is a framework what can be done but none of the software program today have implemented the full feature set in import nor in export. So, none of these major programs not even the very expensive ones have implement the volume change independant from notes. If none of them have implemented it, it does not make sense for Notation Composer to export note independant volume changes nor to import volume changes this way. Importing MusicXML files by Notation composer which are exported by Notation Composer does not make sense either .

A further investigation shows that there are 2 possibilities to export a volume change in MusicXML where those other programs have the capabilities to import it:
  • export/import a volume change as part of a Dynamic Mark. See Wikipedia at A Dynamic Mark can be set dependantly or independantly of a note.
  • export/import a volume change as part of a note's velocity

Solution for (1): In order to be flexible with Composer we implemented a solution in 3.0.6-190 as such that at the time point of a dynamic mark the current volume of GraphOverNotes is taken and exported. In MusicXML import the volume from the MusicXML file is taken and a MIDI controller event is created. On the Wikipedia page some fixed volumes are recommended but to me I would rather have it more flexible. Please see the screen shot of how such a score will looks like (this is the imported MusicXML file). From the 5 major competitive programs which we use, 4 are able to import the volume change this way but only one does it 100% perfect for the correct volume and at the correct time point. For your arrangement this would been that you just have to set a dynamic mark in the score at the time of a volume change.

Solution for (2): Composer exports a velocity change today but only one of the other programs is able to take a non-standard velocity and to create notes with different velocities. Composer imports notes with different velocities with 3.0.6-190.

Given what I have learned in this excercise I believe that this is a pragmatic approach to get sound volumes across.

Free text import is also available in 3.0.6-190. But I need to point out that here similar as for other notation elements where graphical dimensions are involved an update is planned. In the current implementation a correct positioning in the score might be necessary after the import. Even for free text there is one program (an expensive one) from those 5s which is not able to import free text today.

Again, thanks for your input.

Attached Images
File Type: png Unbenannt.png (12.7 KB, 16 views)
Reply With Quote