Re: [fluid-dev] FluidSynth and glib

[Carlo Bramini]

Hello,
please excuse me if this message looks long...

It was not my intention to make changes to Fluidsynth so that you won't be able 
to run it with GLIB anymore.
I was thinking to adjust things in a manner that it could run ALSO without GLIB.
Hopefully, it seems to me that Fluidsynth has been written (probably) by 
thinking also on this subject, so I do not think that this task is extremely 
complicated or hard to maintain. I did it, so I think I know what I'm writing. 
Once things are implemented, I don't think they will need a big maintenance.
Perhaps, it will be even easier to maintain. With pthreads or Windows API, We 
are 100% sure that we won't have functions that they will disappear from one 
version to another because they are deprecated and this is also visibible in 
your current code.

Beside the creation of a fluidsynth without external dependencies, I think that 
there are some other things that could be useful.

As I have written in my previous email, I used MSVC 6.0 for doing this 
development.
The C version implemented in this environment is C90 and it has been a good 
bench for testing the portability.

Just to make an example, C90 does not implement variable length arrays.
However, it could be done with alloca() or _alloca() intrinsic functions, if 
supported.
Fluidsynth already checks the presence of this feature, but it did not allow to 
select something different than GLIB.
So, I implemented this thing in my new common part in this way:

#if defined HAVE_VLA_SUPPORT
#  define FLUID_DECLARE_VLA(_type, _name, _len) _type _name[_len]
#elif defined HAVE_ALLOCA
#  define FLUID_DECLARE_VLA(_type, _name, _len) _type * _name = (_type 
*)alloca(sizeof(_type)*(_len))
#elif defined HAVE__ALLOCA
#  define FLUID_DECLARE_VLA(_type, _name, _len) _type * _name = (_type 
*)_alloca(sizeof(_type)*(_len))
#elif defined HAVE_GLIB
#  define FLUID_DECLARE_VLA(_type, _name, _len) _type * _name = (_type 
*)g_newa(_type, _len)
#else
#  error Support for variable-length arrays is missing on this system.
#endif

Next to all these changes, I made it working on Windows without GLIB.
Perhaps you may find something similar to a previous version of Fluidsynth, at 
least at first sight.
Afterall, there are not many other ways to do it, like starting a thread for 
example.
However, in my opinion I did it more efficient than the past and with some 
common parts.

I also noticed that some thing are also not implemented in the current code 
base.
For example, fluid_get_userconf() returns always NULL on Windows, while in my 
opinion it won't be a bad idea to query CSIDL_APPDATA with ShellAPI for 
retrieving this kind of information.

Under this view, it does not look bad or hard to maintain a specific layer of 
10KB for a particular platform.

If you prefer, I could start to share just the changes that do not impact with 
current GLIB layer and, if you will find them useful, you could integrate them, 
or you could trash them as you wish if they won't look good for you.

In the meanwhile, when working on my homebrew digital piano, I have also 
compiled and apparently made working Fluidsynth on my evaluation board with an 
LPC1788 from NXP with emIDE as development environment and newlib as C library. 
Here there is still lot of work to do because I must a new code to forward the 
MIDI events from the matrix of the piano keyboard connected to this 
microcontroller and write another piece of code for emitting some audio output. 
I could use NuttX OS (with full pthread and posix support), GNU Pth 
(cooperative pthread support) or a very simple cooperative multitasking made by 
me with setjmp/longjmp inside fluid_* functions, probably this last solution 
simplifies a lot the coding since it will work on all implementations of libc 
as last resort. During this coding, I noticed that some thing could be improved 
regarding the RAM usage: if you have some experience in the world of embedded 
systems, you will know that the volatile RAM is a limited resource and all 
constant data should be moved into the flash memory. I have also an external 
SDRAM, but I did not used it intentionally, to see where the weak area are. So, 
some fixes have been made in my build also for this. Probably, it won't work 
well because a Cortex-M3 has not an hardware FPU, so I will need to migrate to 
an M4 or an M7... But this is another story.

Sincerely.