[linux-audio-dev] plugin ideas based on Guenter's mix plugin API

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

Subject: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: est_AT_hyperreal.org
Date: to elo    26 1999 - 14:34:31 EDT


Guenter Geiger discourseth:
>
> If people want to try their favorite filter, effect or the like within
> mix, go ahead programming a plugin, send me the code and suggestions
> how to make the API better :)

Here are my suggestions for the API taking it as a starting point for
a general plugin standard. I understand that Guenter may not have
intended it to be used for that purpose, but, in any case, I applaud
him for taking the lead on this by posting his API. :) I'm really
excited about the idea of coding to a spec that this list has worked
over. The prosepctive increase in functionality is dazzling. I hope
Guenter will put audioplug.h on the web for wider availability.

Note that these suggestions take the contents of the strummin
directory as their context. Many of my suggestions may be based on
ignorance or misunderstandings.

* The whole thing should move to a class/instance paradigm so I can
  instantiate multiple instances of a plugin. Parameter descriptions
  should be in the class and their values in the instance, etc.

* The only global defined by a plugin should be a uniquely named
  function that returns a plugin class. The idea here is to make it
  possible to use static as well as dynamic linking.

* Change properties to a * int32_t to avoid binary compatibility concerns.

* Change sparebytes to a void * for the same reason.

* Change the prefix to something other than `st_' which has too much
  history in unix. A three-character prefix would be much safer.

* Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.

* The param/type field needs some definition and should have an enum
  type.

* We want to be able to say that a param must be integral.

* There should be a parameter default value field along with a flag so
  say whether it's valid.

* String parameters should be provided for.

* We need a flag to say whether a parameter can be modified in between
  any two calls to the process method as opposed to being settable only
  for initizlization purposes.

* The number of channels per input and output signal should be a
  plugin property vector. Counts of frames and samples should be
  clearly distinguished throughout.

* The sample rate should be optionally settable at instance creation
  time and the input and output buffer sizes should be optionally
  settable per call to the process method. I usually code in a way that
  can accomodate this, but I agree that it's important to support less
  flexible plugins as well.

* To handle resampling, variable output buffer sizes are important.
  It's also important that the process method can report how many output
  frames it generated (is this the function of the return value of the
  process method?). It may even be important that the plugin can
  be queried as to how many output frames *will* be generated to avoid
  overruns due to disagreements about fencepost issues.

* The popup method should probably be expanded to a vector of generic
  gui methods.

* Memory allocation hooks are probably desirable. That way I can get
  a plugin to throw bad_alloc even if it know nothing about C++.

Hmm..enough for now. :)

Eric


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST