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

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Reply via email to