iiwusynth-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [iiwusynth-devel] iiwusynth


From: M. Nentwig
Subject: Re: [iiwusynth-devel] iiwusynth
Date: Sun, 05 May 2002 20:25:39 +0300

> -----Original Message-----
> From: ext Tim Goetze [mailto:address@hidden
> Sent: 05 May 2002 20:00
> To: address@hidden
> Subject: Re: [iiwusynth-devel] iiwusynth
>
>
> M. Nentwig wrote:
>
> >Hello,
> >
> >I'll leave most answers to Peter, but I can at least try to help with

> >the two last items:
>
> thanks!
>
> >- The velocity mapping has been changed roughly three days ago. I
> >remember, that soft notes dropped too low, because of the
> shape of the
> >concave-convex curves (this is now implemented according to
> the SF2.01
> >specs, everything else is a bug).
>
> good to know that the spec is being followed in the engine. it's
> easier to direct counter-measures that way (mapping velocity or
> modifying the soundfonts).
>
> >If a known sound font doesn't work as it should, please let
> me know. The
> >specs are rather vague, especially when it comes to the vel-to-filter

> >default modulator.
>
> for me it's hard to tell how they *should* sound -- first, my awe64
> came with only 512k so most fonts don't work with it (plus i assume
> the emu8k chip uses cheap integer calculation internally anyway). and
> second, i don't have any other sf2 engine at my disposal.
>
> [...]
>
> >- The gain is frequently causing me a headache. But the
> default should
> >be safe, that is low.
> >So I have changed the default from 0.9 to 0.2 (dropped
> roughly by 13 dB)
> >in the last changes to CVS. This will make it even worse for you.
> >Luckily, you can simply issue the command
> >gain 1
> >from the command line,  iiwu_synth_set_gain(synth, gain)
> should do the
> >same from C.
> >Sadly, most soundfonts on the net are not normalized, so
> some gain boost
> >is needed (of course it will also lift up the quantization
> noise at the
> >low end).
>
> the 2 MB font that came with the awe is normalized, but the output
> peak varies from preset to preset. it never seems to exceed 0.2f
> though, so at least it can be said to work as expected. :)

Good news :-)

>
> >For real-time piano sounds I usually use a limiter as LADSPA
> plugin to
> >prevent the worst digital clipping, and then as much gain as sounds
> >good.
>
> yeah, the limiter is a good idea to help out here. however in my
> project the synth output signal will feed a DSP chain, and it's far
> more flexible to apply the limiter somewhere in that chain than to
> have it at a fixed place within the synth.

Yes, that's right. Clipping float output data doesn't make sense. I
tried to be consistent, when I changed the 16-bit output clipping code
(...that prevents the worst damage to ears and equipment), and so floats
got clipped, too. I'll fix that.
In the meantime, please feel free to edit 'iiwu_synth_write_float' in
'iiwu_synth.c' and comment out the range limit...

By the way: If you compile your DSP algorithm into a LADSPA plugin, you
can insert it easily into the master output.

>
> therefore the code clamping the output to [-1, 1] in *_write_float is
> a major annoyance to me -- it effectively makes the signal unusable
> once it starts to oversteer within the engine. i have a feeling this
> clamping is based on the assumption that the signal already went
> through a limiter.
>
> btw, is somebody working on making drumkits work right? in the
> above-mentioned 2 MB font, a closed hihat should cut off an open
> hihat. with the awe64 it does, in iiwu it doesn't.

This feature (exclusive groups) is not yet implemented, good that you
mention it. I'll have to find a good GM soundfont to try that.

>
> tim
>
>
>
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/iiwusynth-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]