Tommi Ilmonen
Tommi.Ilmonen@hut.fi
First thing to try is to put on debugging mode. This is done with command line argument
``--debug all''.You can also debug some other targets more selectively by using other arguments in place of ``all''. The possible arguments can be listed with argument ``what''.
Plugin loader can be debugged by adding the following arguments in the command line:
--debug plugin_base plugin_loader
The total command might look like this:
./Linux-i686/dmain mixer2.mj --debug plugin_base plugin_loader
Then scroll up the page to see warnings about the modules. Typically a module fails to load due to missing symbols (missing variables, methods).
IRIX tends have trouble with the current CC flag settings. You have two choices:
1) Remove ``-LANG:std'' from the list of compiler arguments. This usually helps. You must rebuild all binaries after this.
2) Try to work around the SGI bug. First define TOOLROOT environment variable:
export TOOLROOT=""
Then make target ``smain'' in divabase, divaio and mj. Then make ``all'' in the usual fashion.
Mustajuuri is a multiplatform/multicompiler effort. The choice between including iostream.h and iostream needs to be made when using certain standards-compliant compilation modes. This leads to horrible things in the code:
#ifdef _STANDARD_C_PLUS_PLUS #include <iostream> using namespace std; #else #include <iostream.h> #endif
The most direct way to avoid this is to not use the normal iostream classes.
By default all the plugins you compile end up under the ``plugins'' directory in Mustajuuri main directory. This behavior can be altered by setting certain environment variables.
MUSTAJUURI_PLUGIN_TARGET defines where the plugins are stored (linked). If this environment variable is undefined, then the defaults are used.
MUSTAJUURI_LIB_TARGET defines where the libraries (plugins are libraries) are stored (linked).
Typically you want to set both of these together. The latter is useful if you have plugins that link against each other (do remember to update LD_LIBRARY_PATH).
The most common cause for this is that the FPU found in Intel systems have trouble with underflows. If you have and IIR system (reverberator etc.), then at some point the floating point values will drop velow what the FPU can calculate with standard accuracy. As a result the FPU makes an interrupt. Then Operating system comes to the scene and finds that everything is ok. Eventually the the control returns to the application. This useless work consumes plenty of CPU.
We have not found a decent fix to the problem. The most satisfactory
solution is to manually flush small numbers to zero. To see an example
of this see the method MJ_FilterDFIITElem
::put in
mustajuuri/src/mjdsp/mj_filter_iir.h.
On most other platforms (MIPS, PowerPC) you do not need to do this.
This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 FAQ-devel.tex
The translation was initiated by Ilmonen Tommi on 2004-11-18