Subject: Re: [linux-audio-dev] What I want, to stop using Windows
From: Ellis Breen (miminon_AT_hotmail.com)
Date: Wed Sep 27 2000 - 22:23:18 EEST
> On Wed, Sep 27, 2000 at 08:44:56AM -0400, Paul Barton-Davis wrote:
> > >1. Multichannel soundcard - I have a Korg 1212, but this only works in
9x,
> > > mLAN would do for this but I suspect its a way off yet. It only
needs
Firewire is supported in the 2.4 kernel, but actual Firewire drivers for
Linux are in their infancy. Also, Firewire really needs to be supported on
the motherboard to fully realise its potential (PCI66 is too slow!). But it
has all the advantages PCI and USB2 have - direct access to PC resources
e.g. RAM, bus mastering et al, hotswappability, alongside a faster transfer
rate and.I for one would like to see a Firewire version of Creamw_AT_re's
Pulsar (PCI overflow problems are prevalent here as only SCOPE uses onboard
memory).
> 7. A USB MIDI box (run out of slots) that is fast enough to talk to a Mod
> without karking.
USB does indeed work nicely under Linux, I'm using a M$ Intellieye under USB
with full functionality.
>
> > >5. Some primative MIDI sequencing stuff (as part of 4 would be fine)
> >
> > Jazz++, or if you want to get experimental, KeyKit.
>
> I tried Jazz++ on linux and windows, but didn't get on with it, too much
> like Cubase, which I can't stand. Seemed very buggy too.
Anybody know the status of Brahms - seems to have gone quiet? Last I heard
about it was from the ARTS project mentioning it integrating closely with
ARTS soundserver under KDE2. I also subscribe to GSeq mailing list and it's
not too busy.
I'd like to help produce this stuff. I've been thinking about highly modular
sequencing/synthesis for a while before I discovered LAD and it's turned me
on to the idea of a completely open architecture. After all, when/if Native
Instruments/Creamw_AT_re/Nord/Korg go bust, their APIs will doubtless die with
them... unless they are Open Source... I want to make something as portable
and futureproof as possible.
I just looked at MusE. It looks pretty interesting. Does it have an internal
MIDI subsystem (like MROS)? How about adding a SAOL decoder? As a subset of
CSound it is widely accepted and would add a great deal of functionality to
MusE.
Then MusE would provide the following:
a) Native plugins (including VST2 plugins via a LADSPA wrapper)
b) Platform independent synthesis/effects (SAOL)
c) Complex internal/external midi/audio processing (for instance you could
write an arpeggiator in SAOL).
The only other thing needed to make this a 'killer app'
is something to orchestrate these three complementary elements.
We need some kind of metaformat (lets call it MusEML ;-) ) with the
capability of accurately (but abstractly) describing an audio set up (no
tall order), and some means for parsing it within the sequencer.
The approach I envisage would be to describe different audio algorithms
(whether or not the implementation details are known) using a
SAOL superset (which could in turn reference other MusEML documents)
with some extensions for permitting the use of LADSPA plugins and
instruments/effects the implementation of which are undisclosed (e.g.
hardware synths, VST
plugins etc).
Such documents could be shared over the internet. Furthermore these
documents could be organised into libraries categorizing similar sounds.
If someone wishing to listen to some MusEML did not have access to all the
components
then these libraries could point the parser in the direction of good
replacements
for the absent elements. Hopefully survival-of-the-fittest should lead to a
small number of
large libraries (one for CSound users, one for GM users with cloth ears
maybe ;-) ).
The extra cool thing is if we can describe everything as abstractly as
possible we can optimise the performance of the computer for each given
setup, and could
split up the task of making noises between the available resources.
SFront is cool - does anybody know of a direct-to-machine code SAOL
compiler?
Are potential optimisations lost in the translation to C by SFront/SFX?
Could one spec up a superior intermediate API for SAOL to machine code
compilation for which a generic engine and platform-specific API libraries
(and thus optimisations) could be written?
This archive was generated by hypermail 2b28 : Wed Sep 27 2000 - 22:50:40 EEST