I have been working on an audio processing/synthesis application that
should have the power of Reason and Buzz plus the ability to be used
effectivly in live proformance. Some of you may have read my earlier
emails on this subject. I call it Voltage.
The main features that I want but are not availiable in other software
are:
- Linux and Open-Source
- the ability to route and process sequence data (MIDI like data). This
would allow very powerful chordization and arpegiation.
- the ability to create sequence loops in a flexible way (like Reason
Matrix except without the limitations). I'd also like to be able to
record/modify them live without stoping the playback.
- the ability to control things in complex ways using scripting of some
sort (maybe as a machine that is scripted to create certain sequence
events)
What I am looking for is someone to help me (an inexperienced software
designer) design this program. That person don't nesseserily need to
help code the program. I've desided I need help after multiple failed
attempts. I think my current ideas are closer to a working design than
past ones, but I don't want to code it then find out doesn't work (like
I did last time round).
If you are willing to help or have any tips or books I should read, etc.
please email me.
Thanks much.
-Arthur
--
Arthur Peters <amp(a)singingwizard.org>
Hi!
On Tue, Feb 25, 2003 at 07:48:11PM +0200, Kai Vehmanen wrote:
> Date: Tue, 25 Feb 2003 12:20:22 -0500
> From: Paul Davis <paul(a)linuxaudiosystems.com>
> Reply-To: linux-audio-dev(a)music.columbia.edu
> To: linux-audio-dev(a)music.columbia.edu
> Subject: Re: [linux-audio-dev] Fwd: CSL Motivation
>
> >There are discussions on kde-multimedia about
> >the future of Linux/Unix multimedia (especially sound).
> >This is one of the most interesting messages.
>
> CSL is proposed primarily as a wrapper layer around existing APIs. as
> such, it seems to me to have no particular merits over PortAudio,
> which has the distinct advantages of (1) existing
CSL also "exists".
> (2) working on many platforms already and
You're right about that one: CSL is not as complete as PortAudio w.r.t to
portability.
> (3) using well-developed abstractions.
I do not believe that something is ever a "well-developed abstraction" by
itself. Something is always a "well-developed abstraction" from something,
designed to achieve a certain purpose. From the PortAudio homepage:
| PortAudio is intended to promote the exchange of audio synthesis software
| between developers on different platforms, and was recently selected as the
| audio component of a larger PortMusic project that includes MIDI and sound
| file support.
This clearly states the purpose: if you want to write audio synthesis software,
then you should use PortAudio. Then, I assume, the abstraction is well-
developed. However, it does not state:
"... is intended to play sound samples with sound servers easily. Or: ... is
intended to port existing applications easily. Or: ... is intended to let
the application choose its programming model freely."
No. PortAudio makes a lot of choices for the software developer, and thus
provides an easy abstraction. This will mean, however, that actually porting
software to PortAudio will probably be hard (compared to CSL), whereas
writing new software for PortAudio might be convenient, _if_ the software
falls in the scope of what the abstraction was made for.
> CSL was
> written as if PortAudio doesn't exist. I don't know if this a NIH
> attitude, or something else, but I see little reason not use consider
> PortAudio as *the* CSL, and by corollary, little reason to develop Yet
> Another Wrapper API.
Well, I gave you some. The paper gives some more. Basically, CSL is intended
for porting _most_ free software, whereas PortAudio is intended for portable
synthesis software.
I think PortAudio would benefit in _supporting_ CSL, rather than aRts for
instance, because CSL is more generic ; once new sound servers (like MAS)
come up, you need not patch PortAudio all the time, but just one place: a
CSL driver. The same is valid for other meta-frameworks like SDL.
> the only reason i was happy writing JACK was
> precisely because its not another wrapper API - it specifically
> removes 90% of the API present in ALSA, OSS and other similar HAL-type
> APIs.
I am glad you did write JACK, although back then I thought it was just another
try to redo aRts (and we had some heated discussions back then), because some
people seem to like it. If some people will like CSL, why not?
If you added CSL support to JACK right now, you would never need to bother
with any of the "sound server guys" like me again, because you could always
say: "support CSL in your sound server thing, and then JACK will support your
sound server".
On the other hand, if you added JACK support to CSL, you could also mix the
output of all of these "sound servers" into JACK, without endangering your
latency properties.
Cu... Stefan
--
-* Stefan Westerfeld, stefan(a)space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
