Re: [Denemo-devel] Jack midi structure.

[alex stone]

On Wed, Nov 11, 2009 at 10:12 PM, Jeremiah Benham
<address@hidden> wrote:
>
>
>
>
>
> On Nov 8, 2009, at 10:18 AM, alex stone <address@hidden> wrote:
>
>> After having a chat with Nils and Richard in IRC, i'm offering the
>> following as a suggestion for the jack midi framework in denemo.
>>
>> At the moment, staves in denemo connect directly with the "outside
>> world". This creates a challenge in large, fairly static setups with
>> additional apps, sound creation apps like linuxsampler, aeolus, etc.,
>> as ports are constantly connecting and disconnecting, according to the
>> state of the staff.
>>
>> So, the suggestions:
>>
>> 1.) create a "dumb" structure, called "midi device manager".
>>
>> In this structure, the user creates devices. We're dealing with
>> jackmidi here, so the devices are called "Jack". As a new device is
>> added, of the same type (jackmidi), it gains an integer, so the device
>> manager would now have Jack0, Jack1, Jack2, etc..
>> For each device, the user then adds ports to his requirements. If he
>> wants ten ports, then they are created for the specified device. We
>> choose Jack0, and create ten ports. The user then names those ports,
>> according to his requirements. Violins1, violins2, etc...
>
> Should there be a different Jack client corresponding to Jack1, jack2 etc...
> Or does Jack_lsp not see that? I ask because you mentioed adding ports to
> Jack1 etc... Or is this a way of orgazing instruments inside denemo?
>
> So if it was a seperate client for each jack1, etc we would see in qjackctl:
>
> Denemo:jack1
>  midi_out_port1
>  midi_out_port2
>  midi_out_port3
> Denemo:jack2
>  midi_out_port1
>  midi_out_port2
>  midi_out_port3

....................................................................


Jeremiah,

jack_lsp will only see the ports. So the first device would appear in
jack_lsp as something like:

denemo0:midi_out_1
denemo0:midi_out_2
denemo0:midi_out_3

Then the next device:

denemo1:midi_out_1
denemo1:midi_out_2
denemo1:midi_out_3

and so on.

If the user names the ports to correspond with his orchestral
intentions, then the ports could be named something like:

denemo0:1st_violins
denemo0:2nd_violins
denemo0:violas

and so on......

denemo1:piccolo
denemo1:flute_1


and so on

devices can have as many ports as the user wants, and the user can
have as many devices as they want.


Jack_lsp should only see the ports, not the devices, as described
above, but, as you can see, the integer next to "denemo" changes, to
reflect the device number. So the syntax seems to be app name with
midi device integer identifier, then colon, then port name.  The
device is acknowledged but not displayed as a separate "port."



..........................................................................................




>
>>
>> This is our midi base or foundation, and is dumb. When denemo is
>> opened, and the global preferences file "read", these user built and
>> specified devices and ports appear,
>
> So these "device configurations" are to stored in denemorc? They are not a
> seperate device template file?
>

..............................................................................................





It's my view the device and ports preferences should be stored in
denemorc. however i'm not a coder, so it would be worth keeping this
in mind. I see it as a means to keep all preferences in one spot.
If something goes wrong in denemo, or with an external
connection,where the user is required to tweak, or remove a
troublesome device, then they can head straight to .denemorc, and
comment it out, or remove it. In addition, as i wrote before, it's a
lot easier for the user to have 1 tab for "all things midi", and
putting the midi device settings in denemorc could be viewed as a
consistency, if you get my drift.

Clients usually retain their names in Jack, but ports can certainly be
renamed, if the application allows this.




>> Remove from the staves the ability, through current preferences, to
>> connect to the outside world directly.
>> Introduce a "Staff Port List", in which the staff finds the
>> devices,and associated ports, specified in the global "midi device
>> manager.", described above. The user creates a new staff, goes to the
>> Staff Port List, and chooses a port for that staff.
>
> Now I assume you are talking about the staff properties here. Am I correct?

.........................................................................................


Yes. The staff port list is a component of staff properties. (that's
my suggestion, anyway.)



Alex.






-- 
www.openoctave.org

address@hidden
address@hidden