Kara-Moon Forum

Although the documentation mentions that bar labels should be numbers, MMA '-b' malfunctions when labels have leading zeroes.

    $ tail -5 t.mma
    001         Am
    002         G
    003         Am   Em
    004         Am
    005         Am
    $ mma -b1-3 t.mma
    Creating new midi file (5 bars, 0.15 min / :09 m:s): 't.mid'
       Range directive -b/B would result in empty file.    Entire file is being
        created. Check the range.

If you agree that leading zeroes should be acceptable, apply the following fix to parse.py, line 200:

            gbl.barLabel = str(int(l[0]))

That works ... but ... it also means that with the patch line numbers '001' and '1' (and '01') are now the same lines. Not sure if that is a good thing or a bad one :) Discuss please.

For those scratching heads (like I did for a minute or two):

   l[0] is a string
   if that string is all digits we currently save it as a line number. AS A STRING
    ...
   the suggested patch will convert the string (ie, '001') to an integer and convert that back to a string.
     This will then convert '001' to '1'.

Nice thing about the patch is that -b will now work with leading zero line numbers and (for neat freaks) you can now have a wack of line numbers like 0001, 0002, etc. all nicely lining up.

Also, I think that I really should initialize gbl.barLabel in the gbl.py file for clarity. Works fine the way it is, but I think it is sloppy on my part. And, then the array gbl.barLabels is a confusing name. For sure I will need to look at this. Note to myself: the only other file using gbl.barLabel is in trigger.py and (need to check) I think this can be done checking the array instead.

Well, since it is a number, 001 is numerically equal to 1 (and 01).

Do you have a use case where line numbers like 1 and 01 are used (and -b still works)?

I do not have such a case :) I will commit the change ... but before I do I want to look at the code and see if there is any reason to keep it as a string. Might be easier using an integer.

The change is committed. I've changed one thing ... instead of str(int()) I'm using lstrip() will is quite a bit fast. Not that anyone will ever notice. So, lines 199/200 now read:

    if action.isdigit():   # isdigit() matches '1', '1234' but not '1a'!
            gbl.barLabel = l[0].lstrip('0')

I did some tests and it seems to be fine.

Good idea. I considered using a re match/replace of the leading zeroes but didn't think it would be worth it. So apparently it was lstrip that I was looking for :) .

Thanks!

In my experience, if you use regular expressions to solve a problem you now have 2 problems :) I hate regexp.

BTW, lstrip() is more than 2x as fast as str(int()).

I'm a Perl adept and in Perl regular expressions are as common (and fast!) as breathing.

Nevertheless, the real reason I used str(int(l[0])) was that I originally tried int(l[0]) and then mma -b didn't work anymore. So I just added str() not wanting to spend any more energy on such a trivial case. As you mentioned earlier, "Not that anyone will ever notice." :)

I have made one other change regarding the bar labels. In trigger.py please change at line 240 to:

  elif cmd == 'MEASURES':
            for a in opt.split(','):
                if not a.isdigit():
                    warning("%s Trigger: Measures should be bar labels, not '%s'."
                            "This trigger will be ignored." % (self.name, a))
                    continue
                trigger.measures.append(a.lstrip('0'))


this inserts a warning message for illegal labels and strips off the leading '0's to match the new behavior of setting them.

Thanks, applied.