23 Oct
2016
23 Oct
'16
3:56 p.m.
Hi all,
I'm new to this list, been getting into making music on my Linux machine
the last couple of weeks/months.
One of the things I was wondering, it seems like there's no way to make use
of the functionality some instruments have to kill all sounds (panic
button) for all instruments in a session.
Am I correct in my observation that functionality like this is missing? Do
others see a use/need for this as well?
If so, I'm wondering what the correct place would be to implement this: I'd
guess JACK transport?
Thanks and have a nice day!
Simon
23 Oct
23 Oct
4:36 p.m.
Am 23.10.2016 um 17:56 schrieb Simon van der Veldt:
One of the things I was wondering, it seems like
there's no way to make
use of the functionality some instruments have to kill all sounds (panic
button) for all instruments in a session.
"Panic" is a colloquial name for the reaction triggered by the
combination of the MIDI "All notes off" and/or "All sound off" and
"Reset all controllers" messages. Devices and software, which have a
panic function usually react to these MIDI messages as well.
Here's a script using python-rtmidi [1] to send "All sound off" and
"Reset all controllers" on all MIDI channels to all available JACK MIDI
outputs:
https://gist.github.com/c3a212d0071ed78adf4507d16e74305d
import rtmidi
from rtmidi.midiconstants import (ALL_SOUND_OFF, CONTROL_CHANGE,
RESET_ALL_CONTROLLERS)
mo = rtmidi.MidiOut(rtapi=rtmidi.API_UNIX_JACK)
print("Sending AllSoundOff and ResetAllControllers on all channels...")
for portnum, portname in enumerate(mo.get_ports()):
print("Port:", portname)
mo.open_port(portnum)
for channel in range(16):
mo.send_message([CONTROL_CHANGE, ALL_SOUND_OFF, 0])
mo.send_message([CONTROL_CHANGE, RESET_ALL_CONTROLLERS, 0])
mo.close_port()
[1] https://github.com/SpotlightKid/python-rtmidi
4:40 p.m.
Am 23.10.2016 um 18:36 schrieb Christopher Arndt:
for channel in range(16):
mo.send_message([CONTROL_CHANGE, ALL_SOUND_OFF, 0])
mo.send_message([CONTROL_CHANGE, RESET_ALL_CONTROLLERS, 0])
Sorry, that should be:
mo.send_message([CONTROL_CHANGE & channel, ALL_SOUND_OFF, 0])
mo.send_message([CONTROL_CHANGE & channel,
RESET_ALL_CONTROLLERS, 0])
(Fixed the Gist as well.)
Chris
4:52 p.m.
On Sun, Oct 23, 2016 at 6:36 PM, Christopher Arndt <chris(a)chrisarndt.de>
wrote:
"Panic" is a colloquial name for the
reaction triggered by the
combination of the MIDI "All notes off" and/or "All sound off" and
"Reset all controllers" messages. Devices and software, which have a
panic function usually react to these MIDI messages as well.
That's a perfect suggestion, totally forgot about the MIDI possibilities to
do this. Thanks!
It's also possible to do this for OSC with the /panic command, so I guess
that solves the "where should this functionality live" question :)
Also thanks a lot for the gist, I'll whip up a similar script which will
trigger the relevant commands for both MIDI and OSC and run that separately
from the session manager/transport controls when I need it.
Maybe something to add to gladish or claudia in the future.
Thanks again!
Simon
5:16 p.m.
Am 23.10.2016 um 18:51 schrieb Simon van der Veldt:
It's also possible to do this for OSC with the
/panic command, so I
guess that solves the "where should this functionality live" question :)
AFAIK, "/panic" is not a standard OSC message. In fact there are no
"standard" OSC messages.
Chris
9:36 p.m.
On Sun, Oct 23, 2016 at 7:16 PM, Christopher Arndt <chris(a)chrisarndt.de>
wrote:
AFAIK, "/panic" is not a standard OSC
message. In fact there are no
"standard" OSC messages.
You're correct, even though some OSC applications do have such an option
there doesn't seem to be a standardized way to trigger a "panic" mode in
OSC :(
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)?
Simon
10:23 p.m.
On Sun, 23 Oct 2016 23:36:11 +0200
Simon van der Veldt <simon.vanderveldt(a)gmail.com> wrote:
On Sun, Oct 23, 2016 at 7:16 PM, Christopher Arndt
<chris(a)chrisarndt.de>
wrote:
First you need to decide whether you just want to stop making noise, or if you
want to make everything stop doing whatever they do to make noise. They are not
quite the same thing.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
AFAIK, "/panic" is not a standard OSC
message. In fact there are no
"standard" OSC messages.
You're correct, even though some OSC applications do have such an option
there doesn't seem to be a standardized way to trigger a "panic" mode in
OSC :(
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)?
Simon 
10:29 p.m.
OSC doesn't work like that.
The power and weakness of OSC is indeed in the fact that there's no
standard OSC protocol for paths.
JACK too doesn't have such a feature, because it really depends on how
every DAW/plugin/VST/etc would handle a "panic" command.
For example, I might have a synth that - by default - reacts to such a
message by sending the above mentioned "all sounds off" event, but ignoring
the "reset all controllers, but that allows a generic panic message which
resets all controllers too. That's because a user might want to preserve
the controllers status as it is and just stop notes. And this is just one
in a million of possible scenarios.
Anyway, if you're just using devices which are able to receive midi
commands, you could try using mididings ( http://das.nasophon.de/mididings/
) with a specific python script that interfaces with it. Then you can use
whatever you want to control it, since it also has a basic OSC protocol
feature.
If you have both ALSA and JACK devices you might have to use two mididings
scripts, or, eventually (if you really know python) use a single script
that starts two different mididings engines, one with ALSA and the other
with JACK. It's a bit tricky, but, once you get it, it's always better to
start a start and check a single script than two ;)
Cheers
24 Oct
24 Oct
4:19 p.m.
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
2989
days inactive
2990
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Christopher Arndt -
Len Ovens -
Maurizio Berti -
Simon van der Veldt -
Will Godfrey