denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] The 0.8.12 release


From: alex stone
Subject: Re: [Denemo-devel] The 0.8.12 release
Date: Tue, 22 Dec 2009 01:24:36 +0000

I have a build error with the latest git pull, including this code it seems:


http://pastebin.com/m2a78edac


Alex.

On Mon, Dec 21, 2009 at 10:19 PM, Richard Shann
<address@hidden> wrote:
> 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
>
>
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel
>



-- 
www.openoctave.org

address@hidden
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]