Re: [iiwusynth-devel] hello, thanks, and stuff

[Peter Hanappe]

Tim Goetze wrote:
> hi peter, hi all,


Hi Tim,

Welcome to the mailing list! I was abroad last week. I came back
and found a happy mailbox with a filled stomache. I'll try to work my
way thru all the messages and changes to the synthesizer!


> iiwusynth is great. thanks.

Thank you!


> after having started with the 0.0.6 tarball, i yesterday switched to
> CVS -- i think the CVS version should be turned into a tarball soon,
> because it's so much more usable (no more stuck notes in the first
> place, the -100 dB cutoff was a good idea).

I just uploaded a new tarball. It includes all the latest changes,
especially those of Markus Nentwig and those mentioned below.
I also boosted the version number to 0.1.




> there's still a couple of things i would like to see changed, please
> tell me if somebody is working on any of these, and if you'd like to
> see patches:
>
> * if IIWU_VERBOSE: use iwwu_log instead of printf -- the printfs
> clutter up stdout. i'm embedding multiple instances of the synth,
> and it would additionally be nice if there was a way to associate
> iiwu_log messages with a specific synth.

You're right. Done.


> * enum iiwu_log_level: prefix all with IIWU_ (IIWU_PANIC etc) -- the
> current enum names are provoking namespace collisions.

Absolutely. Done, too.


> * iiwu_synth_get_gain: missing this.

Easy and done.

> * IIWU_BUFSIZE needs to be queried to optimize code that embeds the
> synth. iiwu_synth_get_bufsize?

Good idea. For now you can count on the fact that the synthesizer
internally will always use 64 samples.


> some multithreading questions:
>
> * are iiwu_synth_program_change and fellows guaranteed never to call
> malloc, do blocking disk IO or other stuff that can cause a
> realtime thread to miss its deadlines?

It depends partly on the synthesizer and partly on the soundfont
loader.

The synthesizer only allocates memory when it is created. After
that it uses only pre-allocated memory. (This puts a restriction
on the number of modulators a preset can use.)

The default soundfont loader only allocates memory when a soundfont
is loaded. After that, no more allocs.

I'm well aware of real-time constraints and the synthesizer was
developed in that perspective.


> * if they aren't, is it safe to access the synth through these
> functions asynchronously from a different thread than the thread
> calling iiwu_synth_write_*, and will the output be 'smooth' while
> the program change is being worked on?

The synthesizer should be thread safe. True, it does not use any
synchronization mechanisms (mutices and such) to avoid
blocking the real-time thread. However, I don't think, in the current
state, the synthesizer will see any corrupt data. It might see stale
data.

For example, on a noteon, a voice object is initiated. At the end
of the initiation, a flag is switched to turn the voice on.
This flag is shared between the two threads and it is accessed
unprotectedly. However, it's not a problem is the audio thread thinks
the voice is off when actually it's in the process of being turned on. 
In that case, the audio thread will find the voice ready in the next
loop.

The only shared data between the audio thread and application threads
is the on/off flag and the synthesis parameters of a voice (the
synthesis parameters can be changed thru 'control change' messages).
As I said, the audio thread cannot see corrupt data, it might see an
update of the data one loop later.

The program change is completely independent of the audio thread.
Programs (or presets) are only used to construct a voice object
during a noteon event. After that, they are no longer used.

Your question made me wonder if the synthesizer can be accessed
concurrently by several application threads. I might have to add
an option to request synchronous access to the synthesizer public
interface (noteon, noteoff, ...)


> ... and some observations on which i'd like to hear your thoughts:
>
> my overall feeling is that iiwu is overly sensitive to note velocity,
> but that may also be a property of the soundfonts i use. anyways, i'd
> like to be able to specify a float mapping to compensate for this at
> runtime, rather than adjust the (integer) noteon velocity before
> passing it to the synth.

Markus fixed it! (Great job Markus. Classical piano examples now
finally sound good!)


> the output signal of iiwusynth with unadjusted gain is very weak; it
> never exceeds 0.125f with any soundfont i have. i rather
> expected it to max out at 1.0f.

Use the -g (or --gain) command line option, or the 'gain' command
in the iiwusynth shell. iiwusynth and iiwuplay don't use a compressor
internally. That's why the gain is set low by default.

> btw did i mention i like the synth a lot? ;)

Thanks again. So you said you were integrating the synth in your
application? Tell us some more about it!


Cheers!
Peter

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