| Message ID | 570AA980.3070802@ladisch.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, 10 Apr 2016, Clemens Ladisch wrote: > By default, amidi ignores Active Sensing messages because they are sent > by many devices in the background and would only interfere with the > actual messages that amidi is supposed to capture. However, there are > also devices that send Clock messages with the same problem, so it is > a better idea to filter out all System Real-Time messages. I would argue that it would be better to have both options, somehow. I.e. active sensing is mostly a nuisance, but I can imagine occasions (analyzing the output from a sequencer perhaps) where one would want to keep the rest of the real time messages. /Ricard
On Mon, 11 Apr 2016, Ricard Wanderlof wrote: > > On Sun, 10 Apr 2016, Clemens Ladisch wrote: > >> By default, amidi ignores Active Sensing messages because they are sent >> by many devices in the background and would only interfere with the >> actual messages that amidi is supposed to capture. However, there are >> also devices that send Clock messages with the same problem, so it is >> a better idea to filter out all System Real-Time messages. > > I would argue that it would be better to have both options, somehow. I.e. > active sensing is mostly a nuisance, but I can imagine occasions > (analyzing the output from a sequencer perhaps) where one would want to > keep the rest of the real time messages. Hi, I can see your point. I have been thinking about that but my coding skills are somewhat limited. I can image keeping the -a (--allow-realtime) option the way it is and adding a new option -c (--allow-clock) to allow receiving of 0xf8 midiclock messages. At the same time 0xf8 should be filtered by default, just like 0xfe. The other realtime messages are much less a problem because they are not sent continuously (e.g. start and stop) What do you think Clemens Ladich, is this doable?
On Mon, 11 Apr 2016, Martin Tarenskeen wrote: > I can image keeping the -a (--allow-realtime) option > the way it is I meant to write -a (--active-sensing --allow-realtime is what I have now in my home-hacked patched version.
Ricard Wanderlof wrote: > On Sun, 10 Apr 2016, Clemens Ladisch wrote: >> By default, amidi ignores Active Sensing messages because they are sent >> by many devices in the background and would only interfere with the >> actual messages that amidi is supposed to capture. However, there are >> also devices that send Clock messages with the same problem, so it is >> a better idea to filter out all System Real-Time messages. > > I would argue that it would be better to have both options, somehow. I.e. > active sensing is mostly a nuisance, but I can imagine occasions > (analyzing the output from a sequencer perhaps) where one would want to > keep the rest of the real time messages. I can imagine this too, and even more complex filters. But the amidi tool is designed to be simple, and works on the lowest level, with raw MIDI bytes. This makes it appropriate to handle SysEx stuff and to debug low-level hardware problems, but when you care about the semantics of the messages, you should use a higher-level tool, such as aseqdump. Filtering out clock messages serves an actual need. But I am not willing to add complexity for a problem that is, at the moment, nothing but a figment of our imaginations. Regards, Clemens
On Mon, 11 Apr 2016, Clemens Ladisch wrote: > Ricard Wanderlof wrote: > > > > I would argue that it would be better to have both options, somehow. I.e. > > active sensing is mostly a nuisance, but I can imagine occasions > > (analyzing the output from a sequencer perhaps) where one would want to > > keep the rest of the real time messages. > > I can imagine this too, and even more complex filters. > > But the amidi tool is designed to be simple, and works on the lowest > level, with raw MIDI bytes. This makes it appropriate to handle SysEx > stuff and to debug low-level hardware problems, but when you care about > the semantics of the messages, you should use a higher-level tool, such > as aseqdump. > > Filtering out clock messages serves an actual need. But I am not > willing to add complexity for a problem that is, at the moment, nothing > but a figment of our imaginations. My argument is really that currently amidi has an option for filtering out active sensing, which has probably been added as it serves a useful purpose in its own right. The patch replaces that filter with one that filters out everything from F8 (clock) and up, I think it would be better to keep the existing option, and add a new one, rather than to essentially change the meaning of the existing option. I agree that more advanced filtering should be left to another application. /Ricard
Ricard Wanderlof wrote: > On Mon, 11 Apr 2016, Clemens Ladisch wrote: >> Ricard Wanderlof wrote: >>> I would argue that it would be better to have both options, somehow. I.e. >>> active sensing is mostly a nuisance, but I can imagine occasions >>> (analyzing the output from a sequencer perhaps) where one would want to >>> keep the rest of the real time messages. >> >> I can imagine this too, and even more complex filters. >> >> But the amidi tool is designed to be simple, and works on the lowest >> level, with raw MIDI bytes. This makes it appropriate to handle SysEx >> stuff and to debug low-level hardware problems, but when you care about >> the semantics of the messages, you should use a higher-level tool, such >> as aseqdump. >> >> Filtering out clock messages serves an actual need. But I am not >> willing to add complexity for a problem that is, at the moment, nothing >> but a figment of our imaginations. > > My argument is really that currently amidi has an option for filtering out > active sensing, which has probably been added as it serves a useful > purpose in its own right. The patch replaces that filter with one that > filters out everything from F8 (clock) and up I consider this change a bug fix; I just forgot about clock messages when I originally impemented the filter. > I think it would be better to keep the existing option, and add a new > one, rather than to essentially change the meaning of the existing > option. That would be a new feature. Regards, Clemens
On Mon, 11 Apr 2016, Clemens Ladisch wrote: > >> Filtering out clock messages serves an actual need. But I am not > >> willing to add complexity for a problem that is, at the moment, nothing > >> but a figment of our imaginations. > > > > My argument is really that currently amidi has an option for filtering out > > active sensing, which has probably been added as it serves a useful > > purpose in its own right. The patch replaces that filter with one that > > filters out everything from F8 (clock) and up > > I consider this change a bug fix; I just forgot about clock messages > when I originally impemented the filter. Fair enough, although regardless of the original intention, the current version is out there (although I honestly haven't checked how long the filtering option has been available, perhaps it's not that long), and it's not buggy in the sense that it does what the corresponding (long) option says it will do. > > I think it would be better to keep the existing option, and add a new > > one, rather than to essentially change the meaning of the existing > > option. > > That would be a new feature. Yes. /Ricard
diff --git a/amidi/amidi.1 b/amidi/amidi.1 index 1b4cfb1..46e9c50 100644 --- a/amidi/amidi.1 +++ b/amidi/amidi.1 @@ -1,4 +1,4 @@ -.TH AMIDI 1 "26 Jun 2006" +.TH AMIDI 1 "26 Mar 2016" .SH NAME amidi \- read from and write to ALSA RawMIDI ports @@ -80,7 +80,7 @@ to record a Standard MIDI (.mid) file, use .B arecordmidi(1). .B amidi -will filter out any Active Sensing bytes (FEh), unless the +will filter out System Real-Time messages (F8h...FFh), unless the .I \-a option has been given. @@ -91,7 +91,7 @@ Sends the bytes specified as hexadecimal numbers to the MIDI port. .TP .I \-d, \-\-dump Prints data received from the MIDI port as hexadecimal bytes. -Active Sensing bytes (FEh) will not be shown, unless the +System Real-Time messages (F8h...FFh) will not be shown, unless the .I \-a option has been given. @@ -107,9 +107,16 @@ If this option has not been given, you must press Ctrl+C (or kill to stop receiving data. .TP -.I \-a, \-\-active\-sensing -Does not ignore Active Sensing bytes (FEh) when saving or printing -received MIDI commands. +.I \-a, \-\-all\-messages +Includes System Real-Time messages (F8h...FFh) when saving or +printing received MIDI commands. +By default, these messages are ignored. + +(Clock (F8h) or Active Sensing (FEh) messages are sent in the +background by many devices, but typically are not wanted and would +only clutter up +.B amidi\fR's +output.) .SH EXAMPLES diff --git a/amidi/amidi.c b/amidi/amidi.c index cedf18c..4978249 100644 --- a/amidi/amidi.c +++ b/amidi/amidi.c @@ -77,7 +77,7 @@ static void usage(void) "-d, --dump print received data as hexadecimal bytes\n" "-t, --timeout=seconds exits when no data has been received\n" " for the specified duration\n" - "-a, --active-sensing don't ignore active sensing bytes\n"); + "-a, --all-messages include system real-time messages\n"); } static void version(void) @@ -418,11 +418,12 @@ int main(int argc, char *argv[]) {"send-hex", 2, NULL, 'S'}, {"dump", 0, NULL, 'd'}, {"timeout", 1, NULL, 't'}, - {"active-sensing", 0, NULL, 'a'}, + {"all-messages", 0, NULL, 'a'}, + {"active-sensing", 0, NULL, 'a'}, /* for backwards compatibility */ { } }; int c, err, ok = 0; - int ignore_active_sensing = 1; + int ignore_system_realtime = 1; int do_send_hex = 0; while ((c = getopt_long(argc, argv, short_options, @@ -461,7 +462,7 @@ int main(int argc, char *argv[]) timeout = atoi(optarg); break; case 'a': - ignore_active_sensing = 0; + ignore_system_realtime = 0; break; default: error("Try `amidi --help' for more information."); @@ -589,7 +590,7 @@ int main(int argc, char *argv[]) } length = 0; for (i = 0; i < err; ++i) - if (!ignore_active_sensing || buf[i] != 0xfe) + if (!ignore_system_realtime || buf[i] < 0xf8) buf[length++] = buf[i]; if (length == 0) continue;
By default, amidi ignores Active Sensing messages because they are sent by many devices in the background and would only interfere with the actual messages that amidi is supposed to capture. However, there are also devices that send Clock messages with the same problem, so it is a better idea to filter out all System Real-Time messages. Reported-by: Martin Tarenskeen <m.tarenskeen@zonnet.nl> Signed-off-by: Clemens Ladisch <clemens@ladisch.de> --- amidi/amidi.1 | 19 +++++++++++++------ amidi/amidi.c | 11 ++++++----- 2 files changed, 19 insertions(+), 11 deletions(-)