[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Sequencer with sample timer support
From: |
David Henningsson |
Subject: |
Re: [fluid-dev] Sequencer with sample timer support |
Date: |
Mon, 04 May 2009 20:43:09 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090409) |
address@hidden skrev:
> Quoting David Henningsson <address@hidden>:
>> - To try the new sample timer functionality simply call
>> new_fluid_sequencer2(0) instead of new_fluid_sequencer(). That will
>> disable the system timer, which the seqbinder will detect and instead
>> enable the sample timer.
> Do you plan to leave the new_fluid_sequencer2() call or is that just for
> testing purposes? Maybe the sequencer timer selection should be a
> settings option?
I don't know if the settings are an option (pun intended!). The
sequencer does not use/depend on the settings infrastructure today, and
we can't wait until the client gets registered (and take the settings
from the synth). That is because the sequencer is multi-source and
multi-dest for midi events, but there can only be one timing source.
That said, the call is not set in stone for 1.1.0, I was thinking of
adding one more parameter that could optionally disable the mutex (for
speed) if you want to use the sequencer in a single-threaded context.
And if we fix a more advanced timing API for 1.1.0 (see the "timing
revisited" thread for some initial thoughts about this) perhaps the
boolean flag should be replaced with a pointer to some kind of structure.
>> - One question about glib: When we add new public API functions, should
>> these depend on glib or should we avoid it? In this context, I made a
>> new public API function that returned a boolean value, and didn't really
>> know whether it should return int or gboolean.
> I think we should avoid it for now. I don't see an immediate need to
> include glib in the public API. If it seems to make sense later, we can
> change things.
Okay, works for me.
// David