FluidR3Mono_GM.sf3

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FluidR3Mono_GM.sf3

ChurchOrganist
I have just uploaded version 2.111 to my Google Drive which fixes the recently discovered artifact in the Aah Choir samples.

In case you need a link to the folder - here it is.......

https://drive.google.com/open?id=0B7cZM0RQwkwST2tiWWFiaTN0WFE

There is still no response from Mike Schorsch regarding the licence for his Marching Percussion samples, so I am at a complete loss of what to do now regarding incorporating them in FluidR3Mono.

Does anyone have any suggestions?
Regards
Michael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FluidR3Mono_GM.sf3

lasconic
Administrator
Thank you Michael!

As you know, I'm not a big fan of overloading our git repository and so I prefer to skip several versions of your soundfont if possible. (Sometimes, it bit me in the back... but at least the git repo is a bit smaller...). So, what's your roadmap for the soundfont? Do you have anything on your plates in the next month or so?

Regarding drumline, as I said several times, I would love to find a way to make it easier to incorporate them in a future version of MuseScore. Since 1.3, we added the instruments in instruments.xml and it's not very easy to install a soundfont in MuseScore with a single double click. However, it would be a lot simpler if the sounds were incorporated in the default soundfont, or the drumline soundfont (or any other specialize default one) loaded by default when a given instrument is used. Licenses being an issue, I mailed Mike Schorsch again. I hoped we will hear from him.

lasconic

2015-10-16 12:41 GMT+02:00 ChurchOrganist <[hidden email]>:
I have just uploaded version 2.111 to my Google Drive which fixes the
recently discovered artifact in the Aah Choir samples.

In case you need a link to the folder - here it is.......

https://drive.google.com/open?id=0B7cZM0RQwkwST2tiWWFiaTN0WFE

There is still no response from Mike Schorsch regarding the licence for his
Marching Percussion samples, so I am at a complete loss of what to do now
regarding incorporating them in FluidR3Mono.

Does anyone have any suggestions?



-----
Regards
Michael
--
View this message in context: http://dev-list.musescore.org/FluidR3Mono-GM-sf3-tp7579534.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
ABL
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FluidR3Mono_GM.sf3

ABL
What about implementing something similar to what has been done for the translations? I.e. the updated sf3 is stored on a server (separate from the git repository) and continuously updated and the user can download the updated version and it automatically replaces the old version.
By doing something like this, we could reduce the problem of engulfing the git history with huge files, and we could also update the "released" version of the soundfont if we find a problem after the release of a new MuseScore version.

Ciao,
ABL
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FluidR3Mono_GM.sf3

lasconic
Administrator
It's for this reason that the translation updater is called "Resource manager". The plan was to extend it to more resources such as plugins, soundfonts, palette, styles and so on. However, it still means we need to package the soundfont with released versions of MuseScore.

For large files in git, a possible solution is setting up git LFS https://help.github.com/articles/working-with-large-files/

lasconic

2015-10-19 16:37 GMT+02:00 ABL <[hidden email]>:
What about implementing something similar to what has been done for the
translations? I.e. the updated sf3 is stored on a server (separate from the
git repository) and continuously updated and the user can download the
updated version and it automatically replaces the old version.
By doing something like this, we could reduce the problem of engulfing the
git history with huge files, and we could also update the "released" version
of the soundfont if we find a problem after the release of a new MuseScore
version.

Ciao,
ABL



--
View this message in context: http://dev-list.musescore.org/FluidR3Mono-GM-sf3-tp7579534p7579538.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FluidR3Mono_GM.sf3

Luis Garrido-4


On 19/10/15 16:42, Lasconic wrote:
> It's for this reason that the translation updater is called "Resource
> manager". The plan was to extend it to more resources such as plugins,
> soundfonts, palette, styles and so on. However, it still means we need
> to package the soundfont with released versions of MuseScore.
>

Hi!

If I may, yet another option, more suited to a source code repository
way of working, could be having all the WAV files separated, plus some
kind of text description file a la SFZ and then using a build system to
generate the SF2.

Maybe something based on libInstPatch Python bindings?

http://sourceforge.net/p/swami/code/ci/master/tree/libinstpatch/examples/create_sf2.py

Other possible sources of GPL SF2 code that I know of are awesfx and
Polyphone:

http://manpages.ubuntu.com/manpages/precise/man1/sf2text.1.html

http://www.polyphone.fr/

This way of managing a sample library would allow easy substitution of
samples for others of better quality or less dubious licensing and the
ability to output to different formats (GIG, SFZ...)

Cheers,

Luis


------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FluidR3Mono_GM.sf3

ChurchOrganist
In reply to this post by lasconic
Basically - at the moment the FLuidR3Mono soundfont is about providing bugfixes as they appear.

Currently the development is going into the standalone Clarinet soundfont which will ultimately replace the one in FluidR3Mono once it emerges from Beta.

I think it's best to keep them separate for the time being.

I understand about the size of the GIT repository - it is why I started keeping the latest FluidR3Mono version in a publicly accessible folder on my Google Drive, so it is there for whenever you require an update together with changes log and MIT licence.

If, however, we do hear from Micke Schorsch regarding licencing it would not take long to merge the Marching Percussion presets into FLuidR3Mono.

Maybe you should consider adding the latest version when the 2.0.3 version comes out?

Regards
Michael

Regards
Michael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FluidR3Mono_GM.sf3

ChurchOrganist
In reply to this post by Luis Garrido-4
Unfortunately, as I understand it, the SF2 format does not allow for this method of storage, being designed to be packaged up into a standalone soundfont, unlike SFZ which can store the samples separately.

Storage as .WAV could lead to all sorts of problems related to the loss of loop and tuning information which is not currently supported by the standard RIFF wave format, although certain applications such as Sony's SoundForge will store this information as part of the header.

Unfortunately opening and saving with an Open Source alternative such as Audacity results in the loss of this information, even though Polyphone and Viena are geared up to read it should it exist.

Also, for this reason substitution of samples within an SF2 is not straightforward. Loop and tuning information will almost certainly be different, hence the workflow for changing a preset usually starts with the creation of a standalone SF2 which is then imported into the existing soundfont once editing is complete.

Regards
Michael
Regards
Michael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FluidR3Mono_GM.sf3

Luis Garrido-4
On 20/10/15 01:35, ChurchOrganist wrote:
> Unfortunately, as I understand it, the SF2 format does not allow for this
> method of storage, being designed to be packaged up into a standalone
> soundfont, unlike SFZ which can store the samples separately.
>
> Storage as .WAV could lead to all sorts of problems related to the loss of
> loop and tuning information which is not currently supported by the standard
> RIFF wave format, although certain applications such as Sony's SoundForge
> will store this information as part of the header.

Indeed. So the solution I suggested is storing this loop and tuning
information in a separate description file and then designing a system
to automatically generate the SF2 out of this file and the WAVs, as if
you were compiling a binary out of source code files.

This could be done perhaps by simply maintaining the library in SFZ
format and manually using Polyphone's GUI to make the conversion to SF2.
Or maybe a simple command-line SFZ to SF2 converter, perhaps supporting
only the minimal features necessary for this particular library to keep
things simple, could be developed using code from one of the projects I
cited.

Just brainstorming a bit.

Cheers,

Luis

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Loading...