Problems with JSampler and SSO

[The Aviv]

Hello fellow Linux musicians,

I tried to test the Sonatina Symphonic Orchestra with JSampler - but it fails to load the solo instruments. I read the thread SSO and QSampler [SOLVED] and downloaded the OpenOctave MIDI version of SSO (from the OOM library). I found no differences between the two versions, and experienced the same problem.

I will try to use the combo of QSampler and Rosegarden in place of JSampler - but I can barely find any documentation for QSampler. I am also wondering why JSampler displays incorrect ranges for the SSO instruments?

I am running Linux Mint 13, with KXStudio PPAs. I installed OOM (from KXStudio), and can only get it running from the terminal as root (otherwise, the window just pops up and closes). I am under the impression that this tool is not yet reliable. (As a matter of fact, I am under the impression that most of the Linux tools are not reliable.)

I am a beginner composer. In order to develop my production skills, I have given myself the task of rendering an acceptable sound file from a MuseScore transcription of Beethoven's 5th - 1st Movement. However, I question whether that would be possible under Linux? (I must admit, as much as I admire the open source community, I've been tempted lately to just buy a Mac mini, along with Sibelius or Finale. Would that be the better move, or am I just leaning towards the easy path?)

[Although I have not done much research on this, my understanding is that sound synthesis (whether by spectral or physical modelling) is not yet well-developed enough to realistically render orchestral pieces (which, currently, can only be done via sampling). Correct me if I am wrong.]

Any input would be appreciated.

[TheSafePlaces]

Hi.

Hello fellow Linux musicians,

I tried to test the Sonatina Symphonic Orchestra with JSampler - but it fails to load the solo instruments. I read the thread SSO and QSampler [SOLVED] and downloaded the OpenOctave MIDI version of SSO (from the OOM library). I found no differences between the two versions, and experienced the same problem.

Kindly read about the difference, on that selfsame page, further down. If you are _aware_ of this and still cannot see the difference in the SFZ files of the OOM version...ouch, then someone has mucked with the file on the OOM page. You'll have to do it yourself, which isn't hard. I could give you the SSO SFZ files too - they work here, as I wrote in that thread, and are probably a measly 1 MB or so of download.

'not loading' could also be caused by other things. Put up the error message you get in the messages window, let's see the issue.

About qsampler - I don't think there are any docs for it, but it's a pretty straightforward program. Feel free to ask any questions about it. There were tutorials on http://wootangent.net/ which helped me get started - although made for jsampler, they can be used for qsampler too.

I am a beginner composer. In order to develop my production skills, I have given myself the task of rendering an acceptable sound file from a MuseScore transcription of Beethoven's 5th - 1st Movement. However, I question whether that would be possible under Linux? (I must admit, as much as I admire the open source community, I've been tempted lately to just buy a Mac mini, along with Sibelius or Finale. Would that be the better move, or am I just leaning towards the easy path?)

We had a little discussion on that recently (the sampling aspect, which I think you would be concerned with...and if you're not, you should be ).
http://www.linuxmusicians.com/viewtopic ... 21&t=11203
In that thread, the solution that I said I use works for me (I'm currently on my first film score job and it isn't letting me down) but it has it's drawbacks, as I wrote there. Draw your own conclusions because YMMV

[Although I have not done much research on this, my understanding is that sound synthesis (whether by spectral or physical modelling) is not yet well-developed enough to realistically render orchestral pieces (which, currently, can only be done via sampling). Correct me if I am wrong.]

Yeah, that is generally agreed upon. However, some - like I, and Nils Gey, here, among others (one hopes!), keep a vague eye on the physical modeling realm, though, in case of Physical Modeling Revolution (TM)

Software on Linux is...I'd say better in some aspects compared to their proprietary counterparts, and worse in some others. IMHO -
Ardour is pretty reliable for pro-work,
non-timeline is decent, and non-mixer is good and seems set to receive some big gun upgrades (the non-* tools are meant to be used modularly, by the way)
Qtractor is reliable too, although made for basic work.
The rest - I can't stand the GUIs on Muse2, Rosegarden, and non-sequencer, but AFAIK unless there some setup issue on your system everything should work, the odd one or two kinks aside (which you are always welcome to report to the devs and therefore help improve things.).

Since scorewriting and production are your drag as is mine - my central tool in my current film score job is Laborejo, a score-centric sequencer - which is far from polished, but offers features nothing else does (and IMHO it is a far better scorewriter than Musescore/Finale/Sibellius ever will be, and the best MIDI sequencer for composing 'acoustic'/'traditional' music on Linux), and has a very hardworking and receptive-to-user-input-within-reason dev. It's reliable too...for a 0.7 program - i.e. it's reliable most of the times. xD

Hope I helped.

[The Aviv]

Thank you falkTX and TheSafePlaces.

Kindly read about the difference, on that selfsame page, further down. If you are _aware_ of this and still cannot see the difference in the SFZ files of the OOM version...ouch, then someone has mucked with the file on the OOM page. You'll have to do it yourself, which isn't hard. I could give you the SSO SFZ files too - they work here, as I wrote in that thread, and are probably a measly 1 MB or so of download.

Sorry, I did not compare the contents of the SFZ files. Foolish of me. In JSampler, I must have opened the original ones again, thinking I was checking the new SFZs from OOM. I was being brash (out of frustration). (I'm not usually like that.)

I am also wondering why JSampler displays incorrect ranges for the SSO instruments?

This seems to be a bug. JSampler's keyboard always shows the range an octave lower. I posted about this at the LinuxSampler forum.

Well, I'm not sure about the rest, but I do know OOM is dead now.
(I was part of the team, then left)

Why don't we maintain a Linux version of SSO at the KXStudio Music PPA? We shouldn't have to refer new Linux musicians to download a corrected version of SSO from the library of a defunct project. We need to provide a central repository that serves as the main go-to source for "CC|GPL samples, sounds, kits, etc, useful to music production". Isn't that what KXStudio is all about, a central up-to-date repository for Linux artists to select their tools from? If this is solely an issue of manpower, I volunteer to maintain SSO and other noteworthy CC/GPL orchestral sample libraries.

There is another issue with SSO: The SFZ file for the solo flute erroneously maps each sample an octave lower, and the filenames of the sounds reflect the mistake. The samples actually range from C4 to C7 (the correct range of the flute), but they are given as C3 to C6.

Since scorewriting and production are your drag as is mine - my central tool in my current film score job is Laborejo, a score-centric sequencer - which is far from polished, but offers features nothing else does (and IMHO it is a far better scorewriter than Musescore/Finale/Sibellius ever will be, and the best MIDI sequencer for composing 'acoustic'/'traditional' music on Linux), and has a very hardworking and receptive-to-user-input-within-reason dev. It's reliable too...for a 0.7 program - i.e. it's reliable most of the times. xD

Hope I helped.

Thank you again TheSafePlaces. I found your answers very helpful.

[TheSafePlaces]

I am also wondering why JSampler displays incorrect ranges for the SSO instruments?

This seems to be a bug. JSampler's keyboard always shows the range an octave lower. I posted about this at the LinuxSampler forum.

Just in case - do check what key has been mentioned in the SFZ file. It is possible that the guy making the instrument files screwed up. Or the guy labeling on the samples :3 Although I don't think this would be the case, considering what you write about the flute SFZ...

We need to provide a central repository that serves as the main go-to source for "CC|GPL samples, sounds, kits, etc, useful to music production".

1. Good idea.
2. Apparently someone thought the same, so - http://download.linuxaudio.org/musical- ... libraries/
But no SSO there. Odd. Ought to be added.

If this is solely an issue of manpower, I volunteer to maintain SSO and other noteworthy CC/GPL orchestral sample libraries.

That's the spirit Not sure whom one talks for this, though. Perhaps you can host your own mirror for them, and fix things on both download.linuxaudio.org as well as on your mirror?

There is another issue with SSO: The SFZ file for the solo flute erroneously maps each sample an octave lower, and the filenames of the sounds reflect the mistake. The samples actually range from C4 to C7 (the correct range of the flute), but they are given as C3 to C6.

Hm, just checked, this is true...again, not sure who the maintainer(s) currently are.

[The Aviv]

Just in case - do check what key has been mentioned in the SFZ file. It is possible that the guy making the instrument files screwed up. Or the guy labeling on the samples :3 Although I don't think this would be the case, considering what you write about the flute SFZ...

From what I can tell, this is not a problem with any SFZ file, but a bug in JSampler Fantasia.

1. Good idea.
2. Apparently someone thought the same, so - http://download.linuxaudio.org/musical- ... libraries/
But no SSO there. Odd. Ought to be added.

Yes, one problem with using Launchpad as a host for such a repository is the imposed size limit. The KXStudio Music PPA is only permitted 2 GiB worth of data (see package details). It will not do.

I will contact the Linux Audio dev team and work with them.

[TheSafePlaces]

I will contact the Linux Audio dev team and work with them.

Try catching the user 'rgareus' on IRC channels #ardour or maybe #lad, on irc.freenode.net. As far as I am led to understand, he's the maintainer of linuxaudio.org. Even if he isn't in charge of the download section, he'd know who is.

[nils]

I am

[The Aviv]

Hi Nils Gey,

I've read your posts at Music made with Laborejo (and Sonatina Symphonic Orchestra), and I've been reading from your blog (very informative, what would we do without you?).

I now understand that SSO is not suitable for the Linux community to adopt as a continuing project. But as tnovelli suggested, can't we just start from scratch, and work on building a solid open library for all of us to use and constantly develop?

Many others appear to be interested in filling in the gap:

MuseScore forum: Filehosting for the Soundfont Project
Linuxsampler-devel mailing list: SFZ Library
LinuxMusicians: crazy idea: Open-Source HD Orchestra Library
SourceForge project: OpenOrchestra
SourceForge project: OpenSymphonia

Can't we assemble the manpower and infrastructure to compile a library like Mattias Westlund did? But do it better and keep it as an ever-improving work-in-progress? If one person did it, why can't a whole global team do it? We could start off by collecting what's good and legit, and as the project progresses, people will begin contributing their own samples.

[TheSafePlaces]

The Aviv -
SSO is no good for professional works. Used in combination with Fluid R3 it makes for strictly okay, semi-pro stuff. It shouldn't be abandoned outright (unless of course a better alternative presents itself).

About what you say - I'm not sure if you read this thread I pointed you to - http://www.linuxmusicians.com/viewtopic ... 21&t=11203
As the thread is quite long, I'll sum up what I wish to point at -

I intend to make a sampling cooperative, which functions thus -

Code: Select all

The Co-operative consists of a team of Evaluators - a small group of people who are experienced in sample library creation and usage.

The Co-operative decides on candidate instrument(s) for sampling, based more or less directly on community vote.

Player(s) of said instrument(s) are invited for review and are chosen by the Co-operative team.

The Co-operative gives them the Sampling Guidelines -
	The Guidelines consist of
		+how-to docs for musicians who are new to the sampling process,
		+best practices in sampling, a codification of general experience of Co-operative Musicians and Evaluators,
		+and most importantly, the non-optional section - fine technical details of the methods and standards required by the Co-operative in their samples. These will be tailored to guarantee uniformity and 			consistency of the samples and of their quality, across sample sets, no matter where in the world they are recorded and by whom.
	The non-optional section of the Guidelines must be adhered to by musicians for their samples to be accepted by the Co-operative.

Each player decides on a local studio of his/her choice. He/she record a few demo samples and send them to the co-op. If the co-op finds the studio equipment and overall demo-sample quality in accordance with the level required in the Guidelines, they give the player the go-ahead for the studio.

Once the go-ahead on the studio is given, the player begins sampling in accordance with the Guidelines. Players stay in regular touch with the Co-operative, and may choose to regularly send them the samples recorded so far for continuous quality-checking.

Once the sampling process is over, the player sends the entirety of the samples to the Co-operative for review. A final QC, in which it is decided whether or not the samples match the Co-operatives standards as listed in the Guidelines, takes place.

If the samples pass the evaluation, they are made into libraries and the release process begins.

All libraries by the Co-operative are released under CC-BY-SA. Essential articulations are released under a release-date-bounty system -
	1. A sample library is completed - and beta-tested if required - to perfection by the Co-operative Evaluators.
	2. One or many demo videos demonstrating the sample library are launched, and 
	3. A release date is announced - for example, a year from the date of announcement.
		The library will now automatically release under CC BY SA on that date, BUT -
	[the monetary amounts mentioned hereon are as of now strictly theoretical, purely for sake of example]
	4. Every time someone donates 50 USD, the release date goes back by an entire month.
		(donation amounts lower than that add up - if someone gives, say, 49 USD - then the next time someone gives even 1 USD the release date will be affected)
	5. In this example, in case of a successful library launch, the Co-operative makes 600 USD - possibly enough to 
		reimburse the musician
			of studio costs, as well as
			a little amount for her/his time, as well as
		a little profit for the Co-operative as well, to be used for (depending on amount)
			reimbursing the Evaluators for their time and expertise,
			and for investment for the Co-operative's expansion
				For instance, to hire an orchestra and have it sampled at a good studio; the profits alone may not be enough,
				but if saved up over many years, and by joining forces with crowdfunding, it is a distinct possibility, and an important one for the Co-operative.

Extra articulations are released on donate-for-features basis -
	1. We discuss required articulations and other features with the community on a public forum, a list of all feature requests is made.
	2. A public poll with a time-frame is undertaken where all the feature requests are candidates.
	3. Once the time frame is over and a winner is arrived at, a time-bound donation campaign is launched.
	4. If the goal of the campaign is achieved, work on the feature begins. If it fails, all the money collected is returned to the donors and we possibly begin from step 1 anew.

Other Policies of the Co-operative.
	1. Keep all functioning information in the public domain.
	2. Provide all financial information publicly. Donors must know exactly how and where we spend their money.
	3. The Co-operative must profit. Enough profit is the difference between members doing day jobs to support themselves or giving their full attention to the Co-operative. It is the difference between the Co-operative expanding to more ambitious sampling projects like orchestra sections and choirs, or remaining mired in small time things.

At the moment I'm trying to make a as-near-as-professional-quality-as-I-can-get sample library myself (solo classical guitar). If after that I feel that this idea can be pulled off and pulled off well enough to prove detractors wrong, I will try to acquire evaluators and musicians and do a (solo strings) library as a proof-of-concept. If that succeeds, the cooperative can finally take off big time. Comments, suggestions, advice, questions, and opinions welcome.

Thank you for pointing those other projects out, though. I was not aware of all of them...sad that they (seem to have) passed away without a trace. Learn from their failings, we must.

[The Aviv]

SSO is no good for professional works. Used in combination with Fluid R3 it makes for strictly okay, semi-pro stuff. It shouldn't be abandoned outright (unless of course a better alternative presents itself).

My point is that SSO has already been abandoned. I want to commit some fixes, but I can't - because there is nowhere I can do that. Mattias Westlund is not interested in updating SSO (and he is well-aware of its fallacies). See his blog entry SSO — Past, present and future.

Fluid R3 - that has been abandoned as well. I don't even know what license it's under, how it was made, its sources - its sources, the sound files, where are they? What's the history of Fluid R3? Who made it? Where is the project website?

Right now, a new Linux musician could be downloading SSO from Mattias Westlund's website, as I did. And like me, he will discover that some instruments don't work, because of a silly capitalization error. Furthermore, like me, he will discover that the solo flute samples have been wrongly labeled. Like me, he will wonder where he can commit the necessary fixes. He might even discover better open source replacements for some the instruments. If only he could work with other like-minded musicians to collectively improve a single common library.

I don't understand why we don't have that?

[nils]

https://github.com/nilsgey/sfz

If you have fixed the flute and checked for other transposed instruments I would be happy to accept pull requests. I wanted to fix that for ages.