RE: [iiwusynth-devel] iiwusynth

[Tim Goetze]

M. Nentwig wrote:

>-snip-
>
>> i'll probably try some digging around the sources now -- i'm already
>> working on the music with iiwusynth (!) and this feature is very dear
>> to me.
>
>Here's how I'll (probably) implement exclusive groups:
>In Iiwu_synth.c, iiwu_voice_noteon, the new synthesis process ('voice')
>is set up and running just before the 'return r' statement.
>Into the same file I'll put an 'iiwu_voice_noteoff_by_exclusive_group'
>function, which is then called at this point, if the voice has an
>exclusive group != 0. This will then change all other voices from the
>same group into release state.

i think it would be better to put any sounding voice from the same
preset / exclusive class into released state before / at the same
time with allocating the new voice. 

to illustrate why i think so: imagine the open hihat is sounding, and
some crash cymbals maybe, bass, strings and an organ; bringing us to
max polyphony. 

the hihat is to be closed now. your proposal would rather blindly cut
any one of the voices sounding to free a voice first. it would however
be much better to first put the open hihat into released state (we
have to do that anyway), so that when we ask for a new voice, the open
hihat becomes the natural choice for a voice to kill.

and i think you can't just kill by exclusive group -- you have to take
into account which preset the active voice belongs to, too. otherwise
if two presets define the same exclusive class, their voices will  
interact in strange ways.

now if i understand things correctly, this would mean that 
_iiwu_voice_t needs to be extended to remember which preset the voice
belongs to. but i may be wrong.

>Probably I'll have this on CVS by Thursday.

i'm digging deeper and deeper. could well be i have this done when
night falls on europe today. :)

>There are other related things that have to be addressed: For example
>retriggering of voices. I'm running out of polyphony, when playing piano
>(never with more than 10 fingers :-) and the upper register has no
>dampers.

you mean a noteon that meets with the same note already playing? is
the current behaviour problematic?

>BTW, I got a free 148 MB GM sound font, but the results are not very
>encouraging (to say it politely). I'm not sure yet, if it's the
>soundfont or the synth... I'll try the default sound font from Creative.
>
>Have you had any problems with clicks at noteon or noteoff events?

none whatsoever. bad loop points or DC offset in the samples?

or wait. if you have 148 MB of sample data, most probably the OS will
swap out some of your process' memory pages. now if you access a
certain layer of samples (by playing notes) that need to be swapped
in, the thread that does this memory access is suspended until these
pages become available again. this is a serious problem for realtime
code.

the solution is to provide enough physical memory, and to advise the
OS never to swap out your process's pages. on unix, you do this the
quick way by calling mlockall(2), and on a finer grain with mlock(2). 
a quick grep on the iiwu sources reveals no call to these functions.

>> did i mention the synth hasn't crashed yet? most remarkable. i'm all
>> enthused.
>
>Actually, if I think back I think i've never crashed it myself. Strange
>noises now and then, but I can't remember that I ever had a single
>coredump under 'ordinary' conditions. Peter has done a nice job, let's
>hope that I don't screw it up with my changes :-)

yeah, the sources are also easy to read. let's keep it like that. ;)

tim