From alsa-devel-owner@alsa.jcu.cz  Wed Jan 20 20:31:08 1999
Received: from post.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id UAA14595
	for <alsa-devel@alsa.jcu.cz>; Wed, 20 Jan 1999 20:29:13 +0100
Received: from [194.222.223.87] (helo=gedamo.demon.co.uk)
	by post.mail.demon.net with esmtp (Exim 2.10 #1)
	id 1033JM-0003Ju-00; Wed, 20 Jan 1999 19:29:08 +0000
Received: from gedamo.demon.co.uk (gdm@localhost [127.0.0.1])
	by gedamo.demon.co.uk (8.8.7/8.8.7) with ESMTP id TAA06776;
	Wed, 20 Jan 1999 19:29:03 GMT
Message-ID: <36A6145A.44CF320B@gedamo.demon.co.uk>
Date: Wed, 20 Jan 1999 17:37:30 +0000
From: George David Morrison <gdm@gedamo.demon.co.uk>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz
CC: Jaroslav Kysela <perex@jcu.cz>
Subject: Re: Suggestions
References: <Pine.LNX.3.96.990119102034.25743O-100000@entry.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:
> 
...
> 
> All these functions should be available in the alsa-lib library, thus most
> of applications will probably call only a 'download program number'
> function and alsa-lib will detect what instrument and how it should be
> downloaded to the onboard synthesizer.
> 
> SYSEX doesn't seems as way for me. It is limited (I think that maximum
> length should be about 256 bytes) and we must escape end char. Please,
> consider that we must transfer instruments which should have over 1MByte!!
> 
> I'm thinking about some special events which should point to shared memory
> (to avoid trouble with kernel-side memory allocation). In shared memory
> should be stored whole instrument (headers & data) and lowlevel wavetable
> driver should reject bad instrument and accept good instrument.
> 
There's no limit to the size of a sysex message. Waldorf (for example)
transfer the whole Microwave operating system as a sysex message.


...
> > What I have in mind is plug-ins a la Cubase VST etc. Here's an example:
> >
> > 2 plugins: software synth (synth), software reverb (reverb); and the
> > sound card (card)
> >
> > card:
> >   register_midi_source(midi_in)
> >   register_audio_destination(audio_out)
> >
> > synth:
> >   register_midi_destination(syn_midi_in)
> >   register_audio_source(syn_audio_out)
> >
> > reverb:
> >   register_audio_destination(rev_audio_in)
> >   register_audio_source(rev_audio_out)
> >
> > route card.midi_in to synth.syn_midi_in
> > route synth.syn_audio_out to reverb.rev_audio_in
> > route reverb.rev_audio_out to card.audio_out
> >
> > So MIDI messages come in from the card's external input and go to the
> > synth. The synth generates sound which is routed to the reverb and then
> > to the card's audio output.
> >
> > There could be more effects between the synth and output, or the output
> > could go to a hard disk recorder. Come to that the synth could be made
> > up of multiple plugins. All this is, of course is going to take a lot of
> > processing power. I wonder if it might be possible to base plug-ins on
> > something like csound and move some of the load to DSP chips.
> >
> >
> > The way I envisioned ALSA was that the drivers would take care of the
> > card specific details and the libs would provide an abstraction where
> > everything was a MIDI/Audio source/destination. A MIDI destination could
> > be an external port, an internal synth or a software synth but the
> > application wouldn't have to know which, it would just be something you
> > could send MIDI data to.
> 
> I'm not sure if routing PCM stream over kernel is good idea. What about
> this scheme which is already prepared (using your example):
> 
> [MIDI generator] -> [MIDI plugin interface] -> [kernel sequencer] ->
> [MIDI plugin interface] -> [software midi synth in user space] -> [PCM
> plugin effect interface] -> [PCM device in kernel]
> 
> Note that ALSA driver is used here only for routing between two
> applications in user space.
> 
> This means that software midi synth takes care how will be PCM output from
> this device processed. We can design some plug-in interface in alsa-lib
> for both PCM and MIDI devices which should parse some configuration and
> use external code in dynamic libraries.
> 
>                                                         Jaroslav
I'm not sure how this is different from my idea. In my example, only the
original MIDI in and the final audio out go through the kernel.

> 
> -----
> Jaroslav Kysela <perex@jcu.cz>
> Academic Computer Centre, University of South Bohemia
> Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic
> 
> ------
> To unsubscribe from <alsa-devel@alsa.jcu.cz> mailing list send message
> 'unsubscribe' in the body of message to <alsa-devel-request@alsa.jcu.cz>.

-- 
George David Morrison
mailto:gdm@gedamo.demon.co.uk
http://www.gedamo.demon.co.uk


