Re: [Denemo-devel] Jack midi structure.

[Jeremiah Benham]

On Sun, 8 Nov 2009 19:18:03 +0300
alex stone <address@hidden> wrote:

This sounds like a good idea. Is the "midi device manager" dialog a
separate window like score wizard or is a tab in preferences?

Jeremiah


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