Fluid Synth CC1 Tremolo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Fluid Synth CC1 Tremolo

fluid-dev mailing list
Hi All

Thanks for the latest updates. At least my Estey sound font has passed the test and I will now use this for all future testing.

The problem may well lie in the midi channels - It seems that both you and the FS documentation (and perhaps me) are confusing midi channels with fluidsynth channels. They are completely different.

I am using 32 FSchans in eplayOrgan. Each FSchan has a different midi Patch in order to provide multiple instruments which can optionally (by pulling stops) all play at the same time. The notes of all these instruments are sent to their respective FSchans when synth noteon/s are executed. By this stage any midi channels are not relevant and certainly not sent to the synth. This has been proven to work beyond doubt.

Midi channels are limited to a maximum of 16 and are those used in midi files and midi ports to provide separate paths for the various midi instruments (patches). Once the midi events have been processed to produce commands for the synth they are no longer relevant. The synth uses FSchannels.

The documentation for BOTH fluid_synth_cc() and fluid_synth_noteon() references "midi channels" as below whereas, certainly for noteon, it actually means FSchannels. 

"Parameters for cc:
synth FluidSynth instance
chan MIDI channel number (0 to MIDI channel count - 1)
num MIDI controller number (0-127)
val MIDI controller value (0-127)

Parameters for noteon:
synthFluidSynth instance
chanMIDI channel number (0 to MIDI channel count - 1)
keyMIDI note number (0-127)
velMIDI velocity (0-127, 0=noteoff)"

Just because something works from the command prompt does not necessarily mean that it will work when another programmer tries to make it work by using the documented procedures; especially if the documentation is either wrong or ambiguous.

Please clarify whether the parameters for fluid_synth_cc() and fluid_synth_noteon() refer to FSchannels or midi channels.

Thank you
David(csw900)
PS. I did not see what Christian wrote because he did not send me a copy.





_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

Ceresa Jean-Jacques

Hi David,

 

>Just because something works from the command prompt does not necessarily mean that it will work when another programmer tries to make it work by using the documented procedures; especially if the documentation is either wrong or ambiguous.
>Please clarify whether the parameters for fluid_synth_cc() and fluid_synth_noteon() refer to FSchannels or midi channels.

 

Parameter int chan is really MIDI Channel from (0 to MIDI channel count - 1). The default MIDI channel count is 16.

The functions API fluid_synth_cc(), fluid_synth_noteon(), fluid_synth_noteoff() return FLUID_FAILED is chan parameter is incorrect.

 

However, the command of the fluidsynth console application does nothing if chan is incorrect. This should not be a problem for the user

because the result is audible.

 

The MIDI channel count can changed to 32  if need using: fluid_settings_setint(settings, "synth.midi-channels", 32);

This change must be done before calling new_fluid_synth().

 

The wording "FSchannels" does not exist in the documentation.

regards

jjc

 

 

 

> Message du 05/07/20 09:34

> De : "David Back" <[hidden email]>
> A : "FluidSynth Mailing List" <[hidden email]>
> Copie à : "Tom M." <[hidden email]>, "Ceresa Jean-Jacques" <[hidden email]>
> Objet : Fluid Synth CC1 Tremolo
>
>
Hi All

>
Thanks for the latest updates. At least my Estey sound font has passed the test and I will now use this for all future testing.

>
The problem may well lie in the midi channels - It seems that both you and the FS documentation (and perhaps me) are confusing midi channels with fluidsynth channels. They are completely different.

>
I am using 32 FSchans in eplayOrgan. Each FSchan has a different midi Patch in order to provide multiple instruments which can optionally (by pulling stops) all play at the same time. The notes of all these instruments are sent to their respective FSchans when synth noteon/s are executed. By this stage any midi channels are not relevant and certainly not sent to the synth. This has been proven to work beyond doubt.

>
Midi channels are limited to a maximum of 16 and are those used in midi files and midi ports to provide separate paths for the various midi instruments (patches). Once the midi events have been processed to produce commands for the synth they are no longer relevant. The synth uses FSchannels.

>
The documentation for BOTH fluid_synth_cc() and fluid_synth_noteon() references "midi channels" as below whereas, certainly for noteon, it actually means FSchannels. 

>
"Parameters for cc:
synth FluidSynth instance
chan MIDI channel number (0 to MIDI channel count - 1)
num MIDI controller number (0-127)
val MIDI controller value (0-127)

>
Parameters for noteon:
synth FluidSynth instance
chan MIDI channel number (0 to MIDI channel count - 1)
key MIDI note number (0-127)
vel MIDI velocity (0-127, 0=noteoff)"

>
Just because something works from the command prompt does not necessarily mean that it will work when another programmer tries to make it work by using the documented procedures; especially if the documentation is either wrong or ambiguous.
>

>
Please clarify whether the parameters for fluid_synth_cc() and fluid_synth_noteon() refer to FSchannels or midi channels.

>
Thank you
David(csw900)
PS. I did not see what Christian wrote because he did not send me a copy.

>

>

>

>
_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
In reply to this post by fluid-dev mailing list
There is no such thing as "FSchannels". The documentation of the synth always
talks about "midi channels". The only way you communicate with the synth is
via "midi channels". Just because the number of midi channels is limited to 16
in standard midi files does not mean it's limited in the same way for
fluidsynth. Neither does it mean something is "completely different".

JJC already pointed out how the number of channels can be changed, see
http://www.fluidsynth.org/api/fluidsettings.xml#synth.midi-channels

The naming "midi channels" was given to indicate that channels of a midi file
are semantically equivalent to the channels provided by the synthesizer.

> Just because something works from the command prompt does not necessarily
mean that it will work when another programmer tries to make it work

Since the command prompt uses the same synth API calls as you used in your
app, it is definitely suited as proof of concept.


Tom




_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
Thanks for your comment. Even though the FS documentation is wrong and confusing when you consider midi and FSchannels I know you are not going to change it.

Your argument that these channels are equivalent may be right a simple case such as your command interface but when you consider an organ they most definately are not the same or even equivalent. And it is very confusing to think they are.

The midi inputs for eplayOrgan arrive in midi channels whether from a keyboards or midi files. There is ONE midi channel for each input. Each midi input is processed and then sent on to the synth. The notes from EACH incoming midi channel are fed simultaneously to 32 FSchannels for processing by the synths. (eplayOrgan actually uses four synths - one for each division).

Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

Thus there is no way that midi channels  are equivalent to FSchannels.

Now the good news - Now I have changed the channels from midi channels to FSchannels,    fluid_synth_cc(synth, FSchan, 1,100) now works and produces tremolo using the sound font Tom successfully tested.

I have learnt quite a bit about sound fonts - especially how their modulation system works. I hope to learn even more by experimenting now I have a working system to play with. So thank you all for your help.

Best Wishes
David (csw900)






On Sunday, 5 July 2020, 11:43:27 BST, Tom M. <[hidden email]> wrote:


There is no such thing as "FSchannels". The documentation of the synth always
talks about "midi channels". The only way you communicate with the synth is
via "midi channels". Just because the number of midi channels is limited to 16
in standard midi files does not mean it's limited in the same way for
fluidsynth. Neither does it mean something is "completely different".

JJC already pointed out how the number of channels can be changed, see
http://www.fluidsynth.org/api/fluidsettings.xml#synth.midi-channels

The naming "midi channels" was given to indicate that channels of a midi file
are semantically equivalent to the channels provided by the synthesizer.


> Just because something works from the command prompt does not necessarily
mean that it will work when another programmer tries to make it work


Since the command prompt uses the same synth API calls as you used in your
app, it is definitely suited as proof of concept.


Tom





_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

Ceresa Jean-Jacques

Hi, David

 

>Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

Thus there is no way that midi channels  are equivalent to FSchannels.
 
When talking to a MIDI compliant synthesizer the synthesizer must understand what is a MIDI channel. The semantic of int chan parameter of fluidsynth's API
is the same that the four channel bits in any of the MIDI event described by the MIDI specs. Any synthesizer, FS or another should react equivalent to this information.
The format of the data and the meaning of the data are two things different. The only difference is that fluidsynth is less restrictive that the MIDI specs (256 channels instead of
16 ). When using The MIDI driver, the MIDI information received on the MIDI input hardware (channel,note,velocity) is transmitted directly to the parameter of fluidsynth's MIDI API which react as described by the MIDI specs. How could we think that the documentation is wrong ?
 
From the description of eplayOrgan, it seems that the application is an interface between multiple physical keyboards (manuals) and fluidsynth instance(s).
Using 4 fluidsynth instances with 16 MIDI channel by instance means that eplayOrgan need to supply 4 x 16 = 64 MIDI Channels on its output. Please, is my understanding correct ?
 
>The notes from EACH incoming midi channel are fed simultaneously to 32 FSchannels for processing by the synths. (eplayOrgan actually uses four synths - one for each division).
1)Please, what could be the reason to map one incoming midi channel simultaneously to 32 distinct FSChannels ?
2)Are the 4 synths running on the same machine ?, and in this case what is the reason of using 4 instances on the same machine ?

Regards.

jjc

> Message du 05/07/20 16:32

> De : "David Back" <[hidden email]>
> A : "FluidSynth Mailing List" <[hidden email]>
> Copie à : "Tom M." <[hidden email]>, "Ceresa Jean-Jacques" <[hidden email]>
> Objet : Re: Fluid Synth CC1 Tremolo
>
>
 
Thanks for your comment. Even though the FS documentation is wrong and confusing when you consider midi and FSchannels I know you are not going to change it.

>
Your argument that these channels are equivalent may be right a simple case such as your command interface but when you consider an organ they most definately are not the same or even equivalent. And it is very confusing to think they are.

>
The midi inputs for eplayOrgan arrive in midi channels whether from a keyboards or midi files. There is ONE midi channel for each input. Each midi input is processed and then sent on to the synth. The notes from EACH incoming midi channel are fed simultaneously to 32 FSchannels for processing by the synths. (eplayOrgan actually uses four synths - one for each division).

>
Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

>
Thus there is no way that midi channels  are equivalent to FSchannels.

>
Now the good news - Now I have changed the channels from midi channels to FSchannels,    fluid_synth_cc(synth, FSchan, 1,100) now works and produces tremolo using the sound font Tom successfully tested.

>
I have learnt quite a bit about sound fonts - especially how their modulation system works. I hope to learn even more by experimenting now I have a working system to play with. So thank you all for your help.

>
Best Wishes
David (csw900)

>

>

>

>

>

>
On Sunday, 5 July 2020, 11:43:27 BST, Tom M. <[hidden email]> wrote:

>

>
There is no such thing as "FSchannels". The documentation of the synth always
talks about "midi channels". The only way you communicate with the synth is
via "midi channels". Just because the number of midi channels is limited to 16
in standard midi files does not mean it's limited in the same way for
fluidsynth. Neither does it mean something is "completely different".

JJC already pointed out how the number of channels can be changed, see
http://www.fluidsynth.org/api/fluidsettings.xml#synth.midi-channels

The naming "midi channels" was given to indicate that channels of a midi file
are semantically equivalent to the channels provided by the synthesizer.


> Just because something works from the command prompt does not necessarily
mean that it will work when another programmer tries to make it work


Since the command prompt uses the same synth API calls as you used in your
app, it is definitely suited as proof of concept.


Tom





_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
> Thus there is no way that midi channels  are equivalent to FSchannels.

I said **semantically** equivalent.

From my understanding, it was actually your design decision to give it that
decidated "midi channel" and "FSchannel" meaning. I understand why you do that
(i.e. playing the same notes at the same time using 32 different instruments).
I do not understand, why you need 4 different synth's for that. I don't know,
whether you were looking for tremolo or vibrato. However, I'm glad that it
works now.

I think you could have used fluid_synth_start() for all of that, allowing you
to use a total of 4 channels rather than 128. But that's beyond the scope for
now.

And if our documentation is what you consider to be "wrong" while on the other
hand works fine and eases understanding for the rest of our users, I'm fine
with that as well :)

Tom

@JJC: You forgot to send him a copy ;)



_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
In reply to this post by fluid-dev mailing list
Hi

Thanks for the comments.

I think you are used to using FS with its associated midi driver. I am not using your midi driver and thus my input midi channels do not have to (and indeed do not) correspond with the FS channels.

As I have never had any need to use any part of FS except the synth itself I only claim to understand the synth. The midi driver, midi player and any other parts are all foreign to me because they do not do what I needed for an organ.

I am using four instances of FS because with real time midi, execution speed is important - four instances are around four times faster than one instance would be. Each instance corresponds to one division (division = keyboard) of the organ. There are four keyboards on the organ. All four instances of FS reside within the organ app. and all execute simultaneously. Thus eplayOrgan provides 128 (= 4X32) channels of midi action simultaneously.

Also each instance of FS provides one stereo output, so four instances can provide up to four stereo outputs. This is convenient for giving a realistic audio output.

eplayOrgan is fast enough to run at least 6 instances simultaneously on one ordinary PC. This is 24 instances of FS running concurrently. eplayOrgan can also drive (or be driven by) other organs such as GrandOrgue or Hauptwerk all at the same time. The only limitation I have found is screen space on the computer.

I hope this answers all the questions. By the way the tremolo works OK with V1.1.8 of FS so I have no need to update to V2. V2 uses a whole host of extra .dll's and, as far as I can tell, provides no useful extra functionality for an organ.

David(csw900)





On Sunday, 5 July 2020, 18:05:58 BST, Ceresa Jean-Jacques <[hidden email]> wrote:


Hi, David

 

>Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

Thus there is no way that midi channels  are equivalent to FSchannels.
 
When talking to a MIDI compliant synthesizer the synthesizer must understand what is a MIDI channel. The semantic of int chan parameter of fluidsynth's API
is the same that the four channel bits in any of the MIDI event described by the MIDI specs. Any synthesizer, FS or another should react equivalent to this information.
The format of the data and the meaning of the data are two things different. The only difference is that fluidsynth is less restrictive that the MIDI specs (256 channels instead of
16 ). When using The MIDI driver, the MIDI information received on the MIDI input hardware (channel,note,velocity) is transmitted directly to the parameter of fluidsynth's MIDI API which react as described by the MIDI specs. How could we think that the documentation is wrong ?
 
From the description of eplayOrgan, it seems that the application is an interface between multiple physical keyboards (manuals) and fluidsynth instance(s).
Using 4 fluidsynth instances with 16 MIDI channel by instance means that eplayOrgan need to supply 4 x 16 = 64 MIDI Channels on its output. Please, is my understanding correct ?
 
>The notes from EACH incoming midi channel are fed simultaneously to 32 FSchannels for processing by the synths. (eplayOrgan actually uses four synths - one for each division).
1)Please, what could be the reason to map one incoming midi channel simultaneously to 32 distinct FSChannels ?
2)Are the 4 synths running on the same machine ?, and in this case what is the reason of using 4 instances on the same machine ?

Regards.

jjc

 

> Message du 05/07/20 16:32

> De : "David Back" <[hidden email]>
> A : "FluidSynth Mailing List" <[hidden email]>
> Copie à : "Tom M." <[hidden email]>, "Ceresa Jean-Jacques" <[hidden email]>
> Objet : Re: Fluid Synth CC1 Tremolo

>
>
 
Thanks for your comment. Even though the FS documentation is wrong and confusing when you consider midi and FSchannels I know you are not going to change it.

>
Your argument that these channels are equivalent may be right a simple case such as your command interface but when you consider an organ they most definately are not the same or even equivalent. And it is very confusing to think they are.

>
The midi inputs for eplayOrgan arrive in midi channels whether from a keyboards or midi files. There is ONE midi channel for each input. Each midi input is processed and then sent on to the synth. The notes from EACH incoming midi channel are fed simultaneously to 32 FSchannels for processing by the synths. (eplayOrgan actually uses four synths - one for each division).

>
Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

>
Thus there is no way that midi channels  are equivalent to FSchannels.

>
Now the good news - Now I have changed the channels from midi channels to FSchannels,    fluid_synth_cc(synth, FSchan, 1,100) now works and produces tremolo using the sound font Tom successfully tested.

>
I have learnt quite a bit about sound fonts - especially how their modulation system works. I hope to learn even more by experimenting now I have a working system to play with. So thank you all for your help.

>
Best Wishes
David (csw900)

>

>

>

>

>

>
On Sunday, 5 July 2020, 11:43:27 BST, Tom M. <[hidden email]> wrote:

>

>
There is no such thing as "FSchannels". The documentation of the synth always
talks about "midi channels". The only way you communicate with the synth is
via "midi channels". Just because the number of midi channels is limited to 16
in standard midi files does not mean it's limited in the same way for
fluidsynth. Neither does it mean something is "completely different".

JJC already pointed out how the number of channels can be changed, see
http://www.fluidsynth.org/api/fluidsettings.xml#synth.midi-channels

The naming "midi channels" was given to indicate that channels of a midi file
are semantically equivalent to the channels provided by the synthesizer.


> Just because something works from the command prompt does not necessarily
mean that it will work when another programmer tries to make it work


Since the command prompt uses the same synth API calls as you used in your
app, it is definitely suited as proof of concept.


Tom





_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

Ceresa Jean-Jacques

Hi, David

 

Many thanks for the description of eplayOrgan. This answers all the questions.

Indirectly we understand that the cpu on which eplayOrgan is running have four cores.

 

just it is a surprise that you find V2.x.x are using extra .dll's.

Here, I am using V2 correctly configured (using CMake) and compiled and I confirm that there are no extra dll.

But maybe are you using the already pre-compiled binaries ?. Did you use fluidsynth configured and compiled by yourself

on your Windows system ?.

 

Great that tremolo works now, this should had a nice more realistic effect to organ instruments.

jjc

 

> Message du 05/07/20 21:06

> De : "David Back" <[hidden email]>
> A : "Ceresa Jean-Jacques" <[hidden email]>
> Copie à : "Tom M." <[hidden email]>, "FluidSynth Mailing List" <[hidden email]>
> Objet : Re: Fluid Synth CC1 Tremolo
>
>
 
Hi

>
Thanks for the comments.

>
I think you are used to using FS with its associated midi driver. I am not using your midi driver and thus my input midi channels do not have to (and indeed do not) correspond with the FS channels.

>
As I have never had any need to use any part of FS except the synth itself I only claim to understand the synth. The midi driver, midi player and any other parts are all foreign to me because they do not do what I needed for an organ.

>
I am using four instances of FS because with real time midi, execution speed is important - four instances are around four times faster than one instance would be. Each instance corresponds to one division (division = keyboard) of the organ. There are four keyboards on the organ. All four instances of FS reside within the organ app. and all execute simultaneously. Thus eplayOrgan provides 128 (= 4X32) channels of midi action simultaneously.

>
Also each instance of FS provides one stereo output, so four instances can provide up to four stereo outputs. This is convenient for giving a realistic audio output.

>
eplayOrgan is fast enough to run at least 6 instances simultaneously on one ordinary PC. This is 24 instances of FS running concurrently. eplayOrgan can also drive (or be driven by) other organs such as GrandOrgue or Hauptwerk all at the same time. The only limitation I have found is screen space on the computer.

>
I hope this answers all the questions. By the way the tremolo works OK with V1.1.8 of FS so I have no need to update to V2. V2 uses a whole host of extra .dll's and, as far as I can tell, provides no useful extra functionality for an organ.

>
David(csw900)

>

>

>

>

>
On Sunday, 5 July 2020, 18:05:58 BST, Ceresa Jean-Jacques <[hidden email]> wrote:

>

>

> Hi, David

>  

> >Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

Thus there is no way that midi channels  are equivalent to FSchannels.
 
When talking to a MIDI compliant synthesizer the synthesizer must understand what is a MIDI channel. The semantic of int chan parameter of fluidsynth's API
is the same that the four channel bits in any of the MIDI event described by the MIDI specs. Any synthesizer, FS or another should react equivalent to this information.
The format of the data and the meaning of the data are two things different. The only difference is that fluidsynth is less restrictive that the MIDI specs (256 channels instead of
16 ). When using The MIDI driver, the MIDI information received on the MIDI input hardware (channel,note,velocity) is transmitted directly to the parameter of fluidsynth's MIDI API which react as described by the MIDI specs. How could we think that the documentation is wrong ?
 
From the description of eplayOrgan, it seems that the application is an interface between multiple physical keyboards (manuals) and fluidsynth instance(s).
Using 4 fluidsynth instances with 16 MIDI channel by instance means that eplayOrgan need to supply 4 x 16 = 64 MIDI Channels on its output. Please, is my understanding correct ?
 
>The notes from EACH incoming midi channel are fed simultaneously to 32 FSchannels for processing by the synths. (eplayOrgan actually uses four synths - one for each division).
1)Please, what could be the reason to map one incoming midi channel simultaneously to 32 distinct FSChannels ?
2)Are the 4 synths running on the same machine ?, and in this case what is the reason of using 4 instances on the same machine ?

> Regards.

> jjc

>  

> Message du 05/07/20 16:32
> De : "David Back" <[hidden email]>
> A : "FluidSynth Mailing List" <[hidden email]>
> Copie à : "Tom M." <[hidden email]>, "Ceresa Jean-Jacques" <[hidden email]>
> Objet : Re: Fluid Synth CC1 Tremolo

>
>
 
Thanks for your comment. Even though the FS documentation is wrong and confusing when you consider midi and FSchannels I know you are not going to change it.

>
Your argument that these channels are equivalent may be right a simple case such as your command interface but when you consider an organ they most definately are not the same or even equivalent. And it is very confusing to think they are.

>
The midi inputs for eplayOrgan arrive in midi channels whether from a keyboards or midi files. There is ONE midi channel for each input. Each midi input is processed and then sent on to the synth. The notes from EACH incoming midi channel are fed simultaneously to 32 FSchannels for processing by the synths. (eplayOrgan actually uses four synths - one for each division).

>
Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

>
Thus there is no way that midi channels  are equivalent to FSchannels.

>
Now the good news - Now I have changed the channels from midi channels to FSchannels,    fluid_synth_cc(synth, FSchan, 1,100) now works and produces tremolo using the sound font Tom successfully tested.

>
I have learnt quite a bit about sound fonts - especially how their modulation system works. I hope to learn even more by experimenting now I have a working system to play with. So thank you all for your help.

>
Best Wishes
David (csw900)

>

>

>

>

>

>
On Sunday, 5 July 2020, 11:43:27 BST, Tom M. <[hidden email]> wrote:

>

>
There is no such thing as "FSchannels". The documentation of the synth always
talks about "midi channels". The only way you communicate with the synth is
via "midi channels". Just because the number of midi channels is limited to 16
in standard midi files does not mean it's limited in the same way for
fluidsynth. Neither does it mean something is "completely different".

JJC already pointed out how the number of channels can be changed, see
http://www.fluidsynth.org/api/fluidsettings.xml#synth.midi-channels

The naming "midi channels" was given to indicate that channels of a midi file
are semantically equivalent to the channels provided by the synthesizer.


> Just because something works from the command prompt does not necessarily
mean that it will work when another programmer tries to make it work


Since the command prompt uses the same synth API calls as you used in your
app, it is definitely suited as proof of concept.


Tom





_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
In reply to this post by fluid-dev mailing list
> four instances are around four times faster than one instance would be

Four instances are pretty much four times more wasteful on resources
than a single instance. The synth has a built-in parallel renderer,
you just need to use it:

fluid_settings_setint(settings, "synth.cpu-cores", 4);

> Also each instance of FS provides one stereo output, so four instances can provide up to four stereo outputs.

That's not a reason either as the synth supports multi-channel
rendering. Sorry, I think you should not claim to understand the
synth.

> so I have no need to update to V2. V2 uses a whole host of extra .dll's

The "host of dlls" strongly depends on the environment used for
compilation. That said, V2 does not have any extra dependencies!

>  and, as far as I can tell, provides no useful extra functionality for an organ.

V2 provides (completely useless) bug fixes for an organ. V1.1.8 could
crash your entire app...


Tom

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
The extra resources are minimal and are not "wasted" they are used to provide extra speed.

I cannot predict how many cores my users PC's will have so the synth.cpu-cores setting is useless. Even if it adjusts itself to the real no. of cores a user has it provides no guaranteed benefit over using four instances. Each division of an organ is pretty much identical so I use the benefits of c++ code to reuse the identical code for each division including processing the synths. Four instances of FS will run perfectly well even if the users PC has only one core.

The four stereo outputs are automatically provided by using four synth instances. And are simple for users to understand and use. Thus the additional complexity of "multi-channel rendering" is avoided. (Though I may come back to this later, in order to get even more outputs, if and when I get some spare time)

I was only experimenting with V2 in order to get my tremolo working. I am sorry to say my experience of V2 (different, more complex API and all the extra .dlls) put me off using it for now. I used a precompiled version because that was easiest at the time. My previous experience of compiling FS on Windows was very time consuming - hopefully you have now made it easier to compile. I have other more useful things to do at present.

FS V1.1.8 may have bugs (so does all software) but the bugs are so well hidden that I have not noticed them. They certainly do not and never have crashed my App.

David(csw900)


On Monday, 6 July 2020, 06:37:02 BST, Tom M. <[hidden email]> wrote:


> four instances are around four times faster than one instance would be

Four instances are pretty much four times more wasteful on resources
than a single instance. The synth has a built-in parallel renderer,
you just need to use it:

fluid_settings_setint(settings, "synth.cpu-cores", 4);

> Also each instance of FS provides one stereo output, so four instances can provide up to four stereo outputs.

That's not a reason either as the synth supports multi-channel
rendering. Sorry, I think you should not claim to understand the
synth.

> so I have no need to update to V2. V2 uses a whole host of extra .dll's

The "host of dlls" strongly depends on the environment used for
compilation. That said, V2 does not have any extra dependencies!

>  and, as far as I can tell, provides no useful extra functionality for an organ.

V2 provides (completely useless) bug fixes for an organ. V1.1.8 could
crash your entire app...



Tom

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

Marcus Weseloh
In reply to this post by fluid-dev mailing list
Hi all,

Am So., 5. Juli 2020 um 16:32 Uhr schrieb David Back via fluid-dev
<[hidden email]>:
> Thanks for your comment. Even though the FS documentation is wrong and confusing when you consider midi and FSchannels I know you are not going to change it.
> Your argument that these channels are equivalent may be right a simple case such as your command interface but when you consider an organ they most definately are not the same or even equivalent. And it is very confusing to think they are.

FWIW, I would be interested in understanding why you think that our
documentation is "wrong". I can understand "confusing"... FluidSynth
is highly flexible and has a huge API, which makes documenting it
quite hard. But "wrong" is quite a strong word, so I would be very
interested in your reasons for saying that.

FluidSynth is a SoundFont synth, it's synthesis model and by extension
it's API is closely tied to the SoundFont spec and MIDI as a whole.
And the FluidSynth concept of channels is closely related to the
semantics of MIDI. Consider the fact that there are many API calls
(like fluid_synth_cc, fluid_synth_pitchbend, fluid_synth_sysex,
fluid_synth_channel_pressure, ...) that have firm roots in the MIDI
standard. And the naming and valid ranges of the parameters that you
pass to those functions are also (mostly) based in the world of MIDI.
So in my opinion,  FluidSynth concept of "channels" is at least a
subset of MIDI channels and calling them "MIDI channels" makes that
quite clear.

I understand that your application is using its own MIDI processor,
does custom MIDI event routing and uses FluidSynths flexibility to
achieve things not possible with the built-in MIDI engine. But I don't
understand why that makes you say that our documentation is wrong...
Would you care to explain this in more detail?

> Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.

I think this is a weird interpretation. In my view, MIDI channels
don't "contain" MIDI events. MIDI events can specify which MIDI
channel they affect, which means that channels are not a "container"
for events but rather a concept (or the numerical address) of a
configuration and state of a synthesis engine (of which 16 are
directly addressable via MIDI events and many more via the API).

Cheers
Marcus

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
Hi Marcus et al

Taking your last point first: If you have ever used a midi editor you would soon realise that midi channels DO contain midi events. The channel number contained in most events merely associates the event with a particular channel.

According to the midi specification the number of midi channels cannot exceed 16. This is emphasised by the fact that the channel representation contained in events has only 4 bits which automatically limits its range to values between 0 and 15.

Moving on and considering the synth contained in fluidsynth without any other encuberances such as your midi input module. It automatically follows from the above that if the synth can have more than 16 channels OR the channels do not contain midi events they CANNOT be midi channels AND thus the synth channel numbers CANNOT be midi channel numbers. (Even though in PARTICULAR CASES the synth channel numbers may be the equal to midi channel numbers).

Why don't you all relent, admit you are wrong, and change the synth documentation to indicate that the synth inputs are SYNTH channels i.e. FSchans as I have called them.

It would be very useful if somebody familiar with all the aspects of FS drew a block diagram to show each of its modules and the paths of signals between the modules. This diagram should be published along with the other docs.

I have been designing and writing software ever since the first microprocessors came on to the market and know that proper documentation is very important. I also know that in general that much of the documentation should be written before even one line of code is produced. The coder simply follows the documentation and makes his/her code do what the documents say it should do.

David(csw900)


On Monday, 6 July 2020, 23:05:16 BST, Marcus Weseloh <[hidden email]> wrote:


Hi all,

Am So., 5. Juli 2020 um 16:32 Uhr schrieb David Back via fluid-dev
<[hidden email]>:
> Thanks for your comment. Even though the FS documentation is wrong and confusing when you consider midi and FSchannels I know you are not going to change it.
> Your argument that these channels are equivalent may be right a simple case such as your command interface but when you consider an organ they most definately are not the same or even equivalent. And it is very confusing to think they are.

FWIW, I would be interested in understanding why you think that our
documentation is "wrong". I can understand "confusing"... FluidSynth
is highly flexible and has a huge API, which makes documenting it
quite hard. But "wrong" is quite a strong word, so I would be very
interested in your reasons for saying that.

FluidSynth is a SoundFont synth, it's synthesis model and by extension
it's API is closely tied to the SoundFont spec and MIDI as a whole.
And the FluidSynth concept of channels is closely related to the
semantics of MIDI. Consider the fact that there are many API calls
(like fluid_synth_cc, fluid_synth_pitchbend, fluid_synth_sysex,
fluid_synth_channel_pressure, ...) that have firm roots in the MIDI
standard. And the naming and valid ranges of the parameters that you
pass to those functions are also (mostly) based in the world of MIDI.
So in my opinion,  FluidSynth concept of "channels" is at least a
subset of MIDI channels and calling them "MIDI channels" makes that
quite clear.

I understand that your application is using its own MIDI processor,
does custom MIDI event routing and uses FluidSynths flexibility to
achieve things not possible with the built-in MIDI engine. But I don't
understand why that makes you say that our documentation is wrong...
Would you care to explain this in more detail?


> Also midi channels contain midi events in a specified defined format. The FSchannels are driven by software procedures in a completely different specified format.


I think this is a weird interpretation. In my view, MIDI channels
don't "contain" MIDI events. MIDI events can specify which MIDI
channel they affect, which means that channels are not a "container"
for events but rather a concept (or the numerical address) of a
configuration and state of a synthesis engine (of which 16 are
directly addressable via MIDI events and many more via the API).

Cheers
Marcus


_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

Marcus Weseloh
Hi David,

Am Di., 7. Juli 2020 um 09:44 Uhr schrieb David Back <[hidden email]>:
> Taking your last point first: If you have ever used a midi editor you would soon realise that midi channels DO contain midi events. The channel number contained in most events merely associates the event with a particular channel.

Ok, I think I understand where the confusion comes from. If you think
about MIDI channels and events as they are represented in MIDI
editors, then your point makes some sense. The user interface of
editors usually give you the impression that events are contained in
channels, because that makes editing and understanding the concepts
easier to grasp for the user. But that is not the level of abstraction
we are dealing with here. At the API level, we are at a much lower
level of abstraction. In this context, it makes no sense to say that
channels contain events. But that doesn't mean that those channels are
not MIDI channels, it is simply a different context and concept.

> Why don't you all relent, admit you are wrong, and change the synth documentation to indicate that the synth inputs are SYNTH channels i.e. FSchans as I have called them.

Quite frankly: that is a weird (and a little rude) question to ask.
You seem to imply that we argue against your point for the sake of it.
But that is not the case... I think your argument isn't valid because
it comes from the wrong level of abstraction and is based on contexts
that are not applicable here.

Cheers
Marcus

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluid Synth CC1 Tremolo

fluid-dev mailing list
> > Why don't you all relent, admit you are wrong, and change the synth documentation to indicate that the synth inputs are SYNTH channels i.e. FSchans as I have called them.
> Quite frankly: that is a weird (and a little rude) question to ask.

I don't think David is interested in a factual discussion. Look at his
previous, completely unrelated (and partly false) statements that he
came up with:

* "the synth.cpu-cores setting is useless"
* V2 has a "more complex API"
* "V2 uses a whole host of extra .dll's"

The original problem was that David was broadcasting NoteOn events to
various channels while he was failing to broadcast ControlChanges as
well. That's it! Sh*t happens.

And for somebody who was "designing and writing software ever since
the first microprocessors came on to the market" I cannot seriously
believe that this failure was due to the fact that we call these
channels "midi channels" rather than "synth channels". Sorry.

So, just let him be happy with his broken 1.1.8 . And if he thinks he
can do a better job on parallelization by using four hardcoded synth
instances despite "[he] cannot predict how many cores [the] users PC's
[will have]", let him do it as well.

Tom

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev