 |
||||||||||||||
|
Network MIDI TouchDAW implements two well established network MIDI standards:
Despite the tab standing under a WiFi icon, 'Network' generally refers to all kinds of IP networks, be they wireless or wired.
Known potential issue: Android may start the underlying MidiService with the wrong user profile when running under a secondary account, making all 'Network MIDI' functionality unavailable to the app. Please use the primary admin account.
RTP 
RTP MIDI along with the system Apple created around it in their original implementation (see Sound-On-Sound article on the MIDI Network in OS X Tiger) defines a system of network nodes - called 'Sessions' - that can actively connect to other such nodes or be connected to from others. The side that kicks off a connection process by 'inviting' another peer is referred to as the 'Session Initiator'.
A 'session' effectively just combines an open network port with a virtual MIDI port. The MIDI port is made available to DAWs and other MIDI programs on the machine that created the 'session' while the network port allows other devices on the local network to send MIDI to those programs without requiring further MIDI hardware like interface boxes, 5-pin DIN cables or equivalent. RTP MIDI sessions are bidirectional, providing both input and output. They can also deal with multiple network connected clients. In the end you can imagine them as smart virtual interface boxes with built-in merging and splitting functionality. They will neither collect dust nor will they create cable clutter and you get them 'for free'. If you need more ports on the PC, create another session. TouchDAW by default creates two such 'sessions' - one for each of it's two MIDI ports - and announces their existence on the local network via mDNS (aka 'Bonjour').
Before you can do anything with these 'sessions', you will need to set up their computer-side counterparts. How that is done is explained in the quickstart guide and will not be repeated here.
Making TouchDAW connect to a PC's sessions
While the quickstart explains how to connect to TouchDAW from a computer, you can also make the app actively connect to that computer. In the end this will probably be what you want, because you then do not need to open the drivers' control panels anymore and things will just get hooked up the moment you launch the app. I do believe that doing as described in the quickstart provides a better introduction to the system, though and I also can not make assumptions about what sessions you will want the app to connect to, so this is not the default setting. 
Same as the app's sessions will be seen by your computer, the app will also see the ones created on the PC. These 'remote sessions' will be displayed as shown on the left. The indented entries in the list are sessions that have been created by PCs on the network.
Listings in the dialog are generally 'live'. When additional peers come online or present ones shut down, it should be reflected 'shortly'.
When you select one of these entries you instruct TouchDAW to invite and connect the 'remote session' when it starts (resp. after you leave the setup at this point). The app will act as the 'Session Initiator' and you do not need to poke around in the computer side control panels to click the 'Connect' button anymore. If you do take a look at them however you will also see a 'tdaw (and_XY) RTP...' entry in the 'Participants' listing of the invited session: Apart from the first step things are no different and will work the same regardless of who kicked off a connection. Note that the enclosing 'RTP' entry will always get activated along with selecting a 'remote session' if it wasn't already checked. Touching the indention space before a remote session will show its IP address and port. This may be helpful if you run into a situation where multiple sessions have the same name.
Remote session entries are the only ones that are not mutually exclusive. You can let the app connect to more than one remote peer if it makes sense for you.
Should a selected remote session not be available immediately when the app launches, TouchDAW will by default keep trying to connect it. In case an established connection breaks (which might happen because of network problems or because the remote side shuts down) the app will try to reestablish the link. This behavior can be disabled by unchecking the 'Reconnect Remote Sessions' option in the network preferences. See next topic and screenshot. Manually defining remote sessions
There are scenarios where multicast DNS will not be available to advertise and discover sessions. If you run TouchDAW on some kind of PC-side emulator for example, no multicast traffic will usually reach the virtual network interface of the containered operating system. Resource limited embedded systems may support RTP MIDI but not implement mDNS etc. 
To provide the app with information on where it can connect to in such cases, you can manually define 'remote sessions':
To do so touch and hold the network tab's WiFi icon. Dialog contents will then change to what is shown on the left. Here you can either create new 'remote session' entries or edit those you may have already created. Enter a session name and its network address as shown by the hint text in the textfields and touch that 'floppy disc' icon to save things. When an already present definition is selected from the dropdown menu there will also be an option to delete it. To exit the page (short) touch the WiFi icon again. Manually defined sessions will show up in session listings with a preceeding dot like: ● My Session Once defined they can be selected for connection like any other 'remote session'. Multicast / ipMIDI
ipMIDI has been around since 2005-2007 on Windows, Linux and OS X. There are hardware products from SSL, Rupert Neve Designs and others using it and some Linux rooted DAWs (Mixbus & Ardour) come with built-in driverless support for it. 
ipMIDI is a connectionless system. It defines a number of multicast addresses that whoever wishes can listen and send to. None of the clients hooked into such a multicast group will know much about each other. There is no time synchronization, session management or over-engineered recovery system. It is completely 'fire and forget'. Potentially very easy to use and ideally working very well. It can however also easily result in data reaching endpoints that it was not intended for.
To use multicast MIDI with TouchDAW download and install ipMIDI for Windows or macOS (paid with a free demo mode) resp. multimidicast or qmidinet for Linux (both free). These are NOT needed for driverless DAW controller use with Ardour & Mixbus Launch the drivers' control panel and raise the number of ports to a minimum of 4. On Windows you can also use mnet / MIDIHub which is preconfigured to match TouchDAW's settings. TouchDAW by default will use separate ipMIDI ports for in- and output. That is to ensure there will only be one sender per multicast group (If you use multiple controllers, their data will only flow into the DAW and not also from controller to controller). The default routing is as follows:
It is equally possible to run input and output over a single port (and Mixbus / Ardour will insist on it to use their SSL Nucleus preset): When the Multicast option is selected you will find two dropdown menus underneath the main list that can be used to set input and output ports. Set them to the same port to run connections over a single port. If you prefer to see the raw ipMIDI port numbers instead of 'ipMIDI 1' etc. touch and hold the Network button. The network options contain a checkbox to change the display format. Ethernet, Hotspot, Tethering
Both RTP and Multicast MIDI will usually run on a device's default WiFi interface. In most cases this will also be the only network interface available. You can generally also run them over other network adapters, though. 
Additional interfaces may become available if
Interface names depend a lot on chipsets, manufacturer preferences, Android version etc. TouchDAW does not attempt to categorize or label things here. To provide some hints: Wired ethernet interfaces will usually be named 'eth...'. 'rndis...' is related to USB tethering. 'p2p...' would be a WiFi-Direct interface. Recent Android devices running Android 10 or larger will usually bring up an extra interface for WiFi hotspots (Often named 'wlan1' or - on Samsung devices - 'swlan0'). Older systems mostly reconfigure the default adapter and do not bring up another interface. When you select an alternative adapter TouchDAW will store it as a preference, but will automatically fall back to the default WiFi interface if the alternative one is not available. The next time the corresponding option (tethering, hotspot...) is activated, the app should use the stored alternative again without requiring it to be reselected.
Apple makes it hard to tether macOS to an Android device. USB Tethering requires the horndis driver. Unfortunately the project seems to have been abandoned and currently (July 2022) won't install on latest macOS versions and ARM macs.
Dynamic network switching Same as with USB-MIDI ports, if you have configured a USB network connection (tethering or ethernet adapter) and the network is not available when the app starts, TouchDAW will fall back to WiFi and will try to switch to the preferred network when it becomes active. This behavior can be deactivated in the network options (long-click the tab header). With USB ethernet adapters or MIDI interfaces it can also provide more or less seamless switching between wired and wireless modes (interrupted tethering or USB Peripheral connections will also make ports go away on the PC side). |
||||||||||||||
|
|
||||||||||||||