Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread Corbin Simpson
Anything that improves performance on smaller devices is a win for me. Posting from a mobile, pardon my terseness. ~ C. On Nov 16, 2009 6:41 PM, wrote: Quoting Pedro Lopez-Cabanillas : >> >> well, it's been a _long_ ti... Good point. Couldn't mute be accomplished by simply setting the volume M

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread josh
Quoting Pedro Lopez-Cabanillas : well, it's been a _long_ time missing function. if one can assign one channel preset, why can't the same be reset unassigned, just for closure, functional completeness sake? iirc, there were some requests on this regard from time to time, that is, a way to set on

Re: KMid (was Re: [fluid-dev] Re: lost connection to Jack server)

2009-11-16 Thread jimmy
--- On Mon, 11/16/09, Pedro Lopez-Cabanillas wrote: > From: Pedro Lopez-Cabanillas > > Anonymous SVN repository (provisional) > svn://anonsvn.kde.org/home/kde/trunk/playground/multimedia/kmid2/ > Compile it with KDE 4.2 or later. > > Little user documentation, at this moment: > http://userba

Re: KMid (was Re: [fluid-dev] Re: lost connection to Jack server)

2009-11-16 Thread Pedro Lopez-Cabanillas
On Wednesday, October 21, 2009, jimmy wrote: > > > I used to use Kmid, but no one ported it to Qt4/Kde4 > > > > I'm already starting the adoption process. > > Alright, good to know.  You got SVN/CVS, discussion group for it somewhere? Anonymous SVN repository (provisional) svn://anonsvn.kde.org/ho

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread Pedro Lopez-Cabanillas
On Monday, November 16, 2009, Rui Nuno Capela wrote: > On Mon, 16 Nov 2009 00:46:43 -0800, j...@resonance.org wrote: > >> keep, force or (re)set one channel preset as unassigned ? > > > > No it doesn't seem there is a way to set a single channel to > > unassigned with the public API. There is a pr

Re: [fluid-dev] Thread safety long-term thoughts

2009-11-16 Thread josh
Quoting David Henningsson : j...@resonance.org wrote: Quoting David Henningsson : The fluid_synth is becoming increasingly large and complex. I've started to think of it as two parts, a state machine, and a voice renderer. The voice renderer is strict real-time, and corresponds roughly to fluid

Re: [fluid-dev] Thread safety long-term thoughts

2009-11-16 Thread David Henningsson
j...@resonance.org wrote: Quoting David Henningsson : The fluid_synth is becoming increasingly large and complex. I've started to think of it as two parts, a state machine, and a voice renderer. The voice renderer is strict real-time, and corresponds roughly to fluid_synth_one_block and everythi

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread josh
Quoting David Henningsson : j...@resonance.org wrote: Quoting Rui Nuno Capela : We always have a chance :) Sure I can add it. How about something like: int fluid_synth_program_clear (fluid_synth_t *synth, int chan); Something to note though, is that it will keep its sfont ID, bank and p

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread David Henningsson
j...@resonance.org wrote: Quoting Rui Nuno Capela : We always have a chance :) Sure I can add it. How about something like: int fluid_synth_program_clear (fluid_synth_t *synth, int chan); Something to note though, is that it will keep its sfont ID, bank and program numbers. Why can't we

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread josh
Quoting Rui Nuno Capela : No it doesn't seem there is a way to set a single channel to unassigned with the public API. There is a private function called fluid_synth_set_preset, which could be used to set the preset to NULL, which would have the effect of setting it to unassigned, but that isn't

Re: [fluid-dev] Thread safety long-term thoughts

2009-11-16 Thread jimmy
> Date: Mon, 16 Nov 2009 00:37:40 -0800 > From: j...@resonance.org > > Quoting David Henningsson : > > > However, nothing new without a downside. Since the > sample is used by > > the voice renderer, freeing a preset or soundfont is > not solved easily. > > But outlined, first we should check if

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread Rui Nuno Capela
On Mon, 16 Nov 2009 00:46:43 -0800, j...@resonance.org wrote: > Quoting Rui Nuno Capela : >>> int fluid_synth_get_channel_preset_info >>> (fluid_synth_t *synth, int chan, fluid_preset_info_t *info); >>> >> >> looks good enough. >> > > I have a patch against QSynth 0.3.4 which adds support for the

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread josh
Quoting Rui Nuno Capela : int fluid_synth_get_channel_preset_info (fluid_synth_t *synth, int chan, fluid_preset_info_t *info); looks good enough. I have a patch against QSynth 0.3.4 which adds support for the new API with backwards compatibility with older versions. I'll send it your w

Re: [fluid-dev] Thread safety long-term thoughts

2009-11-16 Thread josh
Quoting David Henningsson : While the recent thread safety improvements are much better than the previous handling (since the previous had unpredictable crashes), the recent postings, the shadow variable workaround, and the multi-core support got me thinking. See this as long-term thoughts for di

Re: [fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread Rui Nuno Capela
On Mon, 16 Nov 2009 00:04:17 -0800, j...@resonance.org wrote: > I just committed code to make preset querying use the most recent > assigned preset. I also added the code below to the public API as per > previous discussions. > > I'm not completely happy with the new API though, since it does

[fluid-dev] More commits on the way to 1.1.1

2009-11-16 Thread josh
I just committed code to make preset querying use the most recent assigned preset. I also added the code below to the public API as per previous discussions. I'm not completely happy with the new API though, since it does seem really close to fluid_synth_get_program() in functionality and