Subject: [linux-audio-dev] EVO disksampler actual technical status (and legal ?)
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Jan 19 2002 - 03:02:01 EET
Hi guys,
sorry for my long absence from LAD but I had to finish my last exams at the
university and this took me quite some CPU time. :-)
I'm currently working on my thesis at the university and I hope of being able
to dedicate some time to LAD stuff again in the upcoming months.
Anyway I've read through this month's LAD archives and noticed the postings
regarding EVO:
I did not much lately but at LinuxTag we got some rudimentary form of alsa-seq
support working.
After returning to Milan (in July), I were able to get the latest alsa + muse +
evo working on an LL kernel.
even if the current evo codebase is more a proof of concept rather than an
"application", it showed that the performance of disksampling is more
acceptable. (test box was a Celeron 366 with 256MB RAM)
The test consisted in runnning muse, loading a piano sound (80MB i believe)
into evo, loading a classical piano piece, replicating it on dozen of tracks,
driving up the tempo to 180bpm and then start the playback.
Even if there was not big disk activity going on, the system was able to
withstand the load quite nicely.
I measured mean values of 50 active voices with short peaks in the 60-70 range.
Not bad at all considering that muse needs its piece of the CPU too and that
the # of midi events/sec was quite high.
The timing seemed ok (muse and evo run with SCHED_FIFO).
The current code base (residing on the testpc) is quite a mess plus there are
some bugs in it so I'm not sure it it pays off to work on it or if it would be
more wise rewrite the app from ground after doing some planning on paper before.
The big problem of an _usable_ software sampler is that besides the pure
sample playback engine you need:
- decent routines for loading/mapping various sampleformats like
akai,gig,soundfont and others in order to have lots of audio material at the
sampler's disposal
- a way to remote control the samples in order to manipulate its parameters (eg
modulation stuff) and manage the soundpool (load/unload sounds, modify patches
ecc). For example the remote control stuff could implemented as an IPC driven
API where you can attach a GUI or other controlling sources.
- modulation capabilities / signal-path/routing capabilites
As you see the amount of work to implement all the stuff mentioned above is
quite big and the structure of the project is not as simple as one might think.
Basically the current evo code was written off of my head with very little
planning (just a few sketches on paper).
I think in order to make evo succeed, we need to use a more rigorous software
engineering approach and first defining the structure of the project, objects,
APIs , goals (shortterm/longterm), capabilities ecc
The complexity of a full-featured evo makes it impossible to use the
"off of my head" development model.
Plus in order to implement the various helper libraries (fileformat importing ,
GUIs ecc) we do need the help of several LADers here.
There is no doubt that the aggregate IQ on this list can easily solve all
problems of technical nature.
That's why I'd like you folks to discuss about evo's
design/structure/capability set before returning to write code at random
which after a while turns out to be buggy and unmanageable because of the
lack of structure and appropriate planning.
For example, last year Ruben and I had some private discussions about
evo's signal path and or modulation possibilites.
We discussed about the unflexibility of "hardwired" signalpaths/modulation
stuff and we toyed around with the idea of implementing arbitrary
signalpath/modulation routing.
For example, since efficiency is one of the most important things for an usable
sampler, using a model where the signal path/modulationrouting is determined at
runtime (I believe NI reaktor does so), would be way too slow in order to be
efficient, especially in presence of low latencies.
Since our code is opensource, we could construct the signalpath/modulation
stuff using an editor with in turn generates C code that gets compiled and
loaded as a .so object, achieving the same speed as hardwired structures but at
the same time maintaining full flexibility.
(compilation of a small .so file takes very little so this option would not
penalize the instrument editing process very much (recompilation occurs only
when the structures are modified)).
For example with stuff like this you can beat the "competitors" in terms of
flexibility/performance ratio.
Regarding the legal stuff:
Commonsense says me that Nemesys would be much more likely to go after halion
which has a large userbase and a big corporation (steinberg) behind it rather
than going after a buch of linux audio hackers that make a sampler with a very
little userbase.
Of course in EU SW patents are invalid, so as an EU citizen you should be safe
against these sharks. (*)
(*) As long as you don't give presentations about streaming algorithms in the
US :-)
So my suggestion for the paranoid ones is: US people could still contribute to
the project as long as they don't work work on the streaming routines.
Therefore:
- EU people: streaming routines
- US people: remaining stuff
(yes the above stuff sounds a bit ridicule but in these times it's better to be
in PARANOID_MODE=ON :-) )
I think we should put the patent stuff in the background for now
(especially EU people and US people willing to work on the non-streaming stuff)
and focus or talks about a common strategy/plan in order to make
the long awaited and much needed disk-based sampler succeed.
PS: if you want to write me privately please remove the leading "s" from my
email addr since I'm not reading this mbox. (I'm reading LAD using the web
archives)
cheers,
Benno
This archive was generated by hypermail 2b28 : Sat Jan 19 2002 - 03:22:23 EET