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

[Tim Goetze]

Peter Hanappe wrote:

>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!

great to see you come back loaded with energy -- i just fetched mail 
to see that you have already done a lot of work tonight!

many thanks for fixing all stuff i mentioned. reading my statements
almost made me feel nitpicky ;)

[..]

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

that's ok.

[..]

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

yes, after having read more of the sources i see you clearly had that
in mind. excellent.

[..]

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

i think this is reasonably safe, i'd use the same construct. the
iiwu-embedding code here feeds all events to the synth in the audio 
thread -- it's plain simpler for nonce. however it's good that the 
option to separate events from audio to keep the audio thread 'light'
is intact. iiwu_defpreset_noteon can chew up a few cycles i bet. :)

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

that's really good to hear (also because it means i haven't misread 
the sources ;)

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

do you mean by supplying a callback that is called on loop start? 
that doesn't sound bad, and embedding code would not have to care 
greatly about bufsize, as long as it's ok to do events in the audio
thread.

[..]

> > 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!

only too happy to oblige, i hope i can make it short, but i fear i
can't ;)

it's my private quest for a near-perfect environment for musical 
work, for which i need hard disk recording, DSP, and full-duplex 
audio as well as recording, sequencing and transforming midi. 

all objects (aka plugins) needed for this work together in one 
flowchart (i call it a graph), and can connect in any number of 
ways -- well you cannot feed an audio input from a midi output, 
but if you stick one of these lovely IIWU plugins inbetween, you 
can. ;)

an important point, and the main reason for rolling my own in the
first place, is that all of the objects above interface with python, 
and that it is possible (though at the price of a delay on the order 
of a millisecond or three on this box) to use python for coding 
plugins as long as they don't do audio.

in fact, the application itself and most of the windowing will be 
coded in python, while all the lowlevel code sits in a python 
extension.

the graph and all of the audio and midi plugins i need are up and 
running in sync by now (with the exception of a ladspa plugin, but 
i already have code from an earlier go). apart from minor things, 
the only crucial functions still missing in the extension / library 
layer are seamless loops and better transport control than start /
stop only. 

i read about your iiwu_rt project with great interest, and i can
tell you that making python work well in such a multithreaded,
realtime environment is really, really hard. if python was written 
with the ideas you have in mind my coding life would be a lot less 
complicated. but thank god it's looking like i'll soon be able to 
turn to the simple pleasures of writing the 'real application' in
python, and the delights of coding graphics without at almost any 
statement first thinking 'is it safe to do this?' but rather 'does 
it look good?'

there you have it, i couldn't make it short, just as i thought ...

to get back on-topic: iiwu_chorus.{c,h} are missing from cvs. i'm
really looking forward to how your next commit sounds. :)

tim