FluidR3.sf3 is an heresy !
On Tue, Apr 24, 2018 at 11:54 PM, Marcus Weseloh wrote:
> Hi Philippe,
>
> 2018-04-24 21:32 GMT+02:00 Philippe Simons :
> >> So I think I'm probably the best placed to speak since I'm using
> fluidsynth both as a MIDI
Hi Philippe,
2018-04-24 21:32 GMT+02:00 Philippe Simons :
>> So I think I'm probably the best placed to speak since I'm using
fluidsynth both as a MIDI player and as a real-time synthesizer on Android.
> Obviously I didn't wait for this feature to be implemented to
Hi again,
just out of curiosity, I analysed a large library of MIDI files with regard
to the number of program change events that they contain. I downloaded the
geocities collection from
https://archive.org/details/archiveteam-geocities-midi-collection-2009,
containing around 51000 MIDI files
Hi all,
So I think I'm probably the best placed to speak since I'm using fluidsynth
both as a MIDI player and as a real-time synthesizer on Android.
Obviously I didn't wait for this feature to be implemented to create my
applications, so I can say that I don't them... like at all.
for the
Hi Tom,
yes, it's a little hackish... but not the part you mention, I think.
Overriding the "authority" of the synth over when and which samples to load
is perfectly valid, in my opinion. Yes, those functions would also need to
be exposed to the user via the shell and API, but that would actually
Sorry, I think it's a hack. Dynamic sample loading is implemented in a way to
allow the synth to control when to load or unload presets and samples.
Introducing this fluid_defpreset_t::loaded_manually flag overrides the synth's
authority. Instead the midi player gets in charge of that.
If
lol I just re read myself, but you understood what I meant :p
On Mon, Apr 23, 2018 at 10:15 PM, Marcus Weseloh wrote:
> Hi Philippe,
>
> 2018-04-23 20:16 GMT+02:00 Philippe Simons :
>
>> Seems to forks fine on Android.
>>
>
> Excellent, thanks a lot
Hi Philippe,
2018-04-23 20:16 GMT+02:00 Philippe Simons :
> Seems to forks fine on Android.
>
Excellent, thanks a lot for testing it!
Cheers,
Marcus
___
fluid-dev mailing list
fluid-dev@nongnu.org
Hi Tom,
2018-04-23 19:25 GMT+02:00 Tom M. :
> I keep thinking about this preloading feature and I'm not yet fully
> convinced of it. I see quite high obstacles for it being beneficial i.e.:
>
> - We need a user who plays MIDI files via command line and listens to them
>
Seems to forks fine on Android.
On Mon, Apr 23, 2018 at 7:25 PM, Tom M. wrote:
> I keep thinking about this preloading feature and I'm not yet fully
> convinced of it. I see quite high obstacles for it being beneficial i.e.:
>
> - We need a user who plays MIDI files via
I keep thinking about this preloading feature and I'm not yet fully convinced
of it. I see quite high obstacles for it being beneficial i.e.:
- We need a user who plays MIDI files via command line and listens to them in
real-time.
- The user must actively enable on demand sample loading
- The
I'll give it a shot on my android fork
On Sun, Apr 22, 2018 at 7:26 PM, Marcus Weseloh wrote:
> Hi all,
>
> the dynamic-sample-loading branch has been merged into master. I will
> follow up with a few more pull-requests that add more bells & whistles to
> the feature, like
Hi all,
the dynamic-sample-loading branch has been merged into master. I will
follow up with a few more pull-requests that add more bells & whistles to
the feature, like the preloading function, but also some changes that
reduce the memory consumption of the structural information of Soundfonts.
On 18 April 2018 at 20:11, Marcus Weseloh wrote:
> 2018-04-18 11:10 GMT+02:00 sqweek :
> > ie. there's a hard realtime requirement here in some usages - is it
> still possible to meet that requirement with the samples being
> loaded/unloaded?
>
> Please
Hi sqweek,
2018-04-18 11:10 GMT+02:00 sqweek :
> ie. there's a hard realtime requirement here in some usages - is it still
possible to meet that requirement with the samples being loaded/unloaded?
No, with samples being loaded and unloaded on demand, requirements like
On 16 April 2018 at 05:18, Marcus Weseloh wrote:
> Hi all,
>
> I've finished the first draft of the dynamic sample loading. You can see
> the change in this pull request:
> https://github.com/FluidSynth/fluidsynth/pull/366
>
> If you want to try out the changes, please
Hi all,
I've finished the first draft of the dynamic sample loading. You can see
the change in this pull request:
https://github.com/FluidSynth/fluidsynth/pull/366
If you want to try out the changes, please check out the
dynamic-sample-loading branch:
ependent . In all cases if Marcus need any feedback to verify any
works in progress on Windows don't hesitate to ask.
jjc
> Message du 06/04/18 17:49
> De : "Tom M."
> A : fluid-dev@nongnu.org
> Copie à : "Marcus Weseloh" , "Ceresa Jean-Jacques"
>
Let me just clarify: As of 1.1.7 audio rendering does not lock any mutex.
Previously, you had the option to set "synth.parallel-render" to false, causing
any thread attempting to enter fluid_synth_write_*() to acquire the lock.
However, this caused bug #192, because the current synthesization
actual
> inner fluidsynth structure.
>
> cheers.
>
> jjc
>
>
>
>
>
>
>
> > Message du 05/04/18 20:05
> > De : "Marcus Weseloh" <mar...@weseloh.cc>
> > A : "FluidSynth mailing list" <fluid-dev@nongnu.org>
> > Copie à :
&
l inner
fluidsynth structure.
cheers.
jjc
> Message du 05/04/18 20:05
> De : "Marcus Weseloh"
> A : "FluidSynth mailing list"
> Copie à :
> Objet : Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts
>
>
Hi all,
>
thank you very m
Hi all,
thank you very much for your feedback! Good to know that there is interest
for this feature outside of my particular use-case.
I've decided to go the route Tom suggested: concentrating on the samples
first and leaving the "structural" information loading unchanged for now.
That will
Hello,
Just wanted to add a positive thought.
Soundfont editor developper could benefit of this "memory economic" feature as
this kind of application needs often to avoid memory wasting.
A part theses many others (off line) applications that must care with memory
usage, the one that
>
> I would really like to get your thoughts on this. Do you think it's a
> feature that other Fluidsynth users could benefit from?
>
Great work! Yes, this would be something the Radium music editor would
benefit from.
Radium uses libfluidsynth a as softsynth and not as a MIDI player. This
von Tom M.
Gesendet: Dienstag, 3. April 2018 21:13
An: Marcus Weseloh
Cc: fluid-dev@nongnu.org
Betreff: Re: [fluid-dev] Proposal for a new feature: lazy-loading of
SoundFonts
So briefly, your main motivation for this feature is memory usage.
Absolutely comprehensible on an embedded system. You the
So briefly, your main motivation for this feature is memory usage. Absolutely
comprehensible on an embedded system. You therefore want to parse only
"high-level preset information" of a SF file. I'm missing information about SF2
Instruments here.
Counterproposal: Instead of lazy-loading
26 matches
Mail list logo