Subject: Re: [linux-audio-dev] EVO spec 0.0.1, linuxsampler 0.0.5 released ...
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Jul 19 2000 - 22:34:59 EEST
>If sourceforge eases mantainance work over having the services hosted on our
>own servers then I'd go the sourceforge way.
>Anyone who has experience with it ?
I use sourceforge for all 3 of my currently active projects. Its very
easy to use, and I recommend it without hesitation. You get CVS, FTP,
HTTP and mailing-list services for free.
>Regarding the GUI issues, as said in my previous mails the best thing to do is
>to separate the GUI and the engine, and define a communication protocol/API.
Given that you are already coding in C++ (hurrah!), may I suggest
using libsigc++ for this ? Its very slightly premature, but there has
already been some nice work done with libsigc++ to make it possible to
deliver the "signals" (these have nothing to do with POSIX signals;
think "event+callback" here) between threads, across TCP/IP and via
CORBA. The API for delivering the signal to the other end is identical
in every case. libsigc++ is the best thing since, well, C.
you can then forget about defining a *communication* protocol, and
concentrate purely on what data has to go back and forth. the only
limitation of this system (and i think that it would be a correct
limitation) is that the object sending the "signal" must send over the
data required by the receiver(s), since you don't really want to set
up any 2-way communication in this system. libsigc++ makes this easy.
note: libsigc++ is all about defining *anonymous* communication. one
object emits signals without having any clue who the receivers are, or
if there are any. its damn fast, damn elegant, and damn fine. i'd be
lost without it, its a vital component of how i think about
programming these days.
>Last question about AUDIO MORPHING:
>
>- are the algorithms/math publicy available ?
> (if yes, URLs with docs would be handy)
you should consider doing this in the frequency domain.
Checkout http://www.scrime.u-bordeaux.fr, and take a look at
Prospect/Inspect/Respect. I heard a fantastic demo of this at the LSM,
morphing between a voice and a saxophone (not *that* hard, but it
still sounded bad when done in the time domain).
Sylvain made some fairly good claims that this can't be done well in
the time domain.
>- will the realtime implementation be fast enough to still
> allow 20-30 voices on PII CPUs ?
No idea. You have to feed them through an FFT first, though.
--p
This archive was generated by hypermail 2b28 : Wed Jul 19 2000 - 23:12:18 EEST