Subject: Re: [linux-audio-dev] aes: new model
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Fri May 18 2001 - 18:01:51 EEST
On Fri, May 18, 2001 at 09:13:25AM -0400, Paul Davis wrote:
> >Speaking of which, what do people think of having MIDI as a 1st class
> >thing (stream, events, whatever), as audio is?
>
> I am absolutely opposed. MIDI should be removed from the core of any
> not-purely MIDI API. Its fine to support MIDI, but ideally it would to
> be translated into a format that is not MIDI before it gets used by
I wasn't thinking of raw bytes, I was more thinking of pre-parsed objects.
I can't figure out if your objection was too sending raw bytes of MIDI or
to sending control signals that 1:1 relate to MIDI data.
I'm reading up on SKINI now.
> A much better idea is to support byte-formatted data on ports. Plugins
> that wanted to exchange MIDI could do so using such ports, but there
> would be no explicit 1st class MIDI ports within the API.
I would like to see it labeled as such, so that a user can connect a
sequncers "MIDI" output to a soft-synths "MIDI" input and an external MIDI
port and get what they expect.
> I thought I had it all worked out, but now I am trying to figure out
> how to efficiently execute the signal graph at the same time as
> supporting an rather nice model involving a matrix of port connections
> with gain values for each element (input port,output port) of the
> matrix (idea attributable to bill evans). I'm not sure its possible to
> be memory efficient with the matrix model.
I suggested something similar last year, but with gain controls at each
junction, I eventuly dismissed it as too expensive though, not suprising!
I don't see why it needs that much memory if you only have gain controls
in ins and outs though?
for row (0..rows) {
input_buffer[row] = {0,0,...0};
for col (0..cols) {
input_buffer[row] += output_buffer[col] *
gain_in[row] * gain_out[col];
}
}
or something like that.
- Steve
This archive was generated by hypermail 2b28 : Fri May 18 2001 - 17:35:22 EEST