User Tools

Site Tools


midi_scripting

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Last revision Both sides next revision
midi_scripting [2019/11/24 08:58]
kobx formatting, remplaced --midiDebug with --controllerDebug
midi_scripting [2019/11/24 11:56]
kobx Added part about debugging
Line 76: Line 76:
 The ID parameter of the init function is the ''​controller id''​ attribute from the XML file. The ID parameter of the init function is the ''​controller id''​ attribute from the XML file.
 This can be used to identify the particular controller instance in print statements. This can be used to identify the particular controller instance in print statements.
-The ''​debugging''​ parameter is set to '​true'​ if the user specified the ''​%%--controllerDebug%%''​ parameter on the command line (''​%%--mididebug%%''​ until Mixxx 1.10).+The ''​debugging''​ parameter is set to '​true'​ if the user specified the ''​%%--controllerDebug%%''​ parameter on the command line (''​%%--midiDebug%%''​ until Mixxx 1.10).
  
 **Note**: Instead of using global variables, define properties of your controller object (''​MyController''​ in this example) to avoid name collisions with other scripts that may be loaded. **Note**: Instead of using global variables, define properties of your controller object (''​MyController''​ in this example) to avoid name collisions with other scripts that may be loaded.
Line 249: Line 249:
  
 Generally, you should not call ''​midi.sendShortMsg''​ or ''​midi.sendSysexMsg''​ directly from functions that handle MIDI input. Instead, the input function should change the state of a [[MixxxControls|Mixxx Control]] and you should call ''​midi.sendShortMsg''/''​midi.sendSysexMsg''​ in a callback function that reacts to changes in that Mixxx Control. Refer to the section above for details. This way, the state of the controller will always be in sync with what Mixxx is actually doing, even if the user manipulates Mixxx with the keyboard, mouse, or another controller. If the MIDI input handling function only changes the state of script variables but not Mixxx Controls, then it would be appropriate to call ''​midi.sendShortMsg''/''​midi.sendSysexMsg''​ from the input handling function. Generally, you should not call ''​midi.sendShortMsg''​ or ''​midi.sendSysexMsg''​ directly from functions that handle MIDI input. Instead, the input function should change the state of a [[MixxxControls|Mixxx Control]] and you should call ''​midi.sendShortMsg''/''​midi.sendSysexMsg''​ in a callback function that reacts to changes in that Mixxx Control. Refer to the section above for details. This way, the state of the controller will always be in sync with what Mixxx is actually doing, even if the user manipulates Mixxx with the keyboard, mouse, or another controller. If the MIDI input handling function only changes the state of script variables but not Mixxx Controls, then it would be appropriate to call ''​midi.sendShortMsg''/''​midi.sendSysexMsg''​ from the input handling function.
 +
 +===== Debugging your mappings =====
 +As mentioned above, you don't have to restart Mixxx, when you're testing your scripts.
 +Every time you save your file, Mixxx will reload it immediately.
 +Additionally if you specify ''​%%--controllerDebug%%''​ (or ''​%%--midiDebug%%''​ prior to verion 1.11),
 +Mixxx then logs all incoming and outgoing MIDI messages.
 +Also you can use ''​print()''​ in your script to output further messages.
 +The second parameter passed to your ''​init()''​ functions specifies if the controller debug mode is enabled.
  
 ===== Components library ===== ===== Components library =====
 Now that you understand the basics, it is suggested to use the [[Components JS]] library for new mappings. Now that you understand the basics, it is suggested to use the [[Components JS]] library for new mappings.
 +
 ===== Soft-takeover ===== ===== Soft-takeover =====
 To prevent sudden wide parameter changes when the on-screen control diverges from a hardware control, use soft-takeover. While it's active on a particular parameter, manipulating the control on the hardware will have no effect until the position of the hardware control is close to that of the software, at which point it will take over and operate as usual. You can enable and disable it at any point, and it operates on each MixxxControl independently. Typically, for each control that has physical limits (typically, knobs and sliders) on your controller, you would enable soft-takeover in the ''​init()''​ script function and just leave it enabled. To prevent sudden wide parameter changes when the on-screen control diverges from a hardware control, use soft-takeover. While it's active on a particular parameter, manipulating the control on the hardware will have no effect until the position of the hardware control is close to that of the software, at which point it will take over and operate as usual. You can enable and disable it at any point, and it operates on each MixxxControl independently. Typically, for each control that has physical limits (typically, knobs and sliders) on your controller, you would enable soft-takeover in the ''​init()''​ script function and just leave it enabled.
midi_scripting.txt ยท Last modified: 2019/11/24 12:10 by kobx