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: Richard Shann
Subject: Re: [Denemo-devel] The 0.8.12 release
Date: Tue, 22 Dec 2009 14:51:11 +0000

On Tue, 2009-12-22 at 08:04 +0000, Richard Shann wrote:
> I've added the ability to add ports/devices via prefs dialog.
> A few other points
>       * only playback via jack is wired up, not the immediate playback
>         of notes when entered, scripted midi events etc
>       * no remove yet via prefs dialog, despite appearances.
I have added remove of devices, remove of indvidual ports is trickier;
also I am not clear how the assignment of numbers to devices and ports
is working out - let me know if anything is happening that is tricky to
manage.
Richard



> 
> I've also quietened the debug chatter, as I have some confidence now in
> it - I have had several staffs playing on different clients and ports
> for dozens of measures.
> Richard
> 
> 
> On Mon, 2009-12-21 at 22:19 +0000, Richard Shann 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
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel





reply via email to

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