It occurred to me that another solution would be to write the scores in Chinese. And as a bonus, where else can you find a ready-made supply of 10,000 symbols that already have (more or less) definite meanings?
Wednesday, April 18, 2012
text wrapping
And speaking of aesthetic matters, here are a few more screenshots I had on my desktop from when I was trying to figure out what to do with too-long text:
Rotating text vertically looks cool but turns out it's just not as readable as plain word wrapping.
It occurred to me that another solution would be to write the scores in Chinese. And as a bonus, where else can you find a ready-made supply of 10,000 symbols that already have (more or less) definite meanings?
It occurred to me that another solution would be to write the scores in Chinese. And as a bonus, where else can you find a ready-made supply of 10,000 symbols that already have (more or less) definite meanings?
hex vs. decimal
One of the things I do a lot is writing numbers between 0 and 1. All control values are normalized between 0 and 1 and it turns out scores have a lot of control values. However, I haven't been entirely happy just writing plain decimal numbers for a couple of reasons.
Their values are not very visually apparent. 1.7 looks very similar to .17, but they are entirely different values. I'm usually writing between 0 and 1 so it's annoying to have to write that decimal point every single time. It shouldn't even be possible to accidentally write 1.7. They're also variable length, so for example if I divide all the values by 2 some are likely to turn into big long numbers that no longer fit. I already trim them to 3 decimal places, but a resolution of 1000 is still more than I need---MIDI only has 7 bits of resolution for most control values anyway. It's also annoying how you have to type all those backspaces to change a value, and it's especially slow because it means you actually have to look at what you're doing to know how many backspaces to type. That's the variable length thing.
So I thought I could take a page from the trackers and represent values as fixed width values between 00 and ff. It's faster to type because each key can insert its higit on the right side, and bump off the higit on the left side. I can't automatically advance the cursor after 2 higits because I don't keep track of a cursor position, but I know from experience it's pretty fast to keep one hand on the top digit row and another on the arrows. a-f is a bit more problematic one-handed, especially since my one-handed dvorak is a bit awkward.
Of course not all values are normalized from 0 to 1, so I have an unusual syntax: all hex literals are two-higit and are divided by 255. Actually, what I wound up with is `0x`## so the 'x' can be a small superscript, since it's noisy and space hogging to have every line with a leading 0x.
This is one of those places where a score is not much like a general purpose programming language. Where else would you be writing so many numeric literals that the appearance, width, and ease of them was so important that it's worth building it into the syntax?
The result? I don't know. I think I've gotten used to decimal. The hex actually winds up being a tiny bit wider, since decimal's leading decimal point is actually quite narrow. I'm lukewarm at the moment but I'll have to work with hex for a while and see if I start to like it more. Actually I seem to recall that back in the Amiga tracker day there were only 6 bits of resolution, and that 10, 20, 30, and 40 made convenient rough points of reference. I suppose I can do the same with 40, 80, c0, and ff.
With decimal:
With hex:
Their values are not very visually apparent. 1.7 looks very similar to .17, but they are entirely different values. I'm usually writing between 0 and 1 so it's annoying to have to write that decimal point every single time. It shouldn't even be possible to accidentally write 1.7. They're also variable length, so for example if I divide all the values by 2 some are likely to turn into big long numbers that no longer fit. I already trim them to 3 decimal places, but a resolution of 1000 is still more than I need---MIDI only has 7 bits of resolution for most control values anyway. It's also annoying how you have to type all those backspaces to change a value, and it's especially slow because it means you actually have to look at what you're doing to know how many backspaces to type. That's the variable length thing.
So I thought I could take a page from the trackers and represent values as fixed width values between 00 and ff. It's faster to type because each key can insert its higit on the right side, and bump off the higit on the left side. I can't automatically advance the cursor after 2 higits because I don't keep track of a cursor position, but I know from experience it's pretty fast to keep one hand on the top digit row and another on the arrows. a-f is a bit more problematic one-handed, especially since my one-handed dvorak is a bit awkward.
Of course not all values are normalized from 0 to 1, so I have an unusual syntax: all hex literals are two-higit and are divided by 255. Actually, what I wound up with is `0x`## so the 'x' can be a small superscript, since it's noisy and space hogging to have every line with a leading 0x.
This is one of those places where a score is not much like a general purpose programming language. Where else would you be writing so many numeric literals that the appearance, width, and ease of them was so important that it's worth building it into the syntax?
The result? I don't know. I think I've gotten used to decimal. The hex actually winds up being a tiny bit wider, since decimal's leading decimal point is actually quite narrow. I'm lukewarm at the moment but I'll have to work with hex for a while and see if I start to like it more. Actually I seem to recall that back in the Amiga tracker day there were only 6 bits of resolution, and that 10, 20, 30, and 40 made convenient rough points of reference. I suppose I can do the same with 40, 80, c0, and ff.
With decimal:
With hex:
Subscribe to:
Posts (Atom)