[iiwusynth-devel] Ideas

[M. Nentwig]

Hello!

Here are some ideas I had during the last couple of weeks.
Ideas are a dime a dozen. The value of this mail should be roughly 1$
:)

==MIDI Sysex and command line==
What, if we implement a single MIDI sysex command, that transmits an
arbitrary command in plain ASCII format, similar to the command line?
This would allow to remote-control any of the features from a sequencer
(also the odd stuff like selecting an interpolation algorithm, or the
LADSPA Fx Unit). This would make FluidSynth really powerful in a
sequencer environment. Also, there wouldn't be any need for dedicated
MIDI-control documentation.


==Same for API ==
To take it further, why not add an API function, that interprets an
arbitrary command? For example
double myresult=iiwu_asciicmd(mysynth,"reverb 0");
Reading output from the synth could use a buffer for the general case.
iiwu_asciicmd(mysynth, "inst 0", buffer,256).

I just added API functions for reading each parameter of reverb and
chorus, and got a headache over it.
I'd rather get rid of the whole mess and add a bunch of command line
functions to do the same, like
double myresult=iiwu_asciicmd(mysynth,"reverb_get damp"); (or
"reverb_get roomsize" or "reverb_get width").


==Batch command==
Load the contents of an ASCII file as command line input. Interesting
combination: Issue the batch command via sysex - work with a sequencer
and edit the synth setup changes in a text editor at the same time.

==LADSPA Fx unit==
There hasn't been much interest in the LADPA Fx unit lately. I still
believe it has great potential, especially together with the MIDI sysex
implementation mentioned above. Now LADSPA is Linux-only (it loads a
library at runtime). That's why I'm planning to integrate a couple of
'bread-and-butter' plugins (mixer, EQ, delay) into the synth (just copy
the files and remove any overhead).
One could argue, that dynamic libraries were invented to avoid copying
the same code all over again. But Fluidsynth code growth clearly lags
behind RAM increase.
Also I don't expect that a converted LADSPA plugin will need much
maintenance in the long run.


==Advertisement and stable release==
I just noticed, that there are a lot of Timidity enthusiasts out there.
While Timidity has some additional features, I think FluidSynth / Swami
have clearly more to offer as a realtime synth with standard sound
fonts.
Should we let them know about FluidSynth one day? OK, preferably -after-
making a stable release :)

==Web page: FluidSynth (iiwusynth) applications==
How about a 'howto' page? I could contribute material about using the
standalone program on Linux. Draft:
- compiling
- starting iiwusynth
- - Audio: Alsa examples, hw and plughw
- - Midi: Alsa examples, using snd-virmidi to run without hardware midi
interface
- - testing that it works (noteon with "vintage dreams")
- - testing MIDI in (--verbose)
- - fixing audio problems (plughw, fragments)
- - latency (buffer size) and how to 'measure' it (listen to your MIDI
keyboard and iiwusynth at the same time)
- - Realtime stuff (running as root or suid +s iiwusynth)
- - setting gain
- - turning on chorus
- - batching command files (tail -f -n 1000 mycommand | iiwusynth ...)
OK, this sucks, see ==batch== :)
- - example on how to use Swami to get rid of the default modulators
- - bank changes, choosing programs, choosing drums (bank 128)
- - 20-line perl Tk program example to automate the setup

What's the best format to get this going? Any objections to LaTeX
(latex2html)?

==Synth features==
How about a mono mode and portamento? The SF2.01 standard doesn't say
anything about those.
A command line interface plus the general API functions should do to
turn it on and configure portamento behaviour.
This has a rather low priority for myself. But if somebody is interested
I believe I can implement it easily (famous last words).

==Noteoff optimisation==
This has to be thought through again, I have a suspicion that the last
changes I made here badly screw up layered sounds. Any experiences?
I'll add a parameter 'maximum number of simultaneous voices', accessible
via the command line.
That many voices can then play simultaneously on the same key (all but
one in released state, since you cannot retrigger a key without
releasing it first). As soon as one more voice is triggered, the oldest
voice will be terminated rapidly. What's important (and currently
missing): Voices from different zones - instrument or preset level -
have to be handled independently.

==Single channel output==
If the now-LADSPA Fx unit is made system-independent, then it can be
easily used to set up an arbitrary mix for any number of physical
outputs. This includes routing channel 1 to output 1, channel 2 to
output 2 and so on.
The number of output channels to use is set before starting the audio
driver. By default, the L/R mix is assigned to outputs 1 and 2.
As soon as the user sets up his own Fx preset, the default connection is
disconnected.

==Reverb / Chorus revisited ==
While it doesn't have to be done at the same time, the internal reverb
and chorus can be smoothly integrated into this concept:
They are included in the default Fx configuration. When building a
custom Fx setup, the chorus / reverb send outputs are available instead,
together with control nodes, which provide the chorus / reverb settings.

==Chorus==
I'm quite happy with the chorus sound as it is (any opinions about
that?). I might add a parameter 'predelay', change the interpolation
from 7 point sinc to four-point (more efficient) and get rid of the
lookup table, which puts a lower limit on modulation speed.

==Reverb==
Sometimes I wish for an adjustable low pass filter in the reverb line.
Copy-and-paste the voice filter with Q of 0.5.

==Hooking up a user interface via stdin / stdout==
There is a new command line switch --dump, that will produce ascii
output for each event. I use it to hook up my perl Tk user interface.
Perl Tk is simply great, it took roughly 20 lines of code to implement a
simple sequencer, that can record, save to disk and playback.

So what's probably going to happen next are the changes to the noteoff
algorithm and the how-to.

I better stop writing before this mail gets any longer. But I'd be happy
to hear from you.
As I said, it's just a list of ideas. Fixing existing bugs wouldn't be
such a bad thing, either.

Cheers

Markus