Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Mon Nov 27 2000 - 12:49:20 EET


On Sat, Nov 25, 2000 at 12:50:38PM +0000, Paul Sladen wrote:
> On Fri, 24 Nov 2000, Paul Barton-Davis wrote:
>
> > As far as I am concerned, this is a broken model. Plugins should use
> > ONE standard data type.

Heah hear, and I'm, not just saying that to be lazy ;)

I would argue for MIDI streams (preparsed or not) though. Given a UI you
could easily make a synth out of LADSPA.

> > Yes, I think we should take the high road
> > some day and support non-linear-amplitude data streams the way that
> > CSound does (spectral data etc.). We'd be a big step ahead of VST if
> > we could do that.

What is this? It sounds to me like amplitude stored logarithmicly (a la.
/dev/audio), I can see the advantage, but doesn't it make the maths hard,
and what does it have to do with spectral data?

> Hum, I'd quite like to be able to feed in an MP3 in/out of a plugin,
> although *far* more importantly is to be able to take a block of
> frequency-domain audio.... just think about this, feeding it from a
> pitch-shifter to a time-stretcher, both of which can input/ouput
> (possibley as their default format) a freq-domain stream... hey, but
> haven't we just saved two FFT operations -- ok, bad example, because
I'd
> had grand ideas of the simple call:

That sounds like a bad idea to me. MP3 is a really bad format for
processing, and the ammount of CPU taken to (even half-assedly) FFT an
audio stream is way too much. Unless you know exactly what filter is
going to be applied to the frequncy domain data, you don't know what
corners you can cut when making it.

I found out the hard way how slow full FFT is on intel CPUs, its really
not going to be realtime any time soon. Maybe Intel could do an FFT MMX
extention ;)

> ciSampleSpeed( {speed relative to 1.0}, {pitch shift relative to 1.0}
);
>
> which I was going to plug the higher-3d postional API directly into.
>
> think MP3 decompress -> {as Freq} Pitch-shifter -> {as Freq} inFFT ->
{as
> time-based audio} linear player.

Why do you want this? MP3 is pretty grotty compression and disk space is
cheap.

- Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Nov 27 2000 - 13:48:06 EET