_____ Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=notation....@nongnu.org] Im Auftrag von Tom M. Gesendet: Montag, 8. Mai 2017 21:36 An: FluidSynth mailing list Betreff: Re: [fluid-dev] Program change problems with fluidsynth
> I think the issue is created with the converstion tool from the .abc to the > .mid file. > All midi Program Changes (also those for track/chn 1,2,3) are placed to track > 4. > [...] To my knowledge a Program Change of a track/chn should be set within > the track and not outside the track. You're right. The order of events is determined by their tick and implicitly by their order within a track. Scattering the events across tracks loses the implicit order criteria, which obviously can result in strange behaviour (Note however that it's absolutely legal to do that). Relevant is that the NoteOns of channel 1,2,3 happen at the same tick (noteably tick 1) as the prog changes of chans 1,2,3. Apparently fluidsynth comes along, reading and enqueueing the NoteOns first, later finding the prog changes and enqueueing them at the same tick, but after the note ons... which is too late. The standard doesnt seem to be very verbose on the effect order of midi events that happen at the same tick. Probably because there is no such order. The only statement regarding program changes I could find: "The program must change upon the receipt of the Program Change message. However, the program need not be changed for a note which is already sounding." (The Complete MIDI 1.0 Detailed Specification, document version 96.1) Which basically means that everybody can do what they want, i.e. some synths start the notes as organ, others dont. > Moving the Program Change to the appropriate track solves the issue. Probably only because you've put the prog changes before the note ons (same tick). Doing it the other way round wouldnt work. [Reinhold] Tom: Thanks for digging into the spec. We at Notation Software have analysed tons of midi files and find a Program Change event only in the same track. This is the first time that I see a midi file where a Program Change is not in the same track. But you are right, everybody can do what they want. Francesco: so just make sure that every program change happens one tick before note ons. For your file, change the byte at offset 0x05AC from 0x01 to 0x00. [Reinhold] Francesco: There is the great freeware tool PSRUTI from Heiko Plate available (Please see: <http://www.heikoplate.de/mambo/index.php?option=com_content&task=blogcategory&id=67&Itemid=44> http://www.heikoplate.de/mambo/index.php?option=com_content&task=blogcategory&id=67&Itemid=44 ) which shuffles around the midi events and brings all into the right order. The tool has an old fashioned user interface but many years of experience and feedback have been put into this tool. The internal logic is excellent. Running your midi file through this tool with "GM Conversion" or "XG Optimization" solves the issue. Reinhold Tom 2017-05-08 19:32 GMT+02:00 Reinhold Hoffmann <reinh...@notation.com>: Hi Francesco, I think the issue is created with the converstion tool from the .abc to the .mid file. All midi Program Changes (also those for track/chn 1,2,3) are placed to track 4. When playing the first Note On of track 1,2,3 at that point in time the Program Change settings of track 1,2,3 are undefined for the playing program. Therefore the default setting Piano is used. Later (not timewise later but from an execution of the playing software) when playing track 4 the Program Change of track 1,2,3/chn 1,2,3 are set to be 21 which will modify the sound to organ for all notes to be played later. To my knowledge a Program Change of a track/chn should be set within the track and not outside the track. Moving the Program Change to the appropriate track solves the issue. I have checked the issue because we at Notation Software (www.notation.com) use the fluidsynth libraries, too. From the fluidsynth perspective I believe fluidsynth is fine. Our software acts as such that Program Change is only allowed within the same track. With our software in your example track 1,2,3 play as piano throughout, track 4 as organ throughout. Hope this analysis help Reinhold -----Ursprungliche Nachricht----- Von: fluid-dev [mailto:fluid-dev-bounces+ <mailto:fluid-dev-bounces%2Breinhold> reinhold=notation.com@nongnu. <mailto:notation....@nongnu.org> org] Im Auftrag von Francesco Ariis Gesendet: Dienstag, 2. Mai 2017 11:31 An: fluid-dev@nongnu.org Betreff: [fluid-dev] Program change problems with fluidsynth Hello fluidsynth users/devs, today I tried to render a midi file (attached) with fluidsynth via command line: fluidsynth -a alsa -F audio.ogg -T oga /usr/share/sounds/sf2/FluidR3_GM.sf2 hymn1.mid I attach the first few seconds of the audio file too. As you can hear, the first note (the first beat I should say) is a piano sound, while subsequent notes are a church organ. When I render it with another software (say, llms, attached), every note is a church organ. What happens? In case it might be helpful: the midi was generated from an .abc file, which I attach too. If you need more infos, don't hesitate to ask -F _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/ <https://lists.nongnu.org/mailman/listinfo/fluid-dev> mailman/listinfo/fluid-dev
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
