[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Sequencer with sample timer support

From: josh
Subject: Re: [fluid-dev] Sequencer with sample timer support
Date: Sun, 03 May 2009 17:32:48 -0400
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Quoting David Henningsson <address@hidden>:

During the weekend I've implemented sample timer support in the
sequencer, and I committed that change earlier today. Some notes:


- 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?

- You can also call fluid_sequencer_process manually if you want to use
the sequencer outside both the synth and the wall clock.

- About the coding style, I mainly tried to follow what was around me. I
thought that would be the best course of action since we're before the

I'm starting to think we may just want to leave it the way it is for now, as far as the coding style. Its not that bad really and it might make it easier to not make changes that aren't needed at this point and focus more on the good stuff ;)

- 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.

- In order for things to clean up nicely and still maintain backwards
compatibility, I decided to add a new sequencer event type. The midi
callback is called with this event upon destruction of the sequencer, or
when the client is unregistered. This is not strictly backwards
compatible but as long as existing code does nothing for unknown event
types it should not be a problem.

I agree, that doesn't sound like that will be a problem.

// David


reply via email to

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