> I was thinking to adjust things in a manner that it could run ALSO
without GLIB.
Sry, but I dont see that we can have one fluidsynth shipping for arbitrary
users that doesnt require or use GLIB at all, and having another version of
fluidsynth that uses GLIB.
Imagine: Windows users will come ups
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 wr
GCC support stdatomic.h since 4.9
On Fri, Oct 6, 2017 at 10:21 PM, Tom M. wrote:
> Not really. It's not done by simply switching to a C++ compiler. The data
> types should be converted to object-oriented ones and the
> checking-every-functions-return-value-mentality should be rethought.
> Usage
Not really. It's not done by simply switching to a C++ compiler. The data
types should be converted to object-oriented ones and the
checking-every-functions-return-value-mentality should be rethought. Usage
of STL containers would need to be considered in order to unleash C++ whole
power. And we wo
damn! and I guess moving to C++11 is not an option
On Fri, Oct 6, 2017 at 5:55 PM, Tom M. wrote:
> This is for C++11 only.
>
> And as I just learned: The threading part of C11 is optional, which is
> very disappointing. Because it means that even though clang and gcc claim
> to be feature comple
This is for C++11 only.
And as I just learned: The threading part of C11 is optional, which is very
disappointing. Because it means that even though clang and gcc claim to be
feature complete, glibc is (still) lacking support for the IMO most
important part of C11: Threading ( see
https://sourcewa
According to https://msdn.microsoft.com/en-us/library/hh567368.aspx
VS2015 should have decent enough C11 support for threads and atomics.
Or is only for C++11 ?
Philippe
___
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/li
Hello Tom,
Thought I'd chime in, since I was the one who pushed using glib to begin
with. I got tired of all the architecture specific code which seemed to
have issues in certain situations and saw glib as being a good option. It
does complicate building on those platforms though and in embedded
I would like to bring this up again. I can absolutely comprehend the
arguing of windows or mac users to get rid of glib. I would accept a patch
that makes fluidsynth get rid of glib and support Posix OSs and Windows.
However my personal preferred solution would be to go with C11. Stroustrup
has for
Great news! I finally got VirtualBox and Windows working again! Hopefully,
I'll get the Windows side of things working tomorrow, but the WORST-CASE
scenario would be early next week.
On Mon, Jun 6, 2016 at 6:11 PM, Ryan Gonzalez wrote:
> No. Couldn't get the damn thing to install in a VM. >:(
>
Sweet!
Really, it's all Windows. I STILL can't get it to install because
VirtualBox is being weird, and I'm using Linux, so VMware isn't an option,
and QEMU is not the fastest by any means, and etc...
The source is up at:
https://github.com/kirbyfan64/fluidsynth
Basically, I coded blindly and a
Hi Ryan,
what kind of help would you need ? What is the size of the problem and the
process to work on it ?
If I can find some time, I may try and provide some help.
Antoine
Le 7 juin 2016 à 01:11, Ryan Gonzalez a écrit :
> No. Couldn't get the damn thing to install in a VM. >:(
>
> Anyone her
No. Couldn't get the damn thing to install in a VM. >:(
Anyone here interesting in helping on the Windows front? Please? At all?
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Jun 6, 2016 5:58 PM, "Antoine S
Any news on the windows/glib front ?
Le 25 mai 2016 à 16:41, Ryan Gonzalez a écrit :
> Unfortunately, I can't do anything on Windows now...because it won't boot.
> Hangs forever on the stupid wheel of death. Curse you, Microsoft...
>
> In a few days (hopefully over the long weekend!), I'll pr
Unfortunately, I can't do anything on Windows now...because it won't boot.
Hangs forever on the stupid wheel of death. Curse you, Microsoft...
In a few days (hopefully over the long weekend!), I'll probably install the
Windows 10 trial into a VM and see if I can work from there.
On Linux, though,
Hi,
just wanted to know the status of the glib dependency removal process ?
glib has been a high pain for me when porting to Windows and Mac. I'd be happy
to see it removed from fluidsynth and port my fluidXtra to a glib-free fluid.
Thanks
Antoine
Le 22 janv. 2016 à 00:13, Ryan Gonzalez a écr
Yup!
I had to stop working on it for a bit because of a big exam I was studying
for, but I just restarted today. I'm literally ALMOST done; only 13
functions remain unconverted, as well as mutexes on Windows. So far have
458 additions and 237 deletions.
You can see the progress here:
https://git
Hi,
are there any news on this?
// Johannes
On 01/22/2016 12:13 AM, Ryan Gonzalez wrote:
Well, I've already ported over most glib utilities, atomics, and
mutexes (normal and recursive). I just ended up busy with several
other things until this weekend.
On January 21, 2016 4:06:41 PM CST, Jo
Well, I've already ported over most glib utilities, atomics, and mutexes
(normal and recursive). I just ended up busy with several other things until
this weekend.
On January 21, 2016 4:06:41 PM CST, Johannes Schickel
wrote:
>On 01/14/2016 12:29 AM, Ryan Gonzalez wrote:
>> May I try? :D
>>
>>
On 01/14/2016 12:29 AM, Ryan Gonzalez wrote:
May I try? :D
Pretty much everything outside of threading is really trivial. The
wiki says the supported platforms are Windows, OSX, and Linux, and
that it runs under Solaris and OS/2 but they aren't officially supported.
For atomics, glib seems t
Hello everyone,
I'm the creator of a game engine project which too relies on fluidsynth
for handling midi sound rendering. From what I have gathered, my use of
the library is similar in nature to that of ScummVM, because I only feed
already parsed events into a synth object, and call synth_write t
Indeed. Probably the easiest would be to just lift the related bits from
glib itself.
Best regards,
Element
On Wed, Jan 13, 2016 at 4:29 PM, Ryan Gonzalez wrote:
> May I try? :D
>
> Pretty much everything outside of threading is really trivial. The wiki
> says the supported platforms are Win
May I try? :D
Pretty much everything outside of threading is really trivial. The wiki
says the supported platforms are Windows, OSX, and Linux, and that it runs
under Solaris and OS/2 but they aren't officially supported.
For atomics, glib seems to use GCC's C++11-style atomics. when it can, then
I think the ticket system on SourceForge would be the best way to submit
this:
https://sourceforge.net/p/fluidsynth/tickets/
Indeed, there isn't a lot of stuff that needs to be implemented to remove
glib as a dependency, for a single platform/architecture. Doing this in a
clean and portable fashi
On 01/13/2016 09:28 PM, Ryan Gonzalez wrote:
Similar things for the rest of them. This doesn't seem TOO bad...
Sure, nothing there is magic. But I am not sure if you want to implement
and maintain it own your own. Looks like supported systems in 1.0.9
were: Win32, OS/2, Mac OS 9, and POSIX
Well, the majority of g_* are wrapped with macros anyway, so it wouldn't be
a major issue.
Would the developers of Fluidsynth be OK if I sent a series of patches to
this list that slowly eliminated the need for glib? Unless you have another
way of handling contributions or something
On Wed, J
On Wed, Jan 13, 2016 at 9:28 PM, Ryan Gonzalez wrote:
>
> Similar things for the rest of them. This doesn't seem TOO bad...
>
>
Maybe it would be a good idea to just implement the necessary
"g_"* functions for the needed platforms instead of creating a new API
doing all of these things?
_
This is a list of all the glib functions/macros Fluidsynth uses:
g_assert
g_atomic_int_add
g_atomic_int_compare_and_exchange
g_atomic_int_dec_and_test
g_atomic_int_exchange_and_add
g_atomic_int_get
g_atomic_int_inc
g_atomic_int_set
g_atomic_pointer_compare_and_exchange
g_atomic_pointer_get
g_atomi
Hi Element,
don't worry, I see the point of using glib from your side. :-)
You seem to be right about the hash table code. It looks like it only
mentions "g_hashtable" in some comments, I appareantly missed that when
giving this a quick grep run earlier. Ooops :-).
I was looking a bit into t
Le 13/01/2016 18:36, Element Green a écrit :
Having said all that, it would be nice to have the ability to build a
possibly stripped down version of FluidSynth which would utilize a
user defined compatibility layer. ...Internally the FluidSynth
source code still has it's own compatibility
On January 13, 2016 11:33:20 AM CST, Chris Robinson
wrote:
>On 01/13/2016 08:47 AM, Ryan Gonzalez wrote:
>> glib isn't actually that huge, and Fluidsynth puts it to good use.
>> Cross-platform threading is hard. I'm writing an application that
>> depends on Fluidsynth, and it wasn't really a pr
A single thread version would be great for embedded applications!
Sent from my iPhone
> On Jan 13, 2016, at 9:36 AM, Element Green
> wrote:
>
> Hello Johannes,
>
> Seeing as I'm the one responsible for converting FluidSynth over to glib in
> the first place, I thought it is only right that I
Hello Johannes,
Seeing as I'm the one responsible for converting FluidSynth over to glib in
the first place, I thought it is only right that I respond ;-)
Prior to FluidSynth depending on glib, there was a bit of platform support
code. This code was error prone, somewhat hard to maintain, and of
On 01/13/2016 08:47 AM, Ryan Gonzalez wrote:
glib isn't actually that huge, and Fluidsynth puts it to good use.
Cross-platform threading is hard. I'm writing an application that
depends on Fluidsynth, and it wasn't really a program.
It's not too difficult to wrap up pthreads and Win32 threads i
glib isn't actually that huge, and Fluidsynth puts it to good use.
Cross-platform threading is hard. I'm writing an application that depends on
Fluidsynth, and it wasn't really a program.
The synthesizer indirectly uses gthreads a lot, so I don't think it would be
easy to remove. But, do older
Hello,
first of all thank you for your awesome project!
I am a member of ScummVM (http://www.scummvm.org) and I am currently
looking into getting our FluidSynth support a bit more up to speed (i.e.
get it into more of our ports, updating to the latest version, etc). It
looks like there are so
36 matches
Mail list logo
