RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Benno S. <be...@ga...>]

Well, the fact that the engine is decoupled from the GUI means that
both solutions, a standalone sampler machine and the "full virtual studio in one
machine" are doable.
Regarding the stress that disk based sampling puts on the machine.
Yes it is a quite stressful application, but I don't think PCI is the
main bottleneck here.
Yes its peak performance is only 133MB/sec but as we know harddisks
usually transfer only 10-25MB/sec in the real world.
This means that you can have two separate disks one for HD recording and the
other for the sampler running in parallel without interfering too much eachother.
The problem of GS is that it is a low-level hack (requires special sound card
drivers, the sampler engine basically runs at kernel level (if it crashes =sh*t
happens :-) ) thus not very multitasking-friendly.
(especially when you want to run it in parallel with other CPU/disk hungry
software like Cubase/Logic etc).
This is why users love Halion: it is a VST plugin that can under Cubase,
 you get sample accurate processing and perfect integration, something that
the MIDI driven (even via local midi loopback) GS cannot achieve.
I have not seen GS and Halion in action side by side but from reading the
forums, when it comes to raw performance and low latency GS beats Halion because
of all these low-level hacks.
These issues coupled with the fact that Windows is not that stable when you
overload it, are (IMHO) the main reason why windows users tend to run GS
in a dedicated box treating it just like a hw device.
On the other hand  Linux's multitasking works exceptionally well and well
 designed realtime audio software can fully utilize the machine's resources
 without compromising stability.
This is why, given enough horsepower, I support the idea of the whole virtual
 studio in one single Linux box.
MIDI sequencing and a sampler/synth engine on the same box is not a problem
 since sequencing only takes a fraction of the available resources.
If you add HD recording to the equation, then the workload increases
significantly but nothing speaks against of runnning both the HDR and the
sampler software in the same box.
A single disk system is probably not up to the task because the sampler needs
to access to the data on disk and cannot easily coexist with the HDR tracks
 that fight for the same (scarce) disk bandwidth/latency.
With two disks, the focus shifts to the CPU (mixing and doing FXes on HDR tracks
 can chew up quite some CPU), but fortunately fast CPUs (2GHz+) can do both at
 the same time.
My PII400 is able to stream about 60 tracks (voices) from a 16GB IDE disk (IBM)
when using the old sampler test code. (evo), this means that with 5x the MHz
and two disks it is easily possible to do both HDR and disk based sampling on
the same box.
Regarding battery vs fully-fledged sampler: I agree, better to start out with
 something simple and elaborate later, but if we get this 
"sampler-construction-kit" done, then evolving from the simple to the
"extended" version of the sampler will take only a small amount of time since
you will basically design it using your mouse and not your editor and C compiler.
:-)
For example Juan says he prefers to first write hardcoded engines and then 
 start thinking about recompilation techniques but I see it as a bit of a waste
 of time. I prefer to take a longer
 design phase and write an engine that can later scale really high without
 the limitations of hardcoded engines.

cheers,
Benno

http://linuxsampler.sf.net
 

Scrive Mark Knecht <mk...@co...>:

> 
> In the GigaStudio world the sample libraries are huge, mostly running
> between 1-2GB per library. I use 10-15 of them at a time, so there is no way
> to put this in DRAM. This puts a pretty high stress on the underlying disk
> subsystem, which is fine as long as GSt is on it's own computer where the
> PCI bus and audio subsystem are available to do the work. So, in replacing
> something like GSt or Halion, my guess is that LinuxSampler wants to look
> mostly like a stand along application. That said, it would be very cool to
> be able to send it control commands via the MIDI stream, or over Ethernet,
> from my main DAW. GSt doesn't support much of that today. (If at all...I
> don't use it.)
> 
> If we were looking at a trimmed down version of the technology which
> operated more like Battery, then I think that using the underlying sampler
> technology as both a plugin or a stand alone app running on the same DAW, if
> most of the samples fit in memory. (Easy for drums, not so easy for piano)
> 
> I personally think a Battery like app would be a great starting point for
> this sort of technology, to be followed up by a full-blown sampler app
> later.
> 
> Cheers,
> Mark
> 
> 




-------------------------------------------------
This mail sent through http://www.gardena.net