[LAD] Session wide panic functionality?

Len Ovens len at ovenwerks.net
Mon Oct 24 16:19:21 UTC 2016


On Sun, 23 Oct 2016, Simon van der Veldt wrote:

> Then the question rises again, what would be the correct place to put this kind
> of functionality? In the protocol that controls the instrument (MIDI or OSC) or
> the protocol that controls the playback of the instrument (JACK transport)?

So far as I can tell, there is no fool proof way to have a system wide 
panic that stops all the noise. If one assumes all synths have inputs 
connected to jack/alsa that is ok. Plugins inside a DAW or other SW remove 
control from just about any kind of script. The "Panic" then relies on 
that SW to pass the panic message on. There are some reasons this might 
not be so:
- the synth is being fed from disk
- internal routing has changed between note on/off
- the SW may use midi interneally, but have no midi connection externally

Hopefully, such SW keeps track of anything internally and passes the panic 
message to useful places.... What are those useful places? Should the DAW 
stop (even if recording)? Should it apply the panic to all it's synths or 
just the one connected to the input in question? What of MIDI tracks that 
have no assigned input? A daw on stop probably mutes all sound so a stop 
might be more effective than a panic message in that case.

If this is a live situation does panic turn all the lights off as well? 
All analog audio? sending MIDI or OSC messages everywhere including 
control surfaces may not be the best thing.

A quick note on OSC: OSC can be multicast, but normally it is point to 
point. The server may have a random IP, port and protocol. Those things 
may not be advertized with zeroconf or whatever. This is aside from there 
being no standard /panic message. So for Ardour I could do:
oscsend localhost 3819 /access_action s "/midi_panic"
But if 3819 happens to be in use when Ardour starts, it will pick 
something else. Of course, it is unlikely that any other SW would know 
what to do with this message. (and OSC would have to be turned on for the 
session in use)

I do think a unique solution could be put together for a particular system 
when running a known set of applications, but a generic script will likely 
either miss something or hit something it shouldn't in an unknown 
situation.

Just my thoughts.

--
Len Ovens
www.ovenwerks.net



More information about the Linux-audio-dev mailing list