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

[David O. <da...@ol...>]

On Monday 20 January 2003 19.54, Benno Senoner wrote:
> 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.

Exactly - and using an API that handles both audio and sample=20
accurate control would make it easier to get right and more robust, I=20
think.


> 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.

Yes - but if you have a phatt array of drives, PCI won't cut it. I=20
guess that's why mid and high end servers, and even workstations come=20
with 64 bit PCI and stuff.


> 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.

BTW, there's a problem if you need HDR and direct-from-disk sampling=20
at the same time. (Which I would all the time, if I used a disk=20
sampler, since I never record synth stuff to disk before vocals. I=20
like to have full control until the final mixdown.)

Obviously, you can just use three disks; one for the system, one for=20
the sampler and one for the HDR. However, if you use more than one=20
disk sampler at a time, this starts getting out of hand...

This is why I suggested a standard disk butler API on LAD - but I=20
think we need to do a lot more thinking and coding before turning=20
that into a standard. Maybe something useful will eventually take=20
form in the internals of LinuxSampler, so we can design a XAP=20
extension around that, rather than guessing.


> The problem of GS is that it is a
[...]

So, in short, GS is a Windows specific performance hack, while Halion=20
is a plugin sampler Done Right - only on the wrong OS.


> 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.

Yes - although I think Paul has pointed out that there are still=20
issues with the scheduler when pushing it as hard as JACK does. IIRC,=20
it sometimes doesn't schedule the right process. Seems obvious that=20
this should be fixed in 2.5, but until then...


> This is why, given enough horsepower, I support the idea of the
> whole virtual studio in one single Linux box.

=2E..and with 2 or more P-4 or better CPUs, preferably utilizing SIMD,=20
we're looking at some *serious* DSP power...


> 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.

Except that they need separate disks, unless they share the disk=20
butler, I think... Just adding another disk would probably be=20
acceptable to most serious users, though.


[...]
> 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.

Well, as long as you actually get through the design phase without=20
killing the project, spending more time on the design sounds like a=20
good idea. Saves time in the long run, provided you think straight=20
and know what you're doing.


That said, I did it the other way around with Audiality. (Which is=20
effectively a working test bed for my XAP ideas, BTW.) It's also the=20
first major spare time project of mine that's really off the ground.=20
It's been more or less fully functional right from the start=20
(although it didn't do much :-), almost 2 MB of code ago. I've just=20
added features as I needed them (ehrm, or just thought they would be=20
fun to play with), and restructured when things started getting too=20
messy.

Note that this restructuring part is *very* important, but usually=20
really rather boring. I believe the only reason why Audiality isn't a=20
total heap of spaghetti is that I have trouble remembering complex=20
APIs and logic. If it's to messy, I just can't work with it and must=20
fix it.

Obviously, there's a great deal of rewriting and moving stuff around=20
in this process, but that's not all bad. I've actually *tried* the=20
solutions that I ruled out, and when I get a new "great idea", I can=20
just test it and see if it actually works. When it comes to design,=20
testing ideas in a real app is a lot more useful than testing in a=20
fake environment. Often, you realize where you went wrong as soon as=20
you start typing the test code.


What I'm saying is that the "hack away" approach may not be the most=20
effective way of creating software, but it sure beats never getting=20
off the ground. I think this all boils down to "It's more fun to hack=20
something that sort of works." If it doesn't compile, run and do=20
something "interesting" every 10-20 hours of hacking or so, you're in=20
trouble...


Can't tell you what to do, but given my experience, I would say Juan=20
has a point. Though, it seems to me that rudimentary C code=20
generation shouldn't have to be *that* complicated. You could=20
probably fake most of it, and basically just have the engine output,=20
compile and load a hand coded voice struct, until you have the real=20
stuff in place.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---