Re: [iiwusynth-devel] Ideas

[Peter Hanappe]

> 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$
> :)
>

Hi all,

I'm jumping in a little late again. Let's just say that I gave the
mail a long thought... This reply has become quite long, too.


> ==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.

I think that's a really good idea.

BTW, I don't know much of sysex messages, but aren't there a couple
that are almost standard, like transfering samples through sysex.
If so, should we implement them? Does anyone have some docs about that?


> 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").

Sounds great to me!


> ==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.

I don't if that is what you mean, but there is the iiwu_synth_cmdfile
function. It takes a pointer to the synth and an open FILE* pointer
and evaluates the command in the file line per line (comment lines
starting with # are skipped).

Undocumented feature:
iiwusynth and iiwuplay try to read ~/.iiwusynth and, if that file
doesn't exist, /etc/iiwusynth.conf. Those files can contain any command.
It's useful to load default soundfonts and set default presets. This
currently only works on Linux but something similar could be made to
work on Windows.


> ==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.

I have to admit, Markus, that I've never been completely happy with the
LADSPA implementation. Don't take it wrongly, but somehow I think it's
too good for the synth. I would have preferred something simpler. The
current implementation comes close to a patch-like language. My ideas
might seem a little restrictive on this, but I don't think they are.

Here's my view:

1) All instruments can route their output to the chorus
and reverb modules. These modules are run in parallel and the output
is mixed into the stereo signal.

The values of chorus and reverb send can be controlled using MIDI CC 91
and 93. Both are part of the so called General Purpose Controllers
(GPC). There are 8 GPC, 4 with a range of 0-16384 and four with a range
of 0-127. Why not simply allow 8 effects modules in parallel. Two are
defined by the standard (chorus and reverb). The other six can be loaded
with LADSPA plugins. Each has an 'effects send' controlled by the GPC
messages.

It's very straightforward and easy to understand since it it similar to
a studio set-up. Want another effect? Just issue a 'effect 3 flanger'
to load the flanger plugin into effects slot 4 and send GPC7 (CC 92)
midi messages to control the effects send.

2) I think it's okay to copy the LADSPA code as a start. However, it's
not a long term solution and I'd prefer to avoid it altogether. Porting
most of the LADSPA plugins to windows and mac is not that hard, I think,
since they contains very little platform specific code. I can contact
Steve Harris to have his opinion on this.

3) Users who want more sophisticated routing possibilities should use
iiwusynth in combination with PD/jMax or Jack in combination with an
other application like AlsaModularSynth or SpiralModularSynth.
I think it's a win-win strategy to keep fluidsynth simple and make it
interoperate as much as possible with other software.

FYI:
AlsaModularSynth: http://www.suse.de/~mana/kalsatools.html
SpiralModularSynth: http://www.pawfal.org/Software/SSM/


> ==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 :)

How about this: we fix all the small things that are trailing
and we focus on a FluidSynth 1.0 release in two weeks?
Antoine, do you think the Xtra could be ready then, too?

I will do the name change this week and put up a simple but decent web 
site. By the end of next week, we start making noise (freshmeat, tucows,
mailing lists, ...)!!!


> ==Web page: FluidSynth (iiwusynth) applications==
> How about a 'howto' page? I could contribute material about using the
> standalone program on Linux. Draft:
> [cut]


Maybe also: HOWTO's for some useful set-ups:
- Muse + Swami + FluidSynth
- Muse + FluidSynth as plugin
- Jack + Swami + FluidSynth
- ...


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

> [skipped]


> ==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.

Some of my comments on 'LADSPA Fx unit' apply here as well.

First a little concern: the FluidSynth should by default be SoundFont 2
compliant so that users can expect it to work similar toa hardware
synth. It should be clear to users that any extra features are
non-SoundFont.

I think it's more interesting to add an API function to export
multi-channel audio. That way application developers can use that to
offers whatever mixing they like. I don't think that the mixing
should be part of FluidSynth, except perhaps in the audio drivers.


> ==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.

See my notes on  the LADSPA Fx and the channel output.

> ==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.

A side note:

If we decide to load LADSPA plugins as explained above, maybe the user
should be able to replace the default reverb and chorus with a LADSPA
chorus and reverb.


> ==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.

I'm quite happy with that. We should definitely do that.


> I better stop writing before this mail gets any longer. But I'd be happy
> to hear from you.

Idem!

> As I said, it's just a list of ideas. Fixing existing bugs wouldn't be
> such a bad thing, either.

We're making progress, Markus! It's getting better all the time!

Cheers!
Peter

> Cheers
>
> Markus
>
>
>
>
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/iiwusynth-devel