Re: [Denemo-devel] Jack midi structure.

[Jeremiah Benham]

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

> 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?



> and they are constantly active,
> with the same names each and every time, in other words, dumb. Outside
> of denemo, other clients see 'denemo_midi_out_1, denemo_midi_out_2,

Can they rename Jack1, jack2, etc.. I am not sure if clients can be  
renamed in Jack.

> 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?

Jeremiah

> 5.) Input.
>
> In an adjacent section of the Midi Device Manager, is "Midi Input
> Devices", and the same deal applies. The use creates an "input" port,
> and makes a selection from the jackserver list (jack_lsp capture
> clients) as to which input device is to be used. Again, this is saved,
> and appears when denemo is started.
>
> In conclusion.
>
> The biggest challenge with using Denemo, imho, is the convoluted
> nature of the current midi playback structure. I've offered the above
> suggestions as a way of creating a constant midi framework that is
> stable, always on, and with the same names for ports, etc..
> I also see this approach as not only a lot simpler than the current
> situation, but also "future proof", as the simple design is
> extensible, simply by adding new types of devices (portaudio,
> coreaudio, etc.. as an example). It separates, and demotes the staves
> from having outside world access, and makes the connect framework
> inside the app, definable, and for the user, easier to mange, and
> understand. This means the midi structure inside denemo itself is
> cleaner, and removed from making any specific midi driver coding
> requirement, outside of a generic structure. ( a midi edit is a midi
> edit, rather than a midi "portaudio' edit, and a midi "jackmidi"
> edit.)
>
> 1 base mechanism that can be used across architectures, and keeps any
> part of the app above the midi hub, the 'midi device manager', simple.
> Most importantly, the user doesn't have to figure out Csound
> derivatives, which /dev/midi device is the right one, etc...
> He just sees, and works with, the Midi Device Manager.
>
>
> Alex.
> --
> www.openoctave.org
>
> address@hidden
> address@hidden
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel