MIDI String: problem pulling necessary note information from notation

[pcartwright]

I'm writing a JSFX effect that sends note-off messages early when articulations are encountered in the notation editor. For example, forcing notes with a staccato mark to be no longer than n milliseconds.

The code below is how I pull the note information from notation if the articulation is found. The MIDI string is #string.

match("%{foo}s*"
   " ""%1-2{channel}d*"
   " ""%1-3{notenum}d*"
   ,#string);

The code works as expected for most articulations. In the example below, channel receives a value of 0 and notenum receives a value of 62:

"NOTE 0 62 articulation staccato"

However, things get messed up when I add a slur into the mix. The example below returns a channel value of 0 (good) and a note value of 1 (not good).

"NOTE 0 62 articulation staccato phrase 1 slur begin"

Clearly, the notenum line of my code is capturing the third numeric found and not the second, but I'm not sure why. Any ideas?

[ijijn]

This is because your matching approach is greedy for the * after channel: there's a suitable candidate for notenum (1) later on so it gobbles up the middle of the string. You'll want to use lazy matching with *? instead.

[pcartwright]

Thanks! That did it, though I had to add the '?' to foo as well. I suppose for the same reason; another more suitable string that contains a decimal afterward?

EDIT:

This is the first time where the concept of greedy vs. lazy had any impact to a scrip or JSFX I developed. Why would the example above with the original code not return 62 for channel and 1 for notenum? Is it because the match function knows I'm looking for two integers?

[ijijn]

Glad you got it working!

Ah yes, you'll most likely need multiple ?s to get everything in place. I need to use lazy matching fairly frequently, as the greedy ones often get carried away! I typically like peeling things from the left of the string, and lazy matching works wonders for this.

Hmm, I agree that it does seem counter-intuitive. Just about everything is greedy in your example (the named string, the integer captures and the *s, but not the single spaces) so it would be hard to predict a particular result in advance.

I think that using a right-to-left lazy matching protocol for a greedy left-to-right effect would probably produce the 62 and 1 you would expect but maybe this is implemented slightly differently with some subtle priorities in play. I'm certainly no expert in this area so take with a grain of salt. Really, whenever I find myself in a situation like this I just look for ways to make the match more secure.

Also, if you removed the * between the channel and notenum, that would pin down that part more precisely as two adjacent integers, which can be helpful.