|
List Info
Thread: Re: cooperative plugins?
|
|
| Re: cooperative plugins? |
|
2008-02-08 11:00:50 |
|
I like the functionality of the proposal. It would certainly make my
life easier. If this is wish list time it would be nice to create a
track in nyquist if needed rather than making the user create a dummy
track for output. My current applications don't do in place processing
Here are some alternative implementation ideas which might be safer or easier to implement:
1) Deal with multiple tracks before calling Audacity. Make it an
extension of he thpe 2 dialog interface. In the plugin header add
fields to specify the track needs of a plugin and then pop up a dialog
to let the user do the mapping. Then code to setup track access to the
plugin could be implemented in C before calling nyquist. That would get
rid of the interactive nyquist directory services followed by dynamic
interaction with all tracks. which I'm guessing might be a potential
maintenance issue. The more things in Audacity state nyquist chan
change the more Audacity code needs to cope with these changes.
2) Add a new data type for a read only track access and allow multiple
read only tracks as input. It should be possible to optimize read only
processing for speed. Let the current interface be the only write
access. Put the added read only tracks in a different variable (R?)
3) These don't really solve the multiple pass problem for plugins that
WANT to process data in place. Perhaps that could be handled by alowing
a read only track data type and current "s" read/write interface to
point to the same track. In the general case this would defeat
optimizing the read only interface (the read only interface would need
to be aware of changes made by the read/write track interface) but a
simple fix to this is don't allow access to a read only track that has
had its data modified. Make it a programming error. A simple dirty bit
is cheap to implement.
These proposal might preserve much of he security of the current
interface to nyquist and might be simpler to implement. It is not quite
as general as your proposal but it might be good enough for the next
generation of plugins.
On Feb 3, 2008 9:09 AM, Roger Dannenberg < rbd cs.cmu.edu" target="_blank">rbdcs.cmu.edu> wrote:
I hereby proclaim edgar is rapidly becoming a Nyquist guru. Thanks for
all the recent answers, which are not only correct, but contain some
details I'd have to look up myself.
It strikes me that the Audacity/Nyquist interface needs to be extended.
While the plug-in interface has worked well for simple things (and
probably kept a lot of people out of trouble), I'm thinking now that a
future version should include:
A directory service: plug-ins should be able to query the track
configuration; either Audacity could initialize a Lisp variable to
contain a list of track descriptors (name, position, # channels, volume,
pan, sample rate, location of segments, etc.) or there should be
primitives to get this information (e.g. (NYX-GET-TRACK-INFO n), etc.)
Explicit info on selection(s): again, either a Lisp variable with data
or a primitive to query for info on the user's current selection.
Ability to read from tracks: a new primitive, SND-READ-TRACK, returns a
lazily-evaluated sound consisting of samples from a selected track.
Ability to write to multiple tracks: SND-SAVE-TRACK would contain
descriptions of where to put samples and a Lisp expression that returns
a multichannel sound. The sound is evaluated and written to the
indicated tracks. (This is particularly hard to implement, but the
SND-SAVE-ARRAY primitive provides a model.)
This proposal is based on the way in which Nyquist currently
reads/writes files. Unlike the current method using the variable S, this
would allow multiple selections as input, multiple passes over
selections, and multiple modifications/edits of the user's audio tracks
from a single plug-in invocation.
As an example, this would allow a two-pass normalization: read the
input sound and compute the peak amplitude, then read it again and scale
it accordingly. I wouldn';t do all the work just for this one example,
but there are more interesting problems, discussed recently, that this
would solve.
--
Steve Morris
barbershopstevegmail.com" target="_blank">barbershopstevegmail.com
Bass: Unnamed quintet
Bass: Sounds Of Concord
|
| Re: cooperative plugins? |
 
United Kingdom |
2008-02-08 16:11:34 |
Also if this is wish-list time, here is another one (I have
no idea of
the practicality, and I am speaking of use of a plug-in in
Audacity).
.
When an error is thrown can the plug-in be reloaded, to save
the
quite circuitous route to do so manually? I have another
related
reason for asking, which is that a number of David Sky's
recent
plug-ins included a control to display a Help screen instead
of
perform the plug-in's function. However on pressing OK in
the
Help Screen you also have to reload the plug-in.
Gale
------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-nyquist mailing list
Audacity-nyquistlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audaci
ty-nyquist
|
|
[1-2]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|