Buzzmachineloader

From Buzztard

[edit] Overview

Currently we use a two stage wrapper to get acces to the buzzmachines:

 gstreamer-plugin \
 ladspa-plugin    -> libbml.so -> buzzmachineloader.dll -> <buzzmachine>.dll (wrapped)
 XXX-plugin       /            \> buzzmachineloader.so  -> <buzzmachine>.so (native)

The windows buzzmachineloader.dll wraps the C++ buzzmachines with a C API and provides the machine callback class. The linux libbml.so in turn handles the wine based loading of the windows buzzmachineloader.dll and firther dll's. With the gstbml modules we have a gstreamer plugin using the buzzmachine emulation. Likewise one can e.g. wire a ladspa plugin using the libbml to make buzzmachines available in ladspa hosts.

Some buzz-machine author have published soures. Those can be built natively under linux (after #ifdef'ing the windows stuff).

[edit] Building

Right now the adapter dll is built using VisualStudio. We should try to use the mingw cross compiler under linux.

[edit] TODO

Many parts of the wrapper just log that they have been called. Whenever buzztard triggers such logs we look into implementing the functionality.

[edit] wavetable

We need an WaveTableAccess interface for GStreamer plugins. The GstBML plugin would receive the WaveTable object by functions of the WaveTableAccess iface. It can then build a structure with wavetable table as requested by libbml (non gobject form) and pass it there (one interface property). The GstBML plugin will just pass it thrugh to bml. The interface could be defined in gst-buzztard as both buzztard and gstbml depend on it.

Buzz machines only have only a few things that they really need:

// CWaveInfo flags
#define WF_LOOP		1
#define WF_STEREO	8
#define WF_BIDIR_LOOP	16
 
// there is a max of 200 waves (index 1..200)
CWaveInfo *waves[200];
 
struct CWaveInfo {
  int Flags;
  float Volume;
  CWaveLevel *levels;     // NULL term. array of wavelevels sorted by root-note
};
 
// each wave can have multiple wave-levels
struct CWaveLevel {
  int numSamples;
  short *pSamples;        // interleaved if stereo
  int RootNote;           // buzz note number?
  int SamplesPerSec;
  int LoopStart, LoopEnd; // as sample number
};
 
class CMICallbacks {
  ...
  virtual CWaveInfo const *GetWave(int const i);
  virtual CWaveLevel const *GetWaveLevel(int const i, int const level);
  virtual CWaveLevel const *GetNearestWaveLevel(int const i, int const note);
  ...
};

The buzztard wavetable objects look like this:

struct BtWaveTable {
  GList *waves;
};
 
struct BtWave {
  int index;
  gchar *name, *uri;
  GList *wavelevels;
}
 
struct BtWaveLevel {
  guchar root_note;          /* the keyboard note associated to this sample */
  gulong length;             /* the number of samples */
  glong loop_start,loop_end; /* the loop markers, -1 means no loop */
  gulong rate;               /* the sampling rate */
  guint channels;            /* the channels (1,2) */
  gconstpointer *sample;
}

[edit] Native Machines

If you are an author of a buzzmachine, it would be super-cool if you decide to share your sources! Please send them to us (Ensonic,Waffel), along with a licence you've picked (LGPL, MIT, BSD, ...). This makes your hard work on the machine live on!

The plan is to have a separate buzzmachine source projects (e.g. "buzzmachines" on sourceforge.net) to provide buzzmachines to all kind of projects (like buzé (calvin@countzero.no), buzztard and aldrin (aldrin-users@lists.sourceforge.net)). The project should be buildable under linux (autoconf/automake) and under windows (msvc projects). The rationale behind:

being able to fix bugs in machines
make up-to-date releases
improve docs
merge in new presets

Buzztard has some ported machines in a svn module right now. We have more sources, but they need cleanups and porting still.

Below some thing that need to be discussed:

[edit] Linux Releases

We need to agree on some details:

where to install the plugins?
- ensonic: $prefix/lib/buzzmachines
where to install the docs?
- ensonic: $prefix/share/docs/buzzmachines, $prefix/share/buzzmachines/docs
where to install the presets?
- ensonic: $prefix/share/buzzmachines/presets
do we want to keep 'generator' and 'effects' subdirs?
- ensonic: no
do we want to install unported machines (buzztards wrapper can use them too on x86)?
- ensonic: installing them in the same directory ($prefix/lib/buzzmachines) is ugly

[edit] Machine Docs

It would be nice to have docs in the same format and have same look.

html + css docs
docbook docs
- generate html
- not so easy to write
- not that beneficial for short documents
rest
- generate html
- easy to write

[edit] Merge Presets

We would need some tools to manage preset merging. We can have the default presets that we ship in the repository. When users contribute their presets, they need to be merged. The merging should skip duplicates and maybe warn about similar presets.

[edit] Adding new machines

How to handle new sources? Add new sources to the bugtracker. Once its ported to either win/linux it can be added to the svn. We would need some guidelines for cleanups before adding them. E.g. lot of machines where done as a copy of an existing machine. At least the main source should be renamed.