denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Denemo-devel] jack midi suggestions part 2.


From: alex stone
Subject: [Denemo-devel] jack midi suggestions part 2.
Date: Sun, 8 Nov 2009 20:07:22 +0300

I'm including the relavent irc chat for further reference to my jack
midi denemo framework suggestions:

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


21:00 < alekz49_> the challenge of providing some sort of jack format
is going to be interesting. On the one hand
                  you'll have plenty of soundfont users, who will use
the internal synth, and on the other, you'll have
                  chaps like me, who don't need any sound device in
denemo, but instead require the mechanism to
                  manipulate staffs by multiple channels, inside of a
port per staff, to run big sample libs in LS, or
                  other device.
21:01 < alekz49_> so one use case is a channel per staff, and the
other is a port per staff.
........................................................

21:15 < alekz49_> steele^: on the topic of jack, it may be worth
checking out the structure of linuxsampler, with the
                  ability to add devices. It works well, and maybe
that's a consideration for you chaps as well.
21:19 < alekz49_> steele^: so the user adds devices, and then
"allocates" them to staves, in much the same way as LS
                  uses channel strips. (i.e. One denemo staff = 1 LS
channel strip)
21:19 < alekz49_> steele^: 2 roubles worth anyway.
21:19 <@steele^> alekz49_: I know the linuxsampler structure. One
device=1 port. But Denemos 1 staff -  1 port is fully
                 compatible with this. And you can of course choose
the same port for multiple staffs.
21:19 <@steele^> the devices are already there, one could say.
21:19 <@steele^> or at least planned
21:21 < alekz49_> steele^: ok, but the problem is the ports only
become active when staves are added. I'm suggesting
                  taking the ability to create ports back one step, so
they can remain active, rather than constantly
                  appearing and disappearing. It makes it very hard to
build a large template, and deal with the
                  constant connect/disconnect.
21:21 <@steele^> alekz49_: ok, i'll write that down
21:22 < alekz49_> steele^: so in the initial preferences, the user can
"create" ports, and name them, and every time
                  denemo opens, the ports are created, named as
specified by the user, and they sit there, waiting to
                  be allocated, or not, to a staff.
21:23 < alekz49_> steele^: in other words, the ports are always open,
and always the same name, as specified by the
                  user in global preferences.
21:25 < alekz49_> steele^: then the midi "structure" is setup, and
running, and it's the staves that are connected or
                  disconnected.
21:25 < alekz49_> steele^: brb.
21:27 <@steele^> alekz49_: but how can you work with ardour? it has
the same "problem" ?
21:28 < alekz49_> steele^: i use ardour for audio, and it "remembers"
the port names, etc..
21:30 < alekz49_> steele^: i use templates in ardour a lot, and it
defines and connects the template designated ports
                  when it starts up. Different use case to working
with midi in a notation app.
21:32 < alekz49_> steele^: it's my view all you chaps need is a
"device manager" in preferences, set the number of
                  ports, and name them, then that's what gets enacted
when denemo starts. The staves "lose" their
                  ability to connect to the outside world, instead
being connected only to the list of devices the user
                  spcifies in the device manager.
21:32 < alekz49_> steele^: so the stave popup shows the list of ports
available, and you pick one.
22:01 < alekz49_> steele^: sorry, disappeared for a moment. How does
this sound as an idea to simplify the process in
                  denemo?
22:04 < alekz49_> steele^: you would have 1 internal port in the
device list that is there all the time, for the
                  internal synth.
22:06 < alekz49_> steele^: incidentally, the linuxsampler setup is not
1 device = 1 port. You can setup a device, and
                  nominate as many ports as you want for that device,
and name them.
22:07 < alekz49_> steele^: i have 2 devices in my usual template, each
with about 36 ports, all named by me. That is
                  saved with the template, and it makes it easy to
build connections that automatically reconnect when
                  the app is started.
22:18 < rshann> alekz49_, steele^ I am working in the same room as my
computer - it looks like you are getting close to
                a spec
22:19 < alekz49_> rshann: what's your view on this?
22:30 < rshann> alekz49_, it's outside my field - it sounds like what
you want will only be a minor task, if you can
                describe it in terms that Jeremiah understands
22:30 < alekz49_> rshann: ok.
22:31 < alekz49_> rshann: I'll post a mail in the list, shall I?
22:32 < alekz49_> rshann: or would you like to talk to him about it first?
22:47 < rshann> alekz49_, Add a page of design notes to the denemo.org
wiki, if you are familiar with that technology,
                otherwise just email to the list
22:47 < rshann> the main thing would be to think of it from the denemo
end - what are the staffs/voices supposed to
                output to in terms of jackmidi calls
22:48 < rshann> (here I stray from anything I am familiar with, but I
see "port create" and things like that ....)
22:48 < rshann> something like
22:49 < rshann> when a new voice is created do xxx in the jack side
22:49 < rshann> when one is deleted do xxx
22:54 < alekz49_> rshann: as far as staves go, they react according to
what you specify. If you remove a voice, it
                  makes no difference at all to the "dumb' connection
the stave has with the jackport specified.
22:54 < alekz49_> rshann: if you add a voice, it's still using the
same port you've specified as the dumb connection in
                  staff preferences.
22:55 < alekz49_> rshann: remembering that each port is capable of 16
midi channels.
22:56 < alekz49_> rshann: the jack devices are one level below the
staff level. They are fixed, and constantly active.
                  They are, in effect, "dumb' ports.
22:57 < alekz49_> rshann: so you could create a device called "jack1"
in the device manager, and for that device,
                  create 16 ports, each with 16 midi channels.
22:57 < alekz49_> rshann: when you go to the staff port preferences,
you see the 16 ports you created, in the jack1
                  device.
23:00 < alekz49_> rshann: the user chooses a port for that staff,
let's call it "violins1". That staff now has 16 midi
                  channels available to it.
23:01 < alekz49_> rshann: the important part of this is, the staff no
longer has access to the world outside the app.
                  It now only sees the ports specified by the user in
"Denemo midi device manager", located in global
                  preferences.
23:04 < alekz49_> rshann: and with a "denemo midi device manager" you
gain an important step forward. When denemo is
                  opened, and the global preferences are "read", the
device and ports are created, and remain
                  constantly active, retaining the same names you
allocate, per port.
23:06 < alekz49_> rshann: this makes is easy to reconnect to the same
ports across sessions, so a Cello port in LS, for
                  example, will always be connected the
"cello_midi_out" port in the denemo midi device manager, which
                  will be fed midi from the Cello staff, for which you
have allocated the denemo cello port.
23:09 < alekz49_> rshann: so what sort of devices do we want? if you
want to cater just to jack, then jack it is, and
                  you simple create jack0, jack1, etc.. each one with
the number of ports you create, all named by the
                  user for continuity.
23:10 < alekz49_> rshann: as each device is added, the integer increases.

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

Alex.

-- 
www.openoctave.org

address@hidden
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]