Thanks very much David.
It was great working with you throughout the concept and implementation of
this new feature.
Also the adding an example in the documentation and for providing easy links
> in the email above was much appreciated!
>
No problem. I love Launchpad. I really recommend anyone w
On 2011-02-20 07:27, Matt Giuca wrote:
I have updated the midi-buffer branch with the previous two suggestions:
1. fluid_player_add_mem now copies the buffer before it stores it, so
the caller can now free it immediately (and it is now the caller's
responsibility to free).
2. Internally, fluid_mi
I have updated the midi-buffer branch with the previous two suggestions:
1. fluid_player_add_mem now copies the buffer before it stores it, so the
caller can now free it immediately (and it is now the caller's
responsibility to free).
2. Internally, fluid_midi_file now uses int buf_len and buf_pos
Hi David,
In response to your post here:
http://lists.nongnu.org/archive/html/fluid-dev/2011-01/msg3.html
> Well, for the memory allocation issue it sounds like we both are leaning
> towards #5 as in copying the memory. I don't think the
> inefficiency is an issue and it gives FS the most op
> Many thanks for this. I never did find the time to finish up my
> SDL_mixer patch and send it upstream because life has taken over but
> this looks great.
Tell me about it ... took a long time to get this buffer patch done as well.
> I look forward to cutting my patch in half. :)
>
Well the
On Sat, 4 Dec 2010 13:55:51 +1100
Matt Giuca wrote:
> I have completed an initial cut at the implementation of the new
> fluid_player_add_mem API call, which lets you add a MIDI file to the
> playlist from a buffer in memory, rather than a filename.
Many thanks for this. I never did find the tim
Hi guys,
I have completed an initial cut at the implementation of the new
fluid_player_add_mem API call, which lets you add a MIDI file to the
playlist from a buffer in memory, rather than a filename. This
required extensive re-architecting of the internal mechanism for
loading files. The old flui
I have started making the changes (the major internal change to fluid_midi
is done; it now loads the file to memory at the start and does all the
parsing from the memory buffer). It currently "owns" the pointer (garbage
collection choice #2), but we can discuss that further.
The code is in a branc
On 10/19/2010 12:27 PM, David Henningsson wrote:
On 2010-10-19 09:47, Graham Wykes wrote:
Would there be value in looking at the patch than Jim Henry mentioned
(given that it has been effectively tested for many years by hundreds of
users of Miditzer) to see whether it is compatible with the c
>
> So to summarize, the possible approaches are:
>> 1. Stealing from client-malloc; fluid will call free(). Won't work with
>> different allocators other than malloc.
>> 2. Stealing from client-fluid_alloc; fluid will call fluid_free(). At
>> least it lets fluid control the allocator.
>> 3. Borro
On Tuesday 19 October 2010, David Henningsson wrote:
> If you feel that the current API needs incompatible
> > changes, then this feature should go in a library version 2. That's all.
Not a
> > big deal, this is going to happen sooner or later.
>
> If you're talking about dropping backwards compa
On Tuesday 19 October 2010, Matt Giuca wrote:
> ...as long as it doesn't break anything else, which is the hard part.
>
> I think he meant nobody has the right to stop you implementing it in your
> own private branch. It's convincing others to accept them that's the hard
> part :) Which I've le
On Tuesday 19 October 2010, Jim Henry wrote:
> Pedro,
>
> It sounds like you are suggesting a feature that the Miditzer virtual
> organ uses. A number of years ago Sebastian Frippiat suggested extending
> FluidSynth so that the MIDI Player would pass the MIDI events to the
> caller rather tha
On 2010-10-19 11:21, Matt Giuca wrote:
[]
I've cut down the rest of the text, just because I don't think there is
more to add to it.
So to summarize, the possible approaches are:
1. Stealing from client-malloc; fluid will call free(). Won't work with
different allocators other than malloc
On 2010-10-19 09:47, Graham Wykes wrote:
On 19/10/2010, at 6:07 PM, David Henningsson wrote:
On 2010-10-19 00:02, Pedro Lopez-Cabanillas wrote:
On Monday 18 October 2010, Matt Giuca wrote:
So my questions for any interested observers (especially FluidSynth
developers):
1. Is this feature
>
> We could also copy the memory. While copying memory around is inoptimal,
> that might be a secondary concern. At least that would give us the most
> future flexibility.
Oh yeah, that was my other thought. I think the problem with that is that
again, in almost all cases I can think of, you'll
On 19/10/2010, at 6:07 PM, David Henningsson wrote:
On 2010-10-19 00:02, Pedro Lopez-Cabanillas wrote:
On Monday 18 October 2010, Matt Giuca wrote:
So my questions for any interested observers (especially FluidSynth
developers):
1. Is this feature worth implementing at all?
If you are mo
On 2010-10-19 00:02, Pedro Lopez-Cabanillas wrote:
On Monday 18 October 2010, Matt Giuca wrote:
So my questions for any interested observers (especially FluidSynth
developers):
1. Is this feature worth implementing at all?
If you are motivated to do this work, then go ahead. Nobody has any
On 2010-10-19 02:07, Matt Giuca wrote:
Hi David, James, Pedro,
Thanks for a quick discussion.
David Henningson wrote:
...although this would only be in fluid_midi.c, right? It wouldn't affect other
files.
Correct.
I'd personally prefer the client handling memory entirely. This has two
a
Pedro,
It sounds like you are suggesting a feature that the Miditzer virtual
organ uses. A number of years ago Sebastian Frippiat suggested extending
FluidSynth so that the MIDI Player would pass the MIDI events to the
caller rather than playing them. At the time there was no interest in
his
Hi David, James, Pedro,
Thanks for a quick discussion.
David Henningson wrote:
> ...although this would only be in fluid_midi.c, right? It wouldn't affect
> other files.
Correct.
> I'd personally prefer the client handling memory entirely. This has two
> advantages:
> * We won't have to do
On Monday 18 October 2010, Matt Giuca wrote:
> So my questions for any interested observers (especially FluidSynth
developers):
>
> 1. Is this feature worth implementing at all?
If you are motivated to do this work, then go ahead. Nobody has any right to
stop you of adding an improvement that y
On Mon, 18 Oct 2010 16:53:07 +0200
David Henningsson wrote:
> struct loadable_file
> {
> char* filename;
> void* data;
> size_t data_length;
> }
>
> (You don't need an enum because either one will be NULL.)
>
> But then, at file load time, if filename != NULL, load the file in
On 2010-10-18 16:14, Matt Giuca wrote:
There was a discussion in the thread "FluidSynth backend for
SDL_mixer" about the difficulty with the current implementation of the
FluidSynth API's MIDI file player, in that it will only load a MIDI
file via a filename (fluid_player_add --
http://fluidsynth
There was a discussion in the thread "FluidSynth backend for
SDL_mixer" about the difficulty with the current implementation of the
FluidSynth API's MIDI file player, in that it will only load a MIDI
file via a filename (fluid_player_add --
http://fluidsynth.sourceforge.net/api/midi_8h.html#a1ac5b5
25 matches
Mail list logo
