[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] FluidSynth and glib
From: |
Carlo Bramini |
Subject: |
Re: [fluid-dev] FluidSynth and glib |
Date: |
Sat, 14 Oct 2017 11:35:25 +0200 (CEST) |
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.