Re: [fluid-dev] Program change problems with fluidsynth

[Reinhold Hoffmann]

  _  

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=blogcategory=67=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 :


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.com@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 

Re: [fluid-dev] Program change problems with fluidsynth

[Tom M.]

> 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 :

> 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

Re: [fluid-dev] Program change problems with fluidsynth

[Reinhold Hoffmann]

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