> 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. 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. 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+reinhold=notation....@nongnu.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/mailman/listinfo/fluid-dev >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
