odd context output?

[Claire Arthur]

Hi all,

I'm a bit confused by the output of the context command in relation to what I thought I was supposed to get as output. What I thought I should get as output seems consistent with the description on the Humdrum command manual (https://www.humdrum.org/man/context/) though it doesn't actually show the example explicitly of what I'm looking for.

When I run context -n 3 -i [=r] density (like in the example only subbing my own file for the density file) I don't get the same output. Specifically, in the online example, records with just the barline (e.g., =41) are preserved; but when I run it, they are padded with tokens but NOT preserved (they are correctly spit out in the amalgamated output but appropriately ignored.)

Similarly, I thought that if I ran this same function with the -o option instead of -i that it similarly would preserve the measure numbers (rather than fill a token, as in the online example) but omit the measures from the returned output.

For posterity sake, I'm running this on a mac running the mojave version of the OS. I've had Nat check this on his Linux machine and the output is the same as mine.

So, my question is: is the online documentation incorrect? Or is the context command not working properly?  I would imagine that it would be a desirable feature to preserve the location (and verbatim output) of the measures when assembling spines?  So I was a bit surprised that I couldn't get it to work -- this was not how I remembered it working. Any feedback welcome.

Claire

[Craig]

Hi Claire,

For me the "context -i" option is also not working, but the "context -o" is working.  I think that that has been 

a problem for quite a while, because I never use the -i option and instead filter the barlines before running

context:

      extractx -s 1 h://chorales/chor001.krn | grep -v ^= | context -n 3

which produces data like this, ignoring barlines (since they barlines are already removed before the data reaches context):

4GG 4G 4E

4G 4E 4F#

4E 4F# 4G

.

4F# 4G 4D

4G 4D 4E

4D 4E 4C

.

4E 4C 8BBL

4C 8BBL 8AAJ

.

8BBL 8AAJ 4GG

8AAJ 4GG 2D;

4GG 2D; 4GG

2D; 4GG 4FF#

Looking at the code to context.awk, I don't yet see an obvious place to fix it. 

I also tried:

      context -n 3 -i "[=r]"

and

      context -n 3 -i '[=r]'

since sometimes in cases like this it is a problem with the shell interpreter messing up the regular expression, but this did not fix the problem.

-=+Craig