Re: [fluid-dev] Trying another reverb ?

Hi, Marcus and GrahamG   Thanks for your interrest.   >I would also be very interested in a better sounding reverb. I don't pretend that freemverb is a better reverb. This is ears dependant. The goal was to obtain a less "ringing" sound that with freeverb.To obtain this result the inner struc

Re: [fluid-dev] Trying another reverb ?

Hi again, 2017-10-22 21:09 GMT+02:00 Marcus Weseloh : > So maybe what we need is a system where we can have multiple reverb > implementations in core FluidSynth and a setting that can be used to select > one of the implementations. > Let me explain that idea in a bit more detail. What I have in

Re: [fluid-dev] Trying another reverb ?

Hi, I would also be very interested in a better sounding reverb. I've written a different reverb as well, implementing a "sympathetic string reverb" using tuned comb filters. Currently I maintain it in a custom fork, but I wanted a maintainable solution. So I started working on the LADSPA plugin

Re: [fluid-dev] Trying another reverb ?

Hi jjc Yes, there would be great interest in this, particularly from the jOrgan users group as many of use us use fluidsynth with the current reverb engine. Kind regards, GrahamG On 10/22/17, Ceresa Jean-Jacques wrote: > Hello, > > For another application than FluidSynth i have build a reverb (

[fluid-dev] Trying another reverb ?

Hello, For another application than FluidSynth i have build a reverb (intended to be called freemverb) that sounds less "ringing" that freeverb. Like freeverb , freemverb is a "late" reverb and have a low cpu load (sligtly above freeverb) and low memory cost. Both freeverb and freemverb aren't

Re: [fluid-dev] A Bit of optimization.

>why do you think so? if count==0, 1.0f / count would result in infinity, >wouldnt it? Count is always limited to1 (minimum) by the instruction above: count = 1 + NUM_BUFFERS_ATTACK(x);   jjc > Message du 22/10/17 16:34 > De : "Tom M." > A : "FluidSynth mailing list" > Copie à : > Objet :

Re: [fluid-dev] Current code overrides getopt.h declarations on Windows

Long time ago this looked like: https://github.com/FluidSynth/fluidsynth/blame/c9193d8f8182cd26785f6fdda502dbcad783ccbc/fluidsynth/src/fluidsynth.c#L90-L94 Perhaps these declarations were missing in the header at that time and manually added. I think it's redundant nowadays and removed it

Re: [fluid-dev] Current code overrides getopt.h declarations on Windows

Hello you are right, I did not noticed that thing: that ugly addition on top of fluidsynth.c declares extern getopt(), but in the later code it is using getopt_long(). So, the re-declaration of getopt() looks more useless to me. You may want to re-declare getopt_long() instead, but I doubt that

Re: [fluid-dev] A Bit of optimization.

1) I think @carlo-bramini will take care of that in his next PR :) 2) why do you think so? if count==0, 1.0f / count would result in infinity, wouldnt it? 3) Yes, should work. Tom 2017-10-22 16:07 GMT+02:00 Ceresa Jean-Jacques < jean-jacques.cer...@orange.fr>: > Hi, > > List of possible opti

Re: [fluid-dev] Current code overrides getopt.h declarations on Windows

> If HAVE_GETOPT is defined, let's use the function. We dont rely on getopt, fluidsynth.c will do the parsing itself if it's not present. The bigger problem is that getopt_long() may or may not be present in getopt.h. But so far I havent seen a getopt.h that doesnt provide it. Tom 2017-10-22 1

Re: [fluid-dev] Current code overrides getopt.h declarations on Windows

Hello, in my opinion, that piece of code should be removed. The proper presence of getopt.h and the support of getopt() function should be tested by cmake. If HAVE_GETOPT_H is defined, let's include the file. If HAVE_GETOPT is defined, let's use the function. What do you think? Sincerely. > Il

[fluid-dev] A Bit of optimization.

Hi, List of possible optimization.   1)In fluid_voice.c - fluid_voice_calculate_runtime_synthesis_parameters()     int list_of_generators_to_initialize[35]...,  replaced by,  static const int list_of_generators_to_initialize[35] = { 2)In fluid_voice.c - fluid_voice_update_param()   

Re: [fluid-dev] Current code overrides getopt.h declarations on Windows

Hi, to me it looks like somebody read the getopt man page and took the synopsis as a usage example and not as a short description of the header file contents. I think the lines int getopt(int argc, char * const argv[], const char *optstring); extern char *optarg; extern int optind, opterr, optopt