[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Qsynth broken with FluidSynth 1.1.0
Rui Nuno Capela
Re: [fluid-dev] Qsynth broken with FluidSynth 1.1.0
Tue, 03 Nov 2009 19:12:15 +0000
Thunderbird 188.8.131.52 (X11/20090817)
no hard feelings. whatsoever.
it might sound harsh but, trust me, it is not. it's just what i should
tell and hide no more. surely, i am half-guilty as bad, to only get to
this after you made the release. i should had pay more attention during
but i guess you know the ol'story, so little time... uber-procrastinator
>>>> first of all build fails due to (const char *) api change.
>>> Right, I'll let Josh answer to this, I thought he only changed the input
>>> API, not the callbacks. But that is easily fixed in QSynth, I can supply
>>> a patch against qsynth if you like.
>> no need for that, thanks. i can do that too. problem is that it now needs
>> conditional compilation flags (#ifdef's) to compile against conflicting
>> apis. if you fix it to 1.1.0 you'll break it to < 1.1.0, and vice versa.
>> not a good thing, not at all. it's a tiny change but one big trouble for
>> source distribution by packagers and users at large. a complete disgrace
>> and i would even commit the capital sin to suggest for immediate
>> regression, if not too late.
> I think it would be good to revert the changes in the callbacks, if its
> proving to be so troublesome. I'm the one at fault for that change. I
> had assumed it would just create build warnings, but it sounds like it
> is worse than that. I'd imagine its only the changes in the callbacks
> that are the problem and not the other functions.
indeed. only the callbacks.
>>>> second, qsynth behaves very badly, inconsistently and troublesome
>>>> against 1.1.0. everything just feels broken.
>>> Can you explain this a bit?
>>> I haven't used QSynth much, but I fixed the const char* stuff (in qsynth
>>> 0.3.4, ubuntu version) and built it against current svn. And I got
>>> Fluidsynth up and working in qsynth and it seemed quite responsive when
>>> I played on my piano, and that was actually even without a real-time
>>> kernel or rtprio. I tried changing the reverb and it worked fine.
>> well, you can make it play soundfonts just barely, but using qsynth gui
>> elements on most if not all aspects is now a nightmare, nothing is
>> liable, nothing stays put, all feels broken, what can i say?
> Can you provide some more details? Some steps to reproduce a particular
> issue for example?
ok. run qsynth. tweak the knobs, any knob. see if they do what's
expected. most probable they don't. quit. then run qsynth again. check
whether the knobs are where you left, as usual. nope. scratch head. you
did all as you always used to. what went wrong? puzzled. :)
>> just try to use qsynth against libfluidsynth 1.1.0, tweak some reverb or
>> chorus parameters, even master gain if you like and look at the channel
>> presets for instance. you'll see the trouble in no time. all the
>> advantage you had by using a gui like qsynth has just gone astray
>> unreliable, what a piece of junk it has become :(
>> sorry for the rant, if you were not a qsynth user before i'm sure you'll
>> never be one from now.
> Rui.. I think you are waaay over reacting! We have no intention of
> breaking QSynth! I put a lot of time and effort in FluidSynth 1.1.0.
> If there are issues with it, I very much want to fix them. I think one
> thing that has been lacking in the FluidSynth development cycle, is
> consistent testing. I did as much testing as I could and a few others
> stepped up to the plate, but to be honest I was really expecting more.
> It would have been great if these issues had come to our attention
> before the release. I have no problems releasing a quick update or
> taking down 1.1.0 altogether. In order to resolve the issues, I need to
> be able to reproduce the problems that you are experiencing though. So
> far, most of what I have heard from you, is that it is completely broken
> and very little more to help pin down WHAT is broken.
> I would really appreciate it, if you don't just start assuming that it
> is broken for good, its a piece of junk, etc etc.. It *really* pisses
> me off and is extremely counter productive!
sorry again. that wasn't my intention really. but it's a fact it is
broken, fubar. eheh. that was my first impression, yesterday. maybe it's
qsynth what has it all wrong, and for ages now.
but we can have a deal: just regress on the const char * thing and i'll
do my homework thereafter. first impressions often lie, ya know? maybe
it's just a few legacy hacks lurking in there. no sweat.
but one thing's for sure: qsynth as is known today is not recommended
for distribution with libfluidsynth 1.1.0--it would be just bad
marketing, worst pr ever for fluidsynth, if you know what i mean :)
>>>> it's a pity :( 1.1.0 seemed a good step forward but i'm afraid i will
>>>> avoid it for quite some time, at least until i have some and rewrite
>>>> qsynth from the ground up. or else, let qsynth simply rot to oblivion
>>> Do you think you need do do more than change the const char* stuff?
>> yes. note that changing the const char * stuff will only solve the build
>> process. it is the runtime gui behavior that is at stake.
> Let me say again.. I very much want to resolve these issues and get
> QSynth working as before, without changes required on your part.
> FluidSynth 1.1.0 is supposed to be binary compatible, so there shouldn't
> need to be anything you have to do.
it is binary compatible (you can certainly link old qsynth binaries to
newer libfluidsynth.so without a single issue).
i'm first inclined to investigate whether there were severe changes on
the parameter scaling and ranges, whatever (eg. reverb, chorus, master
gain) than anything else atm.
consider the regression of the const char * stuff (only on the
callbacks) and then i'll be more than pleased to do business again :))
cheers && thanks
rncbc aka Rui Nuno Capela