|
From: rosea.grammostola <ros...@gm...> - 2012-03-13 09:19:29
|
On 03/12/2012 05:53 PM, Christian Schoenebeck wrote:
> On Monday 12 March 2012 18:14:10 rosea.grammostola wrote:
>> Thanks for your reply. There certainly are no stupid questions... I
>> thought, just ask, but it's actually possible!?!
>
> Yes, it is definitely possible to spawn multiple instances of the sampler. But
> right now I cannot imagine a scenario in practice where this would make sense.
>
> For example if you want to leverage a SMP/multi core system, or a system with
> multiple independent hard discs, you could simply create (in the same sampler
> instance) multiple JACK audio output devices (assuming JACK2 or JACKMP), like:
>
> CREATE AUDIO_OUTPUT_DEVICE JACK
> CREATE AUDIO_OUTPUT_DEVICE JACK
> ...
>
> (or do that with some clicks in Fantasia or QSampler). For each audio output
> device in the sampler, a separate audio rendering thread and disk streaming
> thread is spawned. And by connecting a part to one of those audio output
> devices you can control which audio rendering thread& disk streaming thread
> the part shall be part of.
>
>> A typical situation is that you have made a template for let say
>> bigband. One or two types of instruments are not in a typically bigband,
>> but then you have a midi file / composition with that instruments, or
>> just want to try how it sounds. Then it's nice if you have the
>> possibility to try it without rewriting the template first.
>
> Sure, but maybe a "MIDI instrument map" is a better way for you to achieve
> such a flexible configuration. This feature allows you to define a MIDI program
> change map with instruments, thus to turn the sampler in some standard General
> MIDI sound generator. For each entry you define at least a MIDI bank select and
> program change number and a sound file (.gig, .sfz, .sf2 ) to be loaded. For
> each entry you can also define a volume factor (for fine tuning your
> performance) and a load strategy. The latter defines whether the sound shall be
> loaded:
> a) immediately and always kept in memory ("PERSISTENT"), or
> b) instead be loaded on demand and freed automatically when its not in use
> anymore on any sampler part ("ON_DEMAND") or
> c) be loaded on demand, but kept in memory afterwards even if not used anymore
> by any sampler part ("ON_DEMAND_HOLD")
>
> http://www.linuxsampler.org/api/draft-linuxsampler-
> protocol.html#MIDI%20Instrument%20Mapping
>
> On most master keyboards you can define "performances" which will send the
> appropriate MIDI program change messages to the sampler. So you would just
> need to select the respective performance on your master keyboard and you are
> ready to play.
>
> You can also manage MIDI instrument maps with the two GUI frontend
> applications.
Ok, so if you have one big template with all your samples, it doesn't
hurt the performance of you system. Having them in the template, doesn't
mean they are loaded in memory (ON_DEMAND_HOLD). So a bigger template
doesn't necessarily eat more system resources.
\r
|