As of version 3.2.1, PGJTT mixer-templates include a hidden set of channel strips that are called into action when an ensemble wants to send and receive multi-channel audio. This gizmo is built for flexibility, not ease of use. Feel free to contact me for assistance. Click on the pictures to embiggen.
The red-themed “Multi-channel” column in this diagram shows how those hidden channels relate to a series of routing use-cases. These can be combined to deliver reliable, repeatable connections for an ensemble. Once configured, connections are made and torn down automatically by the connect_players script as Players connect and disconnect from JackTrip.
The heart of this lies in creating Jmess XML files that describe the connections the ensemble wants to make, player by player. The connections in the files are made when the player connects, hence the need for one file per player. Flexible as can be… Not super easy, but not horribly hard. The worst that can happen is player-connections won’t be made. Testing is highly recommended.
The connect_players script looks for Jmess files (in the /usr/local/etc/ directory) that match the Player and a session_name that is specified in the command line (thus providing the ability to stage multiple events and switch rapidly between them). In this case, the connect_players script is indicating that Player8 is connected multi-channel.
These following scenarios provide the basics of how to build Jmess files. These sample files are included in the PGJTT /usr/local/etc/ directory and will work if connect_players is called with a session_name of ‘MultiExample’.
These examples describe situations where a player is either sending or receiving multi-channel but this is only for brevity and clarity. Routings where Players send and receive multi-channel work the same way just with more entries in the Jmess XML file.
Scenarios
Player sending post-fader Makes this player’s audio available for receiving player(s). Post-fader implies that the receiving player(s) will be getting the result of any mixing/FX applied to the audio.
Player sending pre-fader Makes this player’s audio available for receiving player(s). Pre-fader implies that the receiving player(s) will be getting audio directly off the incoming JackTrip connection.
Player multi in, sending pre-fader Makes this player’s audio available for receiving player(s). Pre-fader implies that the receiving player(s) will be getting audio directly off the incoming JackTrip connection. In this case the player is sending 4 channels of audio and adjacent channels (and Player numbers) are used to mix and forward those additional channels. There’s no limit to the number of channels that can be handled this way, except the overall limit of channels imposed by the largest mixer template (currently 25).
Player not sending or receiving multi. Shows that this player does not require a Jmess multi file, because their connections are handled by standard connect_players processing.
Player multi in, sending post-fader Makes this player’s audio available for receiving player(s). Post-fader implies that the receiving player(s) will be getting the result of any mixing/FX applied to the audio. In this case the player is sending 4 channels of audio and adjacent channels (and Player numbers) are used to mix and forward those additional channels. There’s no limit to the number of channels that can be handled this way, except the overall limit of channels imposed by the largest mixer template (currently 25).
Player receiving multi-channel Connects multi-channel strips to a player that is receiving multi-channel JackTrip audio from the session.
Production tip – use Qjackctl and Jmess to write Jmess XML files
Repeat these steps for each player who is going to making multichannel connections.
Make a JackTrip connection to an empty Ardour session with the correct player number and multi-channel audio configuration.
Erase all connections with Qjackctl — we are only trying to record the multichannel connections specific to this player.
Manually create the desired multi connections for the connected player (and only that player) with Qjackctl. This example shows Player8 (the one that receives all the multichannel audio).
Write the XML file for that player with Jmess. Take care in writing the file to the location that the connect_players script will look for it (/usr/local/etc). Also take care to specify the exact session_name (MultiDemo in this example), followed by “_Jmess“, followed by player_number (Player8 in this example). Here’s a copy/pasteable version of the string in this example:
jmess -s /usr/local/etc/MultiDemo_Jmess_Player8.xml
Guaranteed that if a player connects and they only connect 2-chan, a file-name mismatch is the cause of the problem. Try running Jmess against the file to test it.
