Re: [fluid-dev] Is it possible to immigrate FluidSynth to a DSP(ADSP21xxx) or an CORTEX-M4 CPU? (Stan Zhang)

[Element Green]

I personally find it rather confusing that anyone would use the GPL or
LGPL for non-software, since they are specifically designed for that
purpose.  Having said that though, I don't see how a GPL SoundFont
could be construed as requiring the software that is loading it to
also be GPL, since there is really no "linking" occurring.  The clause
in the GPL that requires the source code to be made available with any
changes that have been made (if publicly distributed), seems to also
be non-applicable, since there is no source code.  I could see how it
might mean that any changes made to the SoundFont would also need to
be made publicly available, in a commercial product or otherwise,
especially in the case of an embedded device, where the user might not
be able to so easily extract the SoundFont from the device.

Just wanted to set that straight, since it seems like there is so much
misinformation that goes around in regards to software licenses, in
particular the GPL and LGPL.  I'd suggest people use the creative
commons licenses for their SoundFont files or better yet, make them
public domain and make it easy on anyone wanting to utilize it in
their own music.  From what I have seen even most of the creative
commons licenses require attribution (crediting the author).  Imagine
listing all of the authors of individual samples on the back of your
CD, whether it be a simple snare or analog synth sample.  I question
how many free SoundFont files are completely original works to begin
with, since a lot of sample borrowing happens out there.  If you want
to make a buck on your SoundFont, make it not for commercial use and
sell commercial licenses.

</GPL_LGPL_SoundFont_Rant>

Element Green


On Thu, Mar 21, 2013 at 8:38 PM, Aere Greenway
<address@hidden> wrote:
> Stan:
>
> I have no information on the soundfont you mentioned below, and I have not
> tried it.  You need to carefully read the license agreement in the
> installation CD you mentioned.
>
> The ones I mentioned at are distributed under the GPL license, at least,
> where they are in the Ubuntu Linux repository, I presume they must be.
>
> If what you are developing is not to be distributed under the GPL license,
> that causes (in my non-legal opinion) problems with the license terms.
>
> To my understanding (for a non-GPL license), you could direct users
> regarding where and how to obtain any GPL-license soundfonts, and they would
> be the ones to agree to the license terms.  Once they obtain any such
> soundfonts, they would need a way to install them.
>
> If my information above is incorrect, I am hoping people on the mailing list
> with more knowledge of the area will point out any inaccuracies.
>
> - Aere
>
> On 03/21/2013 07:07 PM, *simple* wrote:
>
> Aere,
>
> This is my first reply to the mailing list. I am not sure if there is any
> format not good.
>
> Thanks for your suggestion. The sound font I am going to use is copied from
> Creative's sound card installation CD: CT4MGM.SF2 (4M bytes). The quality
> should be OK for me. But I am not sure if this is a free sound font. Do you
> have any idea on this?
> Stan Zhang (China)
>
> ------------------ Original ------------------
> From:  "fluid-dev-request"<address@hidden>;
> Date:  Thu, Mar 21, 2013 00:01 AM
> To:  "fluid-dev"<address@hidden>;
> Subject:  fluid-dev Digest, Vol 119, Issue 4
>
> Send fluid-dev mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fluid-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Is it possible to immigrate FluidSynth to a
>       DSP(ADSP21xxx) or an CORTEX-M4 CPU? (Aere Greenway)
>    2. Re: Feature Request: Load everything into RAM to make program
>       changes instant (Nils Gey)
>    3. Re: Feature Request: Load everything into RAM to make program
>       changes instant (David Henningsson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 Mar 2013 10:15:59 -0600
> From: Aere Greenway <address@hidden>
> To: FluidSynth mailing list <address@hidden>
> Cc: *simple* <address@hidden>
> Subject: Re: [fluid-dev] Is it possible to immigrate FluidSynth to a
> DSP(ADSP21xxx) or an CORTEX-M4 CPU?
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> My response is perhaps a side-note regarding your question.
>
> In my experience, the better soundfonts are nearly 60 megabytes in
> size.  The Fluid_R3GM soundfont (which is my favorite of the free
> soundfonts) is 142 megabytes.
>
> If you must live with a 32 megabyte limit for soundfonts, the "TimGM6mb"
> soundfont (distributed with MuseScore) is pretty good, but its French
> Horn sound is out-of-tune in a fair number of notes.  But at least, this
> 6-megabyte soundfont doesn't sound overall like a toy musical instrument.
>
> - Aere
>
> On 03/19/2013 08:17 AM, *simple* wrote:
>> I plan to immigrate FluidSynth to CORTEX-M4. Could anyone please give
>> me some hints?
>> The Cortex-M4 system I am going to use: 1MByte flash code memory.
>> 192KByte internal SRAM, with FPU, 168MHz, 32MByte external parallel
>> NOR flash (for soundfont). Is it possible to immigrate Fluidsynth to
>> cortex-M4 with these limits (64 polyphony)?
>> I've tried to use optimized cortex-m4 ASM to replace FluidSYnth's
>> lowpass filter, linear interpolation, reverb, chorus. And I also tried
>> to reduced the memory needed down to 240KBytes. At this moment,
>> without concerning the low speed of reading external flash
>> (soundfont), it looks that 192KByte, 168MHz limit would be OK.
>> However, the low speed of reading external flash seems to be a big
>> problem:
>> the flash IC is 90ns, which means you can read 16bits (1 sample point)
>> every 90ns. To make a 64 polyphone rendering, and output at 44.1kHz,
>> for each output sample, you need to read at least 64*2 samples (if
>> linear interpolation is used), this is 128*90ns=11.52us, which is
>> already 50% time of the sample period of 44.1KHz. So, I am afraid I
>> will have to use DMA to do the readings to the audio samples, so that
>> rendering and transfering audio sample data at the same time. This
>> will need some more (maybe 10KBytes) memory buffering space, and
>> increase the complicacy. I wonder if it is really the only choice here
>> to do DMA for transferring audio sample data?
>> Does anybody here have similar question/experience? And what's your
>> solution?
>>
>>
>> _______________________________________________
>> fluid-dev mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>
> --
> Sincerely,
> Aere
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.nongnu.org/archive/html/fluid-dev/attachments/20130319/249a16a0/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 19 Mar 2013 17:54:03 +0100
> From: Nils Gey <address@hidden>
> To: David Henningsson <address@hidden>
> Cc: FluidSynth mailing list <address@hidden>
> Subject: Re: [fluid-dev] Feature Request: Load everything into RAM to
> make program changes instant
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=US-ASCII
>
> On Tue, 19 Mar 2013 14:14:47 +0100
> David Henningsson <address@hidden> wrote:
>
>> On 03/19/2013 01:55 PM, Nils Gey wrote:
>> > Hello,
>> >
>> > could you please add a running or loading mode to load an sf2 completely
>> > into memory?
>> > The goal is that program changes (and bank?) get rid of the load hiccups
>> > and the new sound is available in an instant.
>>
>> It already is loaded completely into memory. It tries to lock it too, so
>> it does not get swapped out.
>> (If you get the message "Failed to pin sample data to RAM, swapping is
>> possible" warning, you know it failed.)
>>
>> Any hiccups you might get would be related to CPU bound activities
>> happening at program/bank changes, but these should not cause underruns
>> if priorities are set right; possibly delays to midi events coming after.
>>
>> Is this Windows or Linux, btw? I don't know the Windows parts very well.
>>
>> // David
>>
>
> Linux.
>
> Then maybe it is a different issue? Does fluidsynth make sure that program
> changes (and CCs etc.) which happen on the same tick/time value or are
> received at the same time (via the lib) as note ons always come first?
>
> My problem is that if I send a program change and the first note at the same
> time the first note plays back with the old program, either program 0 on
> program start or if fluidsynth kept running in between the current channel
> program.
>
> Nils
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 19 Mar 2013 20:03:23 +0100
> From: David Henningsson <address@hidden>
> To: Nils Gey <address@hidden>
> Cc: FluidSynth mailing list <address@hidden>
> Subject: Re: [fluid-dev] Feature Request: Load everything into RAM to
> make program changes instant
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/19/2013 05:54 PM, Nils Gey wrote:
>> On Tue, 19 Mar 2013 14:14:47 +0100
>> David Henningsson <address@hidden> wrote:
>>
>>> On 03/19/2013 01:55 PM, Nils Gey wrote:
>>>> Hello,
>>>>
>>>> could you please add a running or loading mode to load an sf2 completely
>>>> into memory?
>>>> The goal is that program changes (and bank?) get rid of the load hiccups
>>>> and the new sound is available in an instant.
>>>
>>> It already is loaded completely into memory. It tries to lock it too, so
>>> it does not get swapped out.
>>> (If you get the message "Failed to pin sample data to RAM, swapping is
>>> possible" warning, you know it failed.)
>>>
>>> Any hiccups you might get would be related to CPU bound activities
>>> happening at program/bank changes, but these should not cause underruns
>>> if priorities are set right; possibly delays to midi events coming after.
>>>
>>> Is this Windows or Linux, btw? I don't know the Windows parts very well.
>>>
>>> // David
>>>
>>
>> Linux.
>>
>> Then maybe it is a different issue? Does fluidsynth make sure that program
>> changes (and CCs etc.) which happen on the same tick/time value or are
>> received at the same time (via the lib) as note ons always come first?
>>
>> My problem is that if I send a program change and the first note at the
>> same time the first note plays back with the old program, either program 0
>> on program start or if fluidsynth kept running in between the current
>> channel program.
>
> What version of FluidSynth are you running? 1.1.0 and 1.1.1 could have
> had some ordering bugs.
>
> In all other versions, AFAIK, things happen in the order they are sent
> to the engine. For MIDI files, that would be in the order you find the
> events in the MIDI file. There is no reordering.
>
> Could you clarify how you mean that you send two things at the same
> time? The MIDI engine, internally and as accessed through the API,
> processes events one at a time.
>
> // David
>
>
>
>
> ------------------------------
>
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>
> End of fluid-dev Digest, Vol 119, Issue 4
> *****************************************
> .
>
>
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>
>
> --
> Sincerely,
> Aere
>
>
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>