|Subject:||Re: [fluid-dev] FluidSynth and glib|
|Date:||Sat, 14 Oct 2017 13:14:59 +0200|
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)
# error Support for variable-length arrays is missing on this system.
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.
fluid-dev mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|