Quoting David Henningsson :
Quoting Rui Nuno Capela :
I was thinking the same thing, in regards to notification callbacks.
I'm not saying my way of thinking is the one and only right way forward,
but given state-machine and voice-renderer thinking, the notification
callback way is the wrong w
Quoting Rui Nuno Capela :
All those ranges should be exactly the same as they have been for
FluidSynth from the beginning. At least there was no intention of
changing them from what they were before. They weren't well documented
in prior versions though. If for some reason FluidSynth behaves
d
> Quoting Rui Nuno Capela :
>
> I was thinking the same thing, in regards to notification callbacks.
I'm not saying my way of thinking is the one and only right way forward,
but given state-machine and voice-renderer thinking, the notification
callback way is the wrong way. The right way for syste
Quoting Rui Nuno Capela :
On Wed, 16 Dec 2009 16:15:21 -0800, j...@resonance.org wrote:
Quoting Rui Nuno Capela :
i think i have this all fluid_synth_program_reset() thing gone right
now.
qsynth svn trunk bumped to 0.3.4.12 and it is behaving a lot better now
:) or so it seems.
I check
On 12/16/2009 11:52 PM, j...@resonance.org wrote:
> Quoting Rui Nuno Capela :
>>
>>> Chorus:
>>> nr: 0 - 99
>>> level: 0.0 - 1.0
>>> speed: 0.29 - 5.0
>>> depth_ms: 0.0-21.0 is safe for sample rate values up to 96KHz
>>>
>>> Looks like QSynth goes up to 100 on the "nr" parameter and 10.0 on the
>>>
On Wed, 16 Dec 2009 16:15:21 -0800, j...@resonance.org wrote:
> Quoting Rui Nuno Capela :
>>
>> i think i have this all fluid_synth_program_reset() thing gone right
now.
>>
>> qsynth svn trunk bumped to 0.3.4.12 and it is behaving a lot better now
>> :) or so it seems.
>>
>
>
> I checked it out a
Quoting Rui Nuno Capela :
i think i have this all fluid_synth_program_reset() thing gone right now.
qsynth svn trunk bumped to 0.3.4.12 and it is behaving a lot better now
:) or so it seems.
I checked it out and gave it a whirl. Seemed to work better. I did
notice another slight issue t
Hello Rui,
Quoting Rui Nuno Capela :
On Tue, 15 Dec 2009 19:02:19 -0800, j...@resonance.org wrote:
I committed some additional changes which reverts the work that was
done with Reverb/Chorus in regards to queuing the events and
processing them in synthesis context. They are now processed
imme
On 12/16/2009 08:30 AM, Rui Nuno Capela wrote:
> On Tue, 15 Dec 2009 15:36:31 -0800, j...@resonance.org wrote:
>> Quoting Rui Nuno Capela :
>>> On 12/15/2009 07:41 PM, j...@resonance.org wrote:
Ahh, and I thought that was going to be the golden commit.
>>>
>>> aha, ya know, all that glitters a
On Tue, 15 Dec 2009 19:02:19 -0800, j...@resonance.org wrote:
> I committed some additional changes which reverts the work that was
> done with Reverb/Chorus in regards to queuing the events and
> processing them in synthesis context. They are now processed
> immediately and with a mutex to
On Tue, 15 Dec 2009 15:36:31 -0800, j...@resonance.org wrote:
> Quoting Rui Nuno Capela :
>> On 12/15/2009 07:41 PM, j...@resonance.org wrote:
>>> Ahh, and I thought that was going to be the golden commit.
>>
>> aha, ya know, all that glitters ain't gold :)
>>
>
> We'll see about that ;)
>
>> and
I committed some additional changes which reverts the work that was
done with Reverb/Chorus in regards to queuing the events and
processing them in synthesis context. They are now processed
immediately and with a mutex to ensure multiple threads don't try to
assign values at the same time.
Quoting Rui Nuno Capela :
On 12/15/2009 07:41 PM, j...@resonance.org wrote:
Ahh, and I thought that was going to be the golden commit.
aha, ya know, all that glitters ain't gold :)
We'll see about that ;)
and that will get you to qsynth 0.3.4.11, the one i fuss with ;)
Ok, now usin
On 12/15/2009 07:41 PM, j...@resonance.org wrote:
> Ahh, and I thought that was going to be the golden commit.
>
aha, ya know, all that glitters ain't gold :)
> Quoting Rui Nuno Capela :
>>
>> re. svn trunk r278
>>
>> fluid_synth_unset_program() seems to do its deeds now, but ...
>>
>> that fal
Ahh, and I thought that was going to be the golden commit.
Quoting Rui Nuno Capela :
re. svn trunk r278
fluid_synth_unset_program() seems to do its deeds now, but ...
that fallback logic needs work still. or else. for example, simple
soundfonts which define fewer instruments/presets than the
On 12/14/2009 07:09 PM, j...@resonance.org wrote:
> Oops. Should work now. The logic which tries to fallback to a valid
> preset was getting executed.
>
> With fluid_synth_unset_program() its currently leaving the bank number
> as it was, but clearing the program number. Does this seem OK or sh
Oops. Should work now. The logic which tries to fallback to a valid
preset was getting executed.
With fluid_synth_unset_program() its currently leaving the bank number
as it was, but clearing the program number. Does this seem OK or
should it set the bank to 0? The effect that this woul
On 12/14/2009 08:26 AM, Rui Nuno Capela wrote:
> On Sun, 13 Dec 2009 20:00:35 -0800, j...@resonance.org wrote:
>> Hello Rui,
>>
>> I just committed what I hope are fixes to the last 2 QSynth
>> compatibility issues. It looked like there was an event queuing issue
>> in regards to bank and prog
On Sun, 13 Dec 2009 20:00:35 -0800, j...@resonance.org wrote:
> Hello Rui,
>
> I just committed what I hope are fixes to the last 2 QSynth
> compatibility issues. It looked like there was an event queuing issue
> in regards to bank and program change messages, which was causing the
> bank t
19 matches
Mail list logo
