Re: [Denemo-devel] The 0.8.12 release

[Richard Shann]

On Mon, 2009-12-21 at 11:31 +0000, Richard Shann wrote:
> On Sun, 2009-12-20 at 23:30 -0600, Jeremiah Benham wrote:
> > es in the first tab that is opened in the preferences there is a
> > drop  
> > down for selection of portaudio, fluidsynth, or Jack. These do not
> > get  
> > saved and/or reloaded on restarting Jack. If a user only wanted to
> > use  
> > Jack audio out but wanted to leave the option open to use fluidsynth  
> > then it would be anoying for that user to have to select this every  
> > time. I can probably fix this easily. I will do that tommorow.
> 
> ok, but leave the jack ports/clients stuff. I can see what needs doing,
> it is quite deep structural changes needed. 
After many hours I have the basic structure in place. Note that you
cannot set the clients/ports using the Preferences dialog you have to
write them by hand into denemorc. They look like this (This would come
after <Config> in denemorc)

    <midi-devices>
      <device client="dmmemo">
        <ports>
          <port>midi_out</port>
          <port>midi_uut</port>
        </ports>
      </device>
      <device client="dxmmemo">
        <ports>
          <port>mxidi_out</port>
          <port>mxidi_uut</port>
        </ports>
      </device>
    </midi-devices>


where the strings "demmemo" "midd_uut" etc are just random names I put
in for testing. This example has two clients with two ports each.
There is a very large amount of commented out code (well #if0'd
actually).
And the job of generating new clients/ports is not completely trivial -
it will involve realloc'ing arrays.
But, it is ready for testing - I have seen it working, though sometimes
qsynth was receiving data but I heard nothing (I have alsa bridge in
there).

Jeremiah - you will want to know roughly what I have done:
        the basic problem is that a single global buffer for midi events
queueing to get out will not work. This is because you do not know which
client will request more events next. The solution I have used is
slightly odd, because the buffering is attached to the Denemo.prefs
structure ultimately, but it helps not to have multiple copies of the
client/port lists (these lists are intended to be basically fixed for a
normal use of the program). I have left the choice of the client and
port numbers entirely up to the order in which the names are entered
into the denemorc, so they no longer appear in the name strings (see
above).

Richard