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

[Tim Goetze]

Josh Green wrote:

>Sounds like a rather ambitious project :) I've been wanting a real time
>MIDI composition environment in Linux for quite sometime now, is this a
>goal you are shooting for with your application? I've been entertaining
>ideas of making one myself, but I'm starting to feel like I'll never get
>around to it. If you are already doing something like what I have been
>wanting, it would be much easier to help out then to start something new
>;) Have you thought of a name yet? I was thinking of calling my project
>Dream Sequence, although I wouldn't mind if this name was used for your
>own. Although it sounds like what you are doing is more than just a
>sequencer. Lates.

yes, it sometimes feels almost too ambitious (but otoh it'd be boring
if it was easy ;) and yes, i want 'realtime' composing to be (it
already is, in a way) possible to do with it.

script plugins are run in a separate thread that is woken when they
receive data. this has two consequences: first, there's the delay i
mentioned, and we cannot make any guarantee about the length of this
delay so it's at best what they call 'soft' realtime. in addition,
if memory needs to be allocated (and simply calling a python function
necessitates this) this thread may be suspended for up to another few
milliseconds.

thus you may need to emit events 'in advance' if you're keen on
achieving the best possible timing. currently, with no gui code to
hold the big python lock, i'm using an admittedly simple script plugin
for mapping live midi input with no major timing problems though.
i'm confident that even with a gui, and more python code, the timing
will remain acceptable because earlier experiments have indicated this
to be the case.

second, an alternative method of waking up script plugins in a
periodic fashion needs to be implemented. i'm tending to provide
'timer' or 'pulse' plugins for this purpose that emit events at
periodic intervals or at certain beats within each bar, so we can
simply employ the current mechanism rather than implement this in the
processing core. it's just a few bytes harder on memory but overall
more flexible, and probably a tad quicker to execute, too.

i haven't yet named this thing; i'm a bit anxious that a name will
have too much influence on my mental picture of it, and thus restrict
development possibilities. the working dir goes by the name of
'motion' in the meantime.

and i'm afraid all of this is really off-topic for the mailing list,
but i find it very hard to stop myself from babbling about it. just
tell me to shut up, or to take this off the list. ;)

tim