Re: [linux-audio-dev] finding the selection length with LADSPA

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

Subject: Re: [linux-audio-dev] finding the selection length with LADSPA
From: Michael Thompson (mat0001_AT_jove.acs.unt.edu)
Date: Thu Oct 19 2000 - 01:27:06 EEST


hmmmm I dont think LADSPA is designed the way you are thinking. It is a
real-time plug-in arch that processes streams of data, it doesnt need to know
how long/big the stream is.
The fade functions in Peak, SoundMaker, SoundEdit 16, and SDII are not intended
to process streaming audio in real-time but get the number of samples to
process from the selection. Without explicitly typing the data into the plugin
parameters window you are supplying the plugin with the extra data by selecting
it, the plugin is getting that data from the host (can be a callback or these
params are part of the base class plugin api containing the selection params
that all plugins of this type have access to if they need it. Maybe a
non-real-time version of LADSPA is needed like the VST out of real-time
extensions in the VST2 SDK. The only thing you would need, other than the
member functions/storage to access/store this selection data, is for the host
to be able to tell which plugin is real-time or not...... doesnt LADSPA have
that already?
just an idea....

Michael

douglas irving repetto wrote:

> David Benson wrote:
> >
> > > yes, it seems like it's a problem if it's impossible to implement a fade
> > > in/out filter that operates on a user selection. requiring a user to
> > > type in a number of samples to fade over is kind of old skool, and is
> > > redundant if the user has already selected a region. i can think of many
> > > cases where it's necessary to know the total number of samples selected
> > > before beginning the processing.
> >
> > may i suggest making the fade time be a parameter
> > of the filter? (an input control parameter)
> >
> > in a streaming context, that's really all you can do:
> > ladspa does not model the end of a stream.
>
> i can see how that would work. but it seems like that's putting the user
> in a position where they need to know things that the host may not be
> telling them.
>
> for instance, when i work with an editor (like peak on the mac) and i
> want to do a fade, i simply select some audio and run the fade in filter
> on it. i'm not thinking about how long the selection is or how many
> samples there are or anything like that. and depending on how the gui is
> set up, i may or may not have any way to get at that information anyway.
> what i do know is that i've selected (visually) the exact region that i
> want faded. i guess that an intelligent host program could fill in a
> default value for me, one that is equal to the length my current
> selection. but there's no way to enforce that behaviour.
>
> it seems to me that an awful lot of filter-type operations are most
> conveniently handled by a simple "select the region and run the filter"
> model. and for any process that requires parameters to move from one
> value to another over the run of the process, the plugin needs to know
> the total number of samples that have been selected. having a user type
> in a time parameter could be both awkward and potentially inaccurate.
>
> then again, i'm still just getting to know LADSPA, so please if i've
> missed something or said something dumb let me know!
>
> in the mean time, i'll implement the fade filter with david's suggestion
> above.
>
> thanks,
> douglas
>
> --
> douglas irving repetto
> http://music.columbia.edu/~douglas
> the music-dsp mailing list and website:
> http://shoko.calarts.edu/musicdsp


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

This archive was generated by hypermail 2b28 : Thu Oct 19 2000 - 03:05:34 EEST