Hello Victor,
On Thu, Sep 23, 2010 at 12:26 PM, wrote:
> Regarding the first problem, I have identified in my first e-mail the API
> function that uses the
> reset-presets parameter. All you need to do is implement an option for the
> command-line to
> set that parameter. I can suggest the code
On Wed, Aug 11, 2010 at 1:00 PM, Pedro Lopez-Cabanillas
wrote:
>> Sounds good. Does it make sense to have separate midi.bank-select and
>> a midi.mode setting though? Why not just make it midi.mode and then
>> we can add additional functionality on to it in the future? That was
>> how it had be
ows the 1.0.9 logic.
The user could then force a particular mode with that setting.
Just some thoughts. I'll leave it up to you guys to decide ultimately
how it gets implemented.
Regards,
Elimar
On Wed, Aug 11, 2010 at 12:34 PM, Elimar Green wrote:
> On Mon, Aug 9, 2010 at 11:01 PM, Ped
On Mon, Aug 9, 2010 at 11:01 PM, Pedro Lopez-Cabanillas
wrote:
>
> I agree that we can leave the SYSEX stuff for a future release, avoiding the
> risk of spend too much time implementing and testing this feature. In
> addition to your code, I've included similar functionality in kmidimon.
>
> I di
On Sun, Aug 8, 2010 at 1:05 AM, David Henningsson
wrote:
> I started drafting on 1.1.2's changelog here:
>
> https://sourceforge.net/apps/trac/fluidsynth/wiki/ChangeLog1_1_2
>
> Big changes:
>
> * New CMake build system [plcl]
> * Winbuild directory dropped, autotools deprecated but still
>
It seems simple enough to revert the behavior to 1.0.9 functionality.
This should work fine in most cases, as far as the whole MSB is
actually LSB when only the MSB is received.
I can understand David wanting to release ASAP, since he has been
waiting for a while to do so. But I think the behavio
This was all basically implemented at one point in FluidSynth with a
settings option and detection of SYSEX MIDI mode change messages,
which would modify the current settings value dynamically. It was
removed because it was deemed incomplete (as far as all the additional
functionality which comes
On Thu, Aug 5, 2010 at 10:52 PM, Pedro Lopez-Cabanillas
wrote:
> On Friday, August 6, 2010, Elimar Green wrote:
>> > I want to remark the above quotation from the SF2 specification. SF2 bank
>> > numbers for melodic channels are numbers in the range 0 to 127, 7 bits.
&
On Thu, Aug 5, 2010 at 10:44 PM, David Henningsson
wrote:
> 2010-08-06 07:11, Elimar Green skrev:
>>
>> The idea behind having a fixed polyphony is to prevent CPU max out.
>> Ideally FluidSynth would be able to dynamically monitor CPU usage and
>> start killing voice
I think I forgot to reply to this message..
On Sun, Jul 4, 2010 at 2:04 AM, David Henningsson
wrote:
> On 2010-07-04 05:21, Elimar Green wrote:
>
> Hmm, I'll go with 1.1.2, the changes don't bring in any cool new
> features, from the user end point this is more of a bug
On Wed, Aug 4, 2010 at 1:43 PM, David Henningsson
wrote:
> 2010-08-02 03:17, Elimar Green skrev:
>> Cool. Seems like a user would at least know when a voice gets killed.
>> A nice addition would be the various scores that the killed voice
>> had, to know why it got killed
On Wed, Aug 4, 2010 at 1:21 PM, David Henningsson
wrote:
> 2010-08-04 11:59, Bernd Casper skrev:
>> Hi David,
>> thinking about this polyphony stuff, I wonder if FS could provide the
>> following addition to the current polyphony solution.
>> In the past two years I worked with FS, I always did r
On Wed, Aug 4, 2010 at 2:31 PM, Pedro Lopez-Cabanillas
wrote:
> On Wednesday, August 4, 2010, David Henningsson wrote:
>> 2010-08-03 22:48, Pedro Lopez-Cabanillas skrev:
>> > [Sorry, this is a bit long...]
>>
>> I'm glad you took the time to sort it out!
I second that. Thanks for taking the time
Its been a while since the topic of MIDI bank selection was discussed,
so I'm frustratingly in the dark again about it. From what I read a
bank/program change is sent as such:
Bank MSB (CC #0)
Bank LSB (CC #32)
Program change
So in that case if 1 was sent for MSB and 0 was sent for LSB it would
m
On Sun, Aug 1, 2010 at 11:48 AM, David Henningsson
wrote:
> 2010-08-01 18:50, Elimar Green skrev:
>
> Hey, you forgot "figure out a clever release name" :-) As English is not
> my native language, I'll gladly take suggestions from someone with a
> richer vocabul
On Sun, Aug 1, 2010 at 11:21 AM, David Henningsson
wrote:
>> I think synth.overflow.percussion might be more in line with existing
>> terminology. There may be more than one drum channel too, when we get
>> into supporting different MIDI modes.
>
> Okay, changed and committed. Speaking of termino
On Sat, Jul 31, 2010 at 2:00 PM, David Henningsson
wrote:
> Okay, so I found the bug I talked about in my previous mail, and
> committed the new voice overflow code.
>
> The new ones brings in five new weight settings (voice.overflow.*) for
> prioritizing volume, age, and special weights for drum
On Sat, Jul 31, 2010 at 11:58 AM, David Henningsson
wrote:
> 2010-07-14 11:34, David Henningsson skrev:
>
> Elimar, unless you want to do the actual release yourself, do you have a
> checklist for things that should be updated when performing a release?
>
I did have a FluidSynthReleases WIKI page
Ahh. Just a follow up on my previous email about the missing
FluidSynth tickets. Seems the Trac ticket report I was looking at
didn't include tickets which have not yet been accepted. But they
appear to still be there (when viewing all tickets, even closed ones).
Confusing. So there are a bunc
Hey guys,
Not sure I understand what is going on with this one, but it sounds
like it could perhaps be something I had a hand in breaking ;)
Therefore a feel slightly more responsibility in helping to resolve
it. Do we know what specific logic changed in FluidSynth and why?
I'm sure there is an S
Hello David and Fluid-Dev list,
A FluidSynth release in 1-3 weeks sounds fine to me. Although I have
not had a chance to test your latest changes and I'm not sure if I
will get the chance, as I'm still traveling about and don't have
access to a development system. I had thought I was going to ha
Hello David,
Definitely more progress than I expected.. Sweet!
On Wed, Jun 30, 2010 at 3:53 AM, David Henningsson
wrote:
>
> Yeah. To give you (and myself!) a rough overview, here are some work items:
>
> * Refactor envelopes, lfos and resonant filter into separate classes [DONE]
>
> * Move sou
Hello David,
Sounds like some progress! :) There have been discussions concerning
the voice stealing algorithm in the past. Here is a link to a
relevant thread in the list archives:
http://lists.nongnu.org/archive/html/fluid-dev/2005-10/msg00017.html
In summary, the thought was to add settings
Another one I forgot to CC the list on.
Elimar
On Wed, Jun 23, 2010 at 6:15 PM, Elimar Green wrote:
> Sounds like some good stuff to me! No objections either in regards to sub
> directories.
>
> Cheers!
>
> Elimar
>
>
> On Sun, Jun 20, 2010 at 4:15 AM, Davi
Oops, keep forgetting to CC the list.
Elimar
On Wed, Jun 23, 2010 at 6:22 PM, Elimar Green wrote:
> I'm also not very familiar with CMake. When running the curses based
> interface it seems fairly slick once you are used to it, as there are some
> rather unintuitive thi
Sounds good to me. Go ahead and change it as you wish :) The Trac ticket
system is another form of support, but I think for now we can just use the
mailing list, since there isn't a huge amount of issue reporting.
Elimar
On Thu, Jun 10, 2010 at 11:14 AM, David Henningsson <
launchpad@epost.
rge.net/apps/trac/fluidsynth/ticket/79 ?
> The attached patch doesn't change the queuing mechanism. Controllers are
> just reset immediately, so I don't expect any incompatibility with QSynth
> because of this change.
>
> Regards
>
> Sven
>
>
> On 06/05/2010 0
work in regards to returning the latest bank/program number when queried,
I'm all for that. Simply reverting back to the queued case though, will
break QSynth.
Cheers,
Elimar
On Fri, Jun 4, 2010 at 3:06 PM, Elimar Green wrote:
> Ticket reporting on SourceForge is working. I got a
Ticket reporting on SourceForge is working. I got an update. Just haven't
gotten around to researching why I originally changed it from queuing
program changes. I'm sure there was some reason to that, but event ordering
issues are obviously not acceptable. I'll try and get around to reviewing
t
mar
On Thu, May 27, 2010 at 4:48 PM, Orcan Ogetbil wrote:
> On Wed, May 26, 2010 at 8:55 PM, Elimar Green wrote:
> > Hello again FluidSynth developers and users.
> >
> > I think I have finally managed to move most services over to SourceForge.
>
> This may not be the
Hello again FluidSynth developers and users.
I think I have finally managed to move most services over to SourceForge.
The only thing left on Savannah is the mailing list (which will likely
remain) and the old download area. I didn't copy all the releases over to
the new site, since I didn't thin
o the
original user was in the comment.
Elimar
On Thu, May 20, 2010 at 10:25 AM, Elimar Green wrote:
> Thank you all for the responses and hosting offers! Things are rolling
> along with the SourceForge migration path and their technical support has
> been very quick to resolve issues as the
t though. Any ideas on how to do this with Trac
would be most helpful.
Best regards,
Elimar
On Wed, May 19, 2010 at 1:24 PM, David Henningsson <
launchpad@epost.diwic.se> wrote:
> On 2010-05-18 08:19, Elimar Green wrote:
> > Any thoughts? I think these are the options:
&
Well this whole migration thing is turning into more work than I had
anticipated. I imported SVN into the fluid project on Savannah, but quickly
realized that setting up a separate Trac install would need to do a periodic
sync to update appropriately. I then discovered that the place where I was
ck anything new into the SVN repository. Its OK if you do,
but it probably wont get migrated to the new SVN server. Once we have a new
SVN repository, I'll checkin an empty repository there, to try and hint to
anyone who attempts to use it, that it is the wrong one.
Be
35 matches
Mail list logo
