Re: [Denemo-devel] The 0.8.12 release

[alex stone]

Still testing this, and trying to trip it up. So far so good. I've
built a little script that connects all my denemo devices and ports to
Linuxsampler automatically when the script starts up, and that's
working fine.  Project save and reload also works too, with port per
staff remembered across restarts.

Device and port creation is ok, as long as the user remembers that
each port must have a number too. Simply giving a port a name didn't
work.

The successful syntax seems to be:
device:0

<ports>
piccolo:0
flute1:1
flute2:2
altoflute:3

device:1

<ports>
oboe1:0
oboe2:1
english_hn:2

and so on...

Provided the numbering for ports within a device doesn't repeat, i,e,
flute1:0 flute2:0, then everything works, and frankly, i think this
format is pretty robust, as long as the user pays attention when
building any devices and ports.

I haven't updated yet, but i would say here the user is more likely to
want to add and remove ports, than devices, but i temper this with the
fact we can setup all devices and ports once, as a denemorc default,
and may not need to alter anything again.

6 of one, half a doz of the other, i guess.

more to come as i test further, but this really taking shape......

Alex.


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



-- 
www.openoctave.org

address@hidden
address@hidden