[iiwusynth-devel] Re: Pitch bend, filter, sysex, LADSPA,...

[M. Nentwig]

> -----Original Message-----
> From: ext Josh Green [mailto:address@hidden
> Sent: 06 April 2002 20:22
> To: M. Nentwig
> Cc: Peter Hanappe; iiwusynth devel
> Subject: Re: Pitch bend, filter, sysex, LADSPA,...
>
>
> On Sat, 2002-04-06 at 09:11, M. Nentwig wrote:
>
> <cut>
>
> > =========LADSPA effect unit=========
> > In my opinion, the LADSPA code is now good enough to include it.
> > Several small changes are made in the configuration files,
> there is now
> > an option --enable-ladspa (default=no) available for ./configure.
> > I have written a small perl-Tk script, that shows a couple
> of sliders in
> > a window, which allow real-time control of effect
> parameters (chorus,
> > reverb, overdrive,...)
> > This is not included, but if anybody would like to try, I can make a

> > 'bundle' (soundfont, plugins, script).
> >
>
> I'm curious about your LADSPA code. Is this a host? I've seen
> the LADSPA
> iiwusynth plugin client code in the iiwusynth source tree,
> but I have a
> feeling your talking about something else. If this is a host
> that allows
> LADSPA plugins to be added to the iiwusynth chain than, cool! I'd like

> to give it a try. This is one area where iiwusynth could be
> made really
> pluggable, if one could choose which LADSPA plugin to handle
> chorus for
> instance, and the control ports were modulated by iiwusynth.. Neato..
>

Yup. It's a simple host, which understands a five-word control language.
It can process LADSPA networks of arbitrary size. There is a small
manual (PDF and HTML) in a folder in iiwusynth/src (on sourceforge).
Just give it a try, the directory should be ready for compilation (after
autogen).
You'll have to ./configure --enable-ladspa (all small letters) to
include it. But the LADSPA plugins are not included. I use CMT and SWH
plugins, and 'alienwah'. I can forward them to you, if you are
interested.
The environment variable LADSPA_PATH needs to be set, this is LADSPA
standard (export LADSPA_PATH=/usr/local/lib/ladspa should do).


> > ========Pitch bend=====
> > There was a problem in the code handling program change events: a
> > 'break' was missing, a pitch bend event resulted for each
> program change
> > (to the wrong pitch). This was right in an older version
> (was one of my
> > patches involved here? nooooooo :-), now it works again.
> > Also, pitch bend default is now 0x2000 (center).
> >
>
> Nice find :)
>
> >
> > ========Signal to soundcard=======
> > The signal is now clipped for positive and negative peaks.
> Currently,
> > clipping produces a message (one might argue that clipping
> deserves an
> > error message...).
> > Same in the 'float' code, but untested due to the lack of suitable
> > hardware.
>
> Rock on.
>
> > =========Bank select============
> > My own masterkeyboard sends a bank change with each program
> change. This
> > is completely useless for controlling iiwusynth. I have therefore
> > included a switch (set with #define MN_CUSTOMIZED), that
> disables bank
> > switching through the MIDI input, and prints a warning. Command line

> > bank switching (select) still works. But since the switch is not set

> > anywhere, this will not affect other users anyway.
> >
>
> Is it completely useless? You can have different bank numbers for
> presets loaded into iiwusynth. I'm not sure I understand why
> this would
> be useless. If you have more than 128 presets in a sound
> font, you have
> to use the bank change parameter to get access to the other presets.

Well, the keyboard changes the bank to 16000-and-then-some each time I
press a program button. The sound fonts are usually on bank 0. So there
is no preset on the channel after the program change.
So 'useless' is maybe the wrong word (I could change the bank of a
soundfont before using it), but it's complicated.
And if I dig into the keyboard manual deep enough, there might even be a
way to send only prog changes without bank change - after all, that
beast is called a master keyboard.

>
> >
> > =========Gain=================
> > Changed the max-limit to 5. There are some rather 'quiet'
> soundfonts out
> > there, which would need a boost. And, together with the
> LADSPA limiter
> > set to a soft curve, it helps to get a nice, warm overdrive
> sound. And
> > an incredible volume level, when compared to the 'clean' sound, just

> > below clipping.
> > By the way: The limiter is finished, documented and ready-to-go. Is
> > anybody interested in the LADSPA plugin?
> >
> > This is quite a lot of stuff, I hope I don't keep you too
> busy. Please
> > let me know, if there are any problems, of if something
> should be solved
> > differently.
> >
> > Then, I tried Swami today for the first time, and after having an
> > extended jam session on my (computer) keyboard I must say
> that I like
> > it.
> >
>
> What would be really cool next is to implement real time modulation of

> as many of the sound font parameters as possible :) Sound font
> modulators could then be implimented on top of this. How easy would it

> be to do this? (Peter?) I've seen a bunch of modulator code in
> iiwusynth, but I'm not sure as to how close it is to working.
> A problem I can see with real time modulation of effects is in how the

> API would allow the selection of a voice (in a preset). Perhaps a
> function could be added like:
>
> iiwu_voice_offset_effect (synth, channel, voice_number,
> gen_id, amount)
>
> Since iiwusynth has no idea about the sound font layers
> (preset, preset
> zones, instrument, instrument zones) when using the sfloader API, it
> would be up to Swami to re-calculate what voices need to be offset. I
> suppose something like a iiwu_voice_offset_effect_global routine would

> be nice too to offset all voices on a particular MIDI channel.

> > And now I'll go down to the bomb shelter and play some music.
> >
>
> Is this for your own protection, or the protection of your
> neighbors? :)

Both. Nice thick walls.

>
> > Cheers
> >
> > Markus
>
> Lates.
>  Josh Green
>
>


Cheers

Markus