MIDI control lets a physical controller send instructions that TuneIT uses to operate audio playback. The controller supplies a control message; the audio still comes from the files and output configuration in the playback project. This guide is about MIDI-controlled audio playback, not playing MIDI files or turning TuneIT into a synthesiser.
Draft — current-build validation required. The public TuneIT documentation describes MIDI Learn and says mappings are saved with the project. The steps below follow that documented workflow, but exact control labels, accepted message types and save/reopen behaviour have not been tested against the current release. Complete the release checks at the end before publication.
Connect and identify the controller
Connect the controller using its manufacturer’s supported connection method. For a USB device, confirm that the operating system recognises it and install a driver only if the manufacturer requires one. A traditional MIDI connection needs a suitable interface and correct input/output cabling. Do not assume that an audio cable also carries MIDI control data.
Open TuneIT and inspect its MIDI controls. Identify the input corresponding to the connected controller; similarly named virtual ports can belong to other software. Note the controller model, operating system and TuneIT build. This makes the test repeatable and helps distinguish a device-detection problem from an incorrect mapping.
Prepare one audio cue before learning a control
Load a short, recognisable test sound onto a playback pad and confirm that it starts from TuneIT’s interface through the intended audio output. Start with a simple cue and a modest listening level. If local playback fails, solve that issue first; a MIDI mapping cannot fix a missing file or the wrong audio output.
Choose one physical button or pad for the first assignment. Keep unrelated controllers quiet during the learning step so that an accidental movement does not become the captured input. Record which physical control you intend to use and the action it should perform.
Use the documented MIDI Learn workflow
TuneIT’s documentation describes opening the MIDI controls and using MIDI Learn to map actions. In the build being tested, identify the action or pad target, enter its learn/capture state, then operate the chosen control once. Inspect what was captured and leave the learn state before testing playback. The precise sequence and labels must be confirmed in the current interface; this draft does not invent button names.
Test a single press and then a release. Some controllers send different messages for those two events, or can operate in different modes. Confirm what TuneIT accepts before deciding that a physical control is suitable. Do not assume support for every MIDI message type, velocity behaviour or LED feedback simply because the controller offers it.
Build a small, deliberate control layout
- Assign one control to one verified playback action first. Confirm the intended pad responds and another pad does not.
- Add further sound cues individually and keep a simple mapping list that names the physical control and its target.
- Assign transport or stop controls only when the current TuneIT interface exposes the required action. Test the scope of a stop action before using it in a show.
- Repeat the test with the actual controller preset and any other MIDI software that will be present on the playback computer.
For a rehearsal rig, a useful first test is two distinct effects on two different controls. Trigger each repeatedly, release each control and try the actions in the reverse order. Listen for duplicate starts or unexpected stops. This is an acceptance test for the mapping, not a claim that TuneIT implements a particular controller mode.
Save, close and verify the configuration
The public documentation says MIDI mappings are saved with the project. Save using the application’s project workflow, then reopen the project and confirm the assignments remain. Reconnect the controller and repeat the two-cue test. A successful save alone is not proof that a mapping will recover correctly on another computer or with a differently named MIDI port.
Keep a record of the controller preset and the tested setup alongside the project. If the show moves between Windows and macOS, repeat the test on the destination system and confirm its input selection and output routing. Do not assume a controller’s port names or driver behaviour will match across operating systems.
Troubleshooting
- No device listed: check power, cable, manufacturer requirements and operating-system recognition. Reconnect as appropriate, then recheck TuneIT.
- Device present but no trigger: confirm the chosen input, assignment target and captured control message; also verify that local playback still works.
- One press triggers twice: inspect whether the controller sends separate press/release messages or duplicate routes. Check the supported mapping behaviour before changing it.
- The wrong action occurs: compare the physical control, controller preset and saved mapping list; check for overlapping assignments.
- Mappings seem lost: verify that you reopened the intended saved project and selected the expected device. Record the result and seek support if it differs from the documented behaviour.
Release checks before publication
Record the tested TuneIT version/build on Windows and macOS, exact MIDI settings and Learn labels, supported input/message types, learning sequence, available action targets and save/reopen results. Test with an identified physical controller. Confirm any limits around project portability, press/release handling and feedback before adding those claims. Remove the draft notice only after those checks pass.
Continue with TuneIT features, the documentation overview or Support. Use the official download page to obtain the release you intend to test.