Yes. It makes for an interesting concept. The recipe structure is much nicer. I will add a install midi network. script there to install multimidcast 1.3.
I will add a midi network system component that will run multimidcast but do I script the start up that enables that based on the current midi configuration settings to run the system to process or do I let system run a script that only runs if midi networks enabled?
I still need to be sure a2jmid is up and running as a system component and then map the midi channels
1 Like
Hi @wyleu!
I moved your comment to this topic that is best suited 
Regarding “multimidicast” package … it’s not maintained anymore and doesn’t support jack midi, so it must tunneled with a2j, what is not optimal.
Why not using the qmidinet package (https://github.com/rncbc/qmidinet)? It’s active project with a strong developper (rncbc) behind it …
Regards,
Cos it won’t run headless. I use it on my Linux laptop
Let’s do it work headless 
It shouldn’t be a hard task …
Regards,
At the end of the day it provides a net pipe connected from the jack environment to the iPhone network. Now do we consider WiFi or wired and how it fails. Cos it will.
It’s the reconnection side of things that needs setting up. If the zynthian.org goes down you shouldn’t loose your midi net I’m sorry this is from a phone and auto correct has strong opinions…
Stop press qmidinet claims a headless mode from 0.2.1 so much for my research…
Ok qmidinet looks like a lot better option. However can we install it without all the qt stuff that we don’t want to use?
Doesn’t look like it.
~54M.
I’ll see if I can build it with it just to see what I can get.
Putting qmidinet on . . .
Installed Qt5 components ( sudo apt-get install qt5-default)
Builds ok, can’t seem to run it. starts
on -gj (headless, jack)
but don’t see anything in aconnect -lo
or indeed qmidinet --help
Not sure it’s doing anything . . .
I need permission to push my branch to zynthian-sys . . . if that’s what I should be doing.
Branch called multimidicast . …
contains two files in pending recipes:
Here’s install_multimidicast.sh
# multimidicast
cd $ZYNTHIAN_PLUGINS_SRC_DIR
wget http://llg.cubic.org/tools/multimidicast/multimidicast-1.3.tar.gz
tar -xvf multimidicast-1.3.tar.gz
cd multimidicast-1.3
make
rm multimidicast-1.3.tar.gz
cd ../..
Couldn’t find an example of working from a .gz . . .
Once we’ve got the code down. We need the systemd start up component, which was a file from above. midi-network.service
[Unit]
Description=MIDI Network
After=networking.service
Wants=networking.service
[Service]
Environment=HOME=/root
WorkingDirectory=/root
ExecStart=/zynthian/zynthian-sw/multimidicast-1.3/netstart.sh
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.targetI tried this.
qmidinet --no-gui --jack-midi=1 --alsa-midi=0
and it worked OK 
Better create a pull request … but let’s use qmidinet, please
Regards
OK qmidinet: got it going this morning.
Keep trying to fork /zybtnian/zynthian-sys . . .
This is probably why. Not sure how to sort it out. . .
I REALLY don’t like git . . . 
I have a fork of zynthian-sys in my wyleu\zynthian-sys . . .
I pull the latest master to my local zynth…
I set url to wyleu/zynthian-sys
git checkout -b midi-net
make changes
git commit -a -m ‘dfdfgdf’
git push
Already up to date
No change on wyleu/zynthian-sys. . .
Flurry of hopeless copied git commands …
Am I about to write out my service script for about the tenth time…?
Sure, that you git add the modified file?
Sometimes it tells you the additional git push parameters that ensure that you push to that branch. I am “offline” right now, so that I can’t tell you the exact parameter.
I can see my edit in git show & it’s in git log . . .
Using 4 ports as a default number to qmidinet . . .-n=4
Not even dared turning wifi on yet. All over wired.
did you try
git push --set-upstream origin midi-net
Right I now have 3 zynthian-zeros (yeah I know …) with the same version of midi-net zynthian-sys.
First observations.
1/ Knowing which machine you are on is hard!
We need a strong visual clue to which zynth is which, and I would suggest we allocate colours to each other machine we see on the network. (user defined, ). If we are to do this this colour ( or shade for monochrome) ) should appear on the web conf interface, even if it’s just colouring the wiggle line in the middle of the zynthian logo in the top left conner of the display.
The colour of text in the webconf might track this as well but we are then trying to operate across a default white environment versus a default black one, and that is a debate for what is a magnificently presnted user interface.
2/ The HDMI common interface, whilst suitable for an attached monitor( frequently a life save in set up hell), tends to enforce dubious defaults onto Xwindows presentations.
If you want a lot of zynth’s up on screen at once, you would want to set an hdmi remote display option that is independent of the hardware display.
3/ Network address layer. ON MIDI startup. MIDI network channel in and out get routed to MIDI network in and out if network is enabled ( I’d love to know how the filter rules get channeled into the engine, cos I still think we should have a channel that can drive the interface entirely from MIDI commands, so we can entirely spoof the control interface across a MIDI network)
These connections want to be come infrequently changed defaults.
If we want zynthA to control zynthB, zynthB needs to select the qmidinet ‘channel’ appropriate to zynth A and it would help sanity a lot if zyntha a tended to be in the same place.
So how do we map?
I look at MIDI rules with envious eyes ( and minimum effort in mind).
Could we extend the parser to accept a (defaulted) MIDI NETWORK CHANNEL.
I notice the MIDI channel selected makes it throu’ into the lcd display in the Layer display, With a hash. How about a € for network channel followed by a 0-9…?
If that is the case could the MIDI rules set up the MIDI network routing?
So different settings are nothing more than filter rules.
Then we don’t need to write a whole new lcd page to config, it and once dialect is established we can implement the simplest interface then.
Just thoughts, apologies if they seem laughably mundane.
Your issues seem to be quite specific for your usecases and I am not sure, if other ppl would be having the same.
We need to get qmidinet to master step by step, so that other ppl - like me - can test it.