On 2 May 2014 13:13, David Henningsson wrote:
>
> Yes, calls to fluid_synth_write is what synthesizes the samples. It does so
> by calling an internal function that always render 64 samples (per channel,
> so 64 frames in ALSA terms).
> Fluid_synth_write compensates for you asking for more than 64
On 2014-05-02 02:31, sqweek wrote:
On 30 April 2014 23:38, David Henningsson wrote:
I have it working, but I haven't quite grasped _which_ samples the
fluid_synth_write call returns.
Well, if you first call fluid_synth_note_on, and after that call
fluid_synth_write_s16, then the note you ad
On 30 April 2014 23:38, David Henningsson wrote:
>> I have it working, but I haven't quite grasped _which_ samples the
>> fluid_synth_write call returns.
>
> Well, if you first call fluid_synth_note_on, and after that call
> fluid_synth_write_s16, then the note you added will sound from the
> begi
On 2014-04-27 06:14, sqweek wrote:
Hi folks,
Thanks for fluid-synth! I've been using it for the midi side of a
transcription program I'm developing. To ensure the midi notes are
synchronized with the audio stream, I'm using fluid_synth_write_s16
and mixing the streams together myself.
I have
On 27 April 2014 12:14, sqweek wrote:
> Is it reasonable to use the
> frame number directly as the sequencer's 'tick' (ie.
> fluid_sequencer_set_time_scale(seq, 1.0/44100.0) ) or is that too
> fine?
Sorry, after a second look at the API docs I see this is answered
quite clearly - set_time_scale s
Hi folks,
Thanks for fluid-synth! I've been using it for the midi side of a
transcription program I'm developing. To ensure the midi notes are
synchronized with the audio stream, I'm using fluid_synth_write_s16
and mixing the streams together myself.
I have it working, but I haven't quite grasped
