[PlanetCCRMA] help getting netjack MIDI working? (looks like it's working, just doesn't send data)

Niels Mayer nielsmayer at gmail.com
Sun Mar 7 21:05:30 PST 2010


On Sun, Mar 7, 2010 at 5:58 PM, Al Thompson <biggles58 at sbcglobal.net> wrote:

> I've given up for a while.  I asked about the same question as you in a
> couple of different forums, and got no response at all.  Either nobody
> is trying to do this, or nobody has succeeded.


Some clues from #jack IRC below...

summary -- we're missing an ALSA<->JACK bridge on the "slave" side. The
slave side is sitting there talking to netjack ports not connected or
bridged to the ALSA devices in any way.
(1) For MIDI only, use:
http://ccrma.stanford.edu/planetccrma/man/man1/aseqnet.1.html
(2) Alternately&&more complicated, if using netjack, must also bridge midi
to jack with
http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/12/x86_64/repoview/a2jmidid.html

Unfortunately, planetccrma version is obsolete, version 6 from GIT is
current/stable version.
(3) Audio also requires an ALSA<->JACK bridging too, like alsa_in and
alsa_out on the slave-side netjack.

(10:47:50 AM) npm: is there a way for jack to access midi ports on a
different computer (e.g. run jack on comp A w/ midi devices <--> comp B runs
jack and accesses MIDI on comp A)
(03:18:45 PM) las: npm: netjack will distribute MIDI. you're on your own
trying it out ....
(03:44:37 PM) torbenh3: sill think aseqnet is more appropriate if you only
want to transmit midi.
(03:49:08 PM) las: torbenh3: a good point
...
(07:32:42 PM) npm: las, torbenh3 thanks for suggestions on netjack and
aseqnet: anybody provide help w/ netjack -- this is as far as I got
http://old.nabble.com/help-getting-netjack-MIDI-working--(looks-like-it's-working,-just-%09doesn't-send-data)-ts27815119.html(other
planetCCRMA respondents are having same problems w/ netjack on fedora
12)
(07:44:08 PM) torbenh3: npm: these descriptions are pretty vague.
(07:45:17 PM) torbenh3: npm: it looks like it works.
(07:45:31 PM) torbenh3: npm: anyways... if you only want to send midi, use
aseqnet.
(07:45:46 PM) torbenh3: thats a lot easier to use.
(07:46:15 PM) torbenh3: and your use-case is not exactly whats netjack
targeted for.
(07:46:50 PM) torbenh3: the post talks about patching not working. what are
you trying to patch ?
(07:47:39 PM) torbenh3: without running a2jmidid on the slave, you wont get
midi data into the slave jack graph anyways.
(08:22:03 PM) npm: torbenh3: 'the post talks about patching not working.
what are you trying to patch' --> i'm simply trying to access a midi synth
keyboard connected on a difft computer's USB/midi intfc, so that i don't
have to string a long MIDI cable across the room and wear out the midi ports
physically plugging and unplugging equipment
(08:22:39 PM) npm: i basically just want to access the USB midi device
remotely somehow
(08:25:23 PM) npm: it the part about needing to running a2jmidid ... rings a
bell: so on the slave, i need to run a2jmidid -- when i poked around using
'patchage' it appeared that on the slave side the netjack was sitting there,
but not talking to any devices. so a2jmidid is needed to connect, on the
slave-side between the alsa midi device (usb midi intfc), and 'jackd -net'
running on the slave side?
(08:32:59 PM) torbenh3: npm: what about "USE ASEQNET AND NOT NETJACK" is so
hard to understand ?
(08:33:44 PM) torbenh3: npm: but yes. you would need a2jmidid
(08:34:03 PM) torbenh3: but for what you want to do, aseqnet is a lot
easier.
(08:34:40 PM) torbenh3: netjack is for audio and sample synchronised latency
compensated midi transmission. you dont want either of these things.
(08:35:54 PM) npm: torbenh3: thanks
http://ccrma.stanford.edu/planetccrma/man/man1/aseqnet.1.html is exactly
what I need and then i don't need to worry about bridging jack->alsa
(08:36:30 PM) torbenh3: i said that 5 hours ago, and las confirmed it :)
(08:37:08 PM) npm: i was doing other things and finally had understood
asqenet was better soln
(08:37:49 PM) npm: but also, i was unable to get audio working either (even
though qjackctl or patchage indicated connections had been setup)
(08:38:25 PM) npm: is there an audio bridge akin to a2jmidid also needed to
bridge audio on the slave-side?
(08:38:26 PM) torbenh3: i doubt, that you had soundcard ports showing up on
the slave.
(08:38:33 PM) torbenh3: alsa_out
(08:38:50 PM) torbenh3: run alsa_out and/or alsa_in on the slave.
(08:39:24 PM) torbenh3: npm: saying patching doesnt work implicates
something different from there is nothing i can patch to.
(08:40:39 PM) npm: well the connection showed up in qjackctl and patchage
... it's just that no midi data flowed. but now it's clear that w/o a bridge
for the midi on the slave side, it wasn't actually connected to anything
(08:41:10 PM) torbenh3: how can the connection show up, if it not connected
to anything ? i dont understand.
(08:41:19 PM) npm: so the patching probably did work, i just failed to fully
understand what was going on on the slave side
(08:41:31 PM) npm: it showed the netjack socket being connected
(08:41:43 PM) npm: along w/ whatever ports it said it had connected
(08:41:55 PM) torbenh3: unless you start some bridges. you only see the
network ports. you were probably looping data back to the master.
(08:42:27 PM) npm: and on the slave side, i saw those same netjack ports,
not talking to anyting.. and that's when i fully understood your statement
about aseqnet and/or a2jmidid
(08:43:12 PM) npm: so thanks for enlightenment
(08:43:30 PM) torbenh3: ok :) trying to find out, whats wrong the docs. i
guess somebody needs to make some of these points clearer.
(08:44:07 PM) npm: yes, definitely. note the response to
http://old.nabble.com/help-getting-netjack-MIDI-working--(looks-like-it's-working,-just-%09doesn't-send-data)-ts27815119.html--
another person w/ same problem
(08:44:40 PM) torbenh3: yeah. i guess he has the same problem. i am not on
that mailing list though.
(08:44:49 PM) npm: i'm pasting this conversation as response to the mailing
list. Ok?
(08:44:57 PM) torbenh3: sure.
(08:45:00 PM) npm: thanks
(08:45:24 PM) torbenh3: but maybe he wants something different.
(08:45:56 PM) torbenh3: basically. if your mididata comes from the master.
and audio should get back to the master. netjack is the way to go.
(08:46:10 PM) npm: yes he wants the second solution you gave w/r/t alsa_out
alsa_in
(08:47:05 PM) torbenh3: note that alsa_out in jack 0.116.x is not really
good. it works a bit. but its pretty bitchy.
(08:47:16 PM) npm: so running a softsynth on the slave, taking midi from
master, outputting audio back to master, is a proper use case, correct?
(08:47:28 PM) torbenh3: yes.
(08:47:46 PM) torbenh3: with a2j you can feed midi from anywhere though.
(08:47:59 PM) npm: well that's a future experiment for me... that and
figuring out a2jmidid
(08:48:46 PM) torbenh3: but having 2 run 2 different deamons, is a bit
annoying. since the really good a2j version is only available in git iirc.
(08:49:41 PM) torbenh3: a2jmidid will make all midiports available in
jack... much like -Xseq but since thats an option of the alsa driver it
doesnt work with other drivers.
(08:50:11 PM) npm: planetccrma seems to do a good job of keeping the latest
and greatest around for fedora... will look into what they have
(08:51:12 PM) torbenh3: looks like a2jmidid releasee 6 is good.
(08:51:42 PM) npm:
http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/12/x86_64/repoview/a2jmidid.html
(08:52:22 PM) npm: they use 5. i guess it's time to update...
(08:52:24 PM) torbenh3: i just checked. not sure about that version.
(08:53:49 PM) torbenh3: hmm... seems version 5 will stop working or crash
after some number of midi events transmitted.
(08:54:24 PM) torbenh3: if you experience that, you need to update.
(08:56:03 PM) torbenh3: just looking at the commit logs. so i am not 100%
sure. but my bug fixes are between 5 and 6. and the code i fixed seems to be
in v5

-- Niels
http://nielsmayer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100307/2757ae00/attachment-0001.html 


More information about the PlanetCCRMA mailing list