-
Notifications
You must be signed in to change notification settings - Fork 0
Plugins
- AES67 Monitor
- DCA/VCA Plotter
- MIDI Fixture Controller
- Protocol Monitor
- QLab Mimic
- Sennheiser Rx Monitor
(This used to be two separate plugins (Midi Events Viewer and OSC Events Viewer), that have since been merged.)
A utility plugin, this provides a non-modal window that floats above the main UI of LiSP - allowing normal program use whilst open - and every time a MIDI or OSC message is received, the plugin displays the message. That's about it.
Whilst not likely to see use mid-performance, it is useful during the setup or debugging of system integration; checking that (a) LiSP is receiving something, and (b) exactly what's being received.
The tab displaying OSC messages also conveniently shows the exact ip and port LiSP is currently listening for OSC messages on.
This is possibly the most flashy and "gimmicky" plugin on this list 😁
Figure53, the folks behind QLab, provide an iOS app QLab Remote for, well, remotely controlling QLab. There is also a free (but not open source) third-party iOS app Audio Toolbox that also provides basic remote control of QLab. Both of these apps communicate with QLab via OSC. And wouldn't you know it, Figure53 have provided an online resource (https://qlab.app/docs/v4/scripting/osc-dictionary-v4/) that lists what OSC messages QLab responds to!
Admittedly this resource is provided so interested parties can create their own apps and programs that interact with QLab; but instead I've used it to create a plugin for LiSP that permits LiSP to pretend to be QLab. Thus, it is possible to use either of the two apps mentioned above (and any other similar apps) to remotely control LiSP.
Or at least that's the idea...
There are a few caveats with this plugin:
-
It does not support the full gamut of
OSCmessages that QLab does. This is down to limited development time than anything. (Combined with documentation of varying quality, and an unhelpful support team.) -
Whilst QLab Mimic only requires one additional dependency beyond those that are required for LiSP itself, it requires two of the dependencies it does share - namely
libloandpyliblo- to be a a lot more recent than LiSP does. And it is here that the plugin runs into problems.The minimum version of
liblorequired by this plugin is0.31, which is (currently) the most recently released version and thus few linux distributions have updated their repositories to carry it (https://repology.org/project/liblo).And as for
pyliblo, well: (a) there hasn't been a release since April 2015, and (b) QLab Mimic needs a version that contains both of the currently outstanding PRs in the project's GitHub repository (https://github.com/dsacre/pyliblo) to be applied. -
It requires a version of LiSP that's been modified to support the plugin.
To explain this one, I need to cover a little backstory.
My final year dissertation at university bore the title Controlling the Controllers, with the subtitle of Remote control of sound desks using Show Control Methodology (or something like that - it was a while ago, and I don't have a copy to hand). It was, as the subtitle implies, an essay on how some sound desks are controllable via Show Control: a description of what information would be needed to be communicated to achieve such a thing, followed by an exploration on how it might be - and in fact is - done with the protocols available at the time (MIDI, OSC, DMX).
Whilst I was researching and writing it, it occurred to me that there might be a use for some program that could be used by a sound operator during setup to work out what MIDI messages are needed to achieve a certain goal.
After all: in the world of Lighting, a lighting desk operator does not need to know the specific DMX implementation of the fixtures in their rig: they tell their lighting desk what fixtures are plugged in, and what - in abstract terms (point there; turn green; go brighter) - should be done with them... and the desk works out what DMX changes are needed and makes it.
I, surrounded at the time by the MIDI implementation charts of various sound desks, couldn't believe that there wasn't a similar thing for MIDI...
Well, it's taken a while, and a couple of false starts, but I've eventually created something that approximates that idea I had way back when. Admittedly, my "MIDI Device Library" currently has few device profiles - and the feature set is hardly comprehensive - but it is possible to tell it "Hey, I've got a Allen & Heath GLD80 on channel 14, and I want to mute input channel 7", and receive back a list of the MIDI messages that would need to be transmitted to achieve that (actually transmitting the messages is an exercise for the user).
And what's more, this is not actually part of LiSP - it is a standalone library that any (python) program should be able to use.
So, the plugin:
The plugin provides an interface between the device library and the user of LiSP. When installed, it provides a "MIDI patch list" - much like a lighting desk's DMX patch list. Once populated, users may add a Fixture Control cue. Through this, a user can state the action they wish to achieve with a device in the patch (e.g. mute input channel 18). When the cue is called, LiSP passes the request to the library, which returns a list of needed MIDI messages, which LiSP then transmits.
At no point does the user need to know the MIDI implementation of the device they're sending messages to.
If you don't know what DCAs (some desks call them VCAs) are, then I suppose to oversimplify: they're like mute-groups, but with a fader instead of a button. Like mute-groups, an arbitrary number of any combination of desk channels may be assigned to them; and like mute-groups, audio doesn't actually get routed through them.
In a live music environment, DCAs can be used to group channels together - without altering the signal path of those channels - to allow for ease of control of overall volume of said group.
In large theatrical - in particular musical - shows, DCAs are used to make mixing radio mics far easier. Even with a large quantity of radio mics, typically the only time that they are all "live" at the same time is during big numbers - for most of the show an operator only needs control over a handful of mics. Yes: the mics that make up that handful change from scene to scene, but the point still stands.
By splitting the show by scene (and sometimes more finely still) you can assign individual mics to individual DCAs so you have just the mics you need for a specific scene, with the rest muted, saved as a cue. With appropriate programming of mid-show reassignments, it is possible to mix a musical of 24+ radio mics (& effect return channels) with just 8 faders.
In fact Digico have recently released a video showing how the DCAs (they call them VCAs) on their SD and Quantum series desks (or at least those that are running "theatre-variant" firmware) may be programmed. They also touch on why you wouldn't want to program the reassignments via "normal" desk presets/snapshots. https://www.facebook.com/DiGiCo.Official/videos/191131322331575/
The sort of DCA-reassignment cue-stack that Digico demonstrates in the video only exists on desks specifically aimed at the theatrical market - desks not often found in many venues that typically have more dance-schools or live music events than musical theatre. There may also be a budget concern involved. This is where this plugin comes in.
Along with the added benefit of having the DCA reassignment cues in the same cue-stack as sound effects and other cues, because this plugin depends on the Midi Fixture Controller plugin above, it also uses the same device library it uses. Which means that although it only works with the Allen-Heath GLD80 right now, once appropriate device profiles have been created and added to that library, this plugin should work with any MIDI-capable sound desk with both DCA/VCAs and a comprehensive enough MIDI implementation.
This plugin adds the ability to monitor network-connected Sennheiser-branded radio microphone receivers from within LiSP.
Within the plugin-added dialog window, one can see each receiver's RF and Audio levels, the transmitter's battery status, etc.
Note: Currently only compatible with receivers using Sennheiser's "Media Control Protocol" (MCP).
AES67 is an Audio-over-IP technical standard that can either be used standalone, or as a way to connect certain proprietary AoIP systems with support for AES67 (e.g. Dante, Ravenna, LiveWire+) that would be otherwise unable to interoperate. More information can be found on Wikipedia.
For Linux Systems, AES67 support can be obtained by using the Merging Technologies' kernel driver that adds Ravenna and AES67 capabilities to ALSA. Unfortunately, whilst the kernel driver itself is Open Source (GPLv3.0), the "Butler" (the interface allowing configuration of audio streams entering and leaving the computer running the driver) is not.
There is a way around that however: Andrea Bondavalli's AES67 Daemon.
Andrea's daemon has an API that this plugin communicates with, allowing in-program at-a-glance indication of status, in addition to rudimentary routing of the local AES67 audio connections.