fluid-dev
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]