[Denemo-devel] Jack midi structure.

[alex stone]

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

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, 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,
etc, but if the user has named the denemo ports, then other jack
clients will see "denemo:violins1 , denemo:violins2 , etc..."

This is the midi/jackmidi foundation of denemo, and doesn't change
(it's dumb, and always active, i.e. stable), unless the user
specifically makes the change in global preferences, in the "midi
device manager".

2.) Staves.

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 the staff has
a port, with 16 midi channels, and this is constant, unless the user
specifically changes it. The staff can ONLY output midi though the
specified port, and again, this keeps things constant across sessions,
and controllable "within' denemo.
In the Staff Port List, the user is presented with a further choice of
midi channels. This can be a list of integers, 1,2,3,4,5,6, etc, and
"all". This not only proves useful for using external sound devices
like linuxsampler, but is important for the internal synth too, as the
user can then specify a channel per staff, working within the
limitations of the internal synth's single port, and the consequent
maximum of 16 midi channels.

voices can be added and removed, as the user sees fit. This makes no
difference at all to the dumb midi port structure. It just sits there,
funnelling midi out.

3.) Internal Synth.

This is simply a constant default port inside the "Midi Device
Manager", connected to the internal synth. It appears, along with the
user created ports, in the Staff Port List, so effectively, it's just
another port to choose from.

4.) The ports can be used for any number of staves. So the user can
create, for example, a "woodwinds" port, and then use the same port,
but different midi channels, across their woodwind section.

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