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 player and as a real-time synthesizer on Android.
>
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 create my
applications, so I can
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 that
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 player,
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 sampl
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 for testing it!
>
> Cheers,
>
> Marcus
>
> _
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
https://lists.nongnu.org/mailman/listinfo/fluid-dev
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
> in real-time.
>
- The user
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 command line and listens
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 MI
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 the preloading functio
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 understand that the dynamic sample loading
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
guaranteed immediate availab
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 check out the
> dynamic-sam
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:
https://github.com/FluidSynth/fluidsynth/tree
per dependent . 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&qu
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
i
t;
> 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
>
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 bring
rt
feature".
All the best.
jjc
> Message du 02/04/18 23:39
> De : "Marcus Weseloh"
> A : "FluidSynth mailing list"
> Copie à :
> Objet : [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts
>
>
Hi all,
>
I would like to prop
>
> 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
feature
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 structu
Hi all,
I would like to propose (and then implement) a new feature to Fluidsynth;
lazy-loading of Soundfont data.
Let me first explain the problem I want to solve:
I'm building a musical instrument (including the hardware) that uses
Fluidsynth for sound output. The player has up to 10 channels av
27 matches
Mail list logo
