Re: [Denemo-devel] Jack midi structure.

[alex stone]

Jeremiah, A tab in preferences would probably be better. (Once we
setup devices and ports, it's not something we're going to use all the
time.)

I was thinking further on what i wrote, and caught another "feature'
of this, as a bonus.

Even if the user creates more devices and ports than they need, it
wouldn't matter. So the user might setup a device with 24 ports, but
only use 18 of them for a particular piece. That's ok. The ports are
all still open waiting to be used, and being dumb, they'll just sit
there, with no consequence of any sort.

and of course, should you choose to implement this, it will enable the
removal of quite a few of the other preferences items that seem a bit
cluttered at the moment. 1 tab, and that's it.

Alex.

On Sun, Nov 8, 2009 at 9:31 PM, Jeremiah Benham
<address@hidden> wrote:
> 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.
>
>



-- 
www.openoctave.org

address@hidden
address@hidden