Re: [linux-audio-dev] an interesting idea/point/issue from vst-land

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

Subject: Re: [linux-audio-dev] an interesting idea/point/issue from vst-land
From: Stephane Conversy (Stephane.Conversy_AT_lri.fr)
Date: Tue Mar 28 2000 - 12:12:44 EEST


Paul Barton-Davis wrote:
>
> In message <01BF9823.02EB0FE0_AT_bartman.plc.psion.com>you write:
> >Interesting idea, but when will the reverb KNOW that is is done? One can
>
> Hmm. Interesting point. I was about to rush off with a very rapid
> answer, but I realized that really is non-trivial to determine
> this. The only "correct" answer is the one that we don't want: the
> host has to tell the plugins "i'm about to finish calling all of you,
> does anyone have any objections", at which point, the reverb would say
> "hmm, looks like we pre-computed a delay of 1.3737383 seconds until a
> maximal sample value would decay to an effectively silent level, so
> yes, please keep going".
>
> I don't know if there any way to fit this into the new functions you
> added for pre-run and post-run stuff, would it ?
>
> --p

actually this was the purpose of TurnOff.qm in quasimodo.
When a signal was lower than a certain value during a certain
amount of time, then the entire ModuleSet was shut up.
It's useful with any modules that ends, like a guitar string,
a reverb, a gaver impact, etc.
I'm not sure it's the right solution though.
At that time I thought about a module (could be a 'plug-in' for LADSPA
crews) that stops only modules chained into it and from it.
It was too complicated, and actually I didn't need it in the sounds
I made. It's a good example of a 'maybe-wanted' feature that I've never
found to be useful eventually.

About the float vs double issue, we have to take care that conversion
is very expensive, i.e. transforming a float* buffer into a double*
buffer
may make performance goes down.

And finally, another pros for float: I may want to use Altivec SIMD
instructions.
Often, the vector unit operations takes an amount of float operands
which is twice
the number of doule operands, so it's twice as fast. Not negligible.
I agree taking care of Altivec now may seem early.

Anyway, mixing double plug-in's and float plug-in's may be expensive,
and thinking too much about features we may want in the future lead
to endless discussions (that's true for most softwares: think
spiral...).

I propose to put a 'typedef float sample_type' in config.h or whatever
and run tests to compare performance and quality.

regards,

        stef

PS: I'm not an active participant to the list, I follow it, but I may be
completly ignorant of the actual issues raised up so far. If so, please
move silently this post into you trash.

-- 
Stéphane Conversy
http://www-ihm.lri.fr/~conversy/
mailto:conversy_AT_lri.fr


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

This archive was generated by hypermail 2b28 : Tue Mar 28 2000 - 11:42:58 EEST