I find myself getting more interested in recorders. They are actually more interesting than what our school day mandatory lessons might suggest because they actually have a pretty wide range nearly 3 octaves (kinda like a concert flute), though the more standard range is closer to being 2+ octaves (2 octaves and a minor second). This is very close to that of the dizi actually---dizi has a standard range of 2 octaves and a second, with an option to go up to 2 octaves and a fourth. There are some subtle differences still of course, since in terms of correspondence of fingering patterns, the recorder's bell tone starts one major second lower than the dizi, and while the recorder does overblow in octaves, the addition of the thumb hole on the recorder means that the lower half of the second instrument octave has some funky fingering patterns to begin with.
Getting to the upper half of the second instrument octave on the recorder is super funky. They use a lot of variations from the ``standard'' simple flute fingering pattern of XXO-XXO to choose the higher harmonics accordingly to get the right pitch (see this old post for examples of the fingering). It is hard to do that on a 6-hole dizi for two reasons: the lack of a thumb hole makes selecting that higher harmonic through forcing an anti-node from pure embouchure control harder, and the holes on the dizi are much larger than that of the recorder while having a larger inner bore diameter, characteristics that make it less sensitive than the recorder in using right-hand hole covering to force different standing wave modes. But having direct embouchure control on the dizi does make up for the differences---the recorder cannot be coaxed to overblow very high harmonics due to the fixed angle set by the windway and labium.
The recorder does have a more dainty feel to it compared to the one-key flute (and it definitely is much more dainty than the dizi, though it is possible to play the dizi that way with enough training).
I spent some time today putting together an easier table to reference the fingering patterns (regular and minor/major second trills) that the woodwind fingering guide has. There's nothing wrong with that website, it's just that it is not that easy to look at the fingering patterns at a glance. I have done the same for the concert flute as well; unfortunately I cannot post them out due to various limitations listed on the main page itself since I do use the images that the site uses itself. Compare this to the one-key flute fingering chart, and the generic saxophone fingering chart.
Anyway, I raised this point because I'm expecting a delivery tomorrow for an updated alto recorder. Specifically, the YRA-302BIII. I already have the YRA-28BIII from 9 years ago, and it had been one of the old ``work horse'' recorders that I enjoy playing. Now though, amidst all the other recorders that I have, the YRA-28BIII felt a little lacklustre as compared to all the other 300-series recorders from Yamaha. It's about that windway---the other recorders that I have use a slightly curved one, and it has an appreciable effect on the amount of control that I can apply on the instrument. The YRA-28BIII just felt very flat in tone; it didn't seem to want to respond to nuances. At some point, when I was trying to play softer, the sound outright died instead of maintaining itself at the lower dynamics. I'm expecting that the YRA-302BIII will perform much better on that.
It's also a way of testing the Yamaha e-shop. Unfortunately, there really is nothing else from Yamaha that I would like to get, save for their pianica. But that involves a keyboard... and I'm a little less inclined to do so. The rest of the [woodwind] stuff, I can get them from MusicGear Singapore, and with good service as well.
------
In retro-programming land, I figured out the format that QuickBASIC stores its bitmaps in 16-colour land. The basic layout is quite messy---see this schematic to understand the actual memory-mapping used for the hardware. The abstraction here is that the 16-colour is broken down into its 4 bits, with each bit occupying one ``bit plane''. QuickBASIC stores the bitmap in row-major order, with each row comprising a byte-aligned bitmap for each plane. The bytes little-endian order, while the bits are big-endian order (as explained in the schematic). So, to write one pixel colour into the bitmap, I would have to access four different bytes and use bit-operations to set the correct bit. It's horrible, and it sucks, but it was needed because it was designed to conform to what the hardware was capable of. Figuring out the format is important because I needed some way to do pixel perfect collision---dumping it to screen and iterating through what was on-screen felt very wasteful to me. Having in-memory bitmaps that I can operate on also expands options for when I need them, like extracting sub-bitmaps from existing bitmaps/hybrid bitmaps. I think of it as a way to support things like masked bitmapped versions of fonts to allow the background to show through without having to manually create and maintain 256 separate hybrid bitmap arrays (urgh). Potentially, it can be used to handle frame-animations for individual sprites, but that will not be a high priority for now because I don't know how much memory I will end up with.
I also revamped the memory-related parts that I was using for LED2-20. The old method that I was using had an error in it---I was advancing the offsets by one [byte] each time, and when it hit 65536, I rolled it over back to 0 and incremented the segment. It was wrong because of the translation from the segment:offset to the 20-bit physical address was based on segment×16+offset. This meant that if I did what I did, I would end up going back to some previously seen memory location to recopy, which was wrong.
The correct way was to advance along the actual 20-bit physical address to make the copy. However, there was no way within QuickBASIC to walk through the memory that way---it had to be reduced back to some segment to be set by DEF SEG before the relevant PEEK/POKE can be done. And so there had to be some translation in between these two. I haven't benchmarked if this method was fast enough, but at least it would not be the part that breaks if/when I decide to use the ``huge array'' option in QuickBASIC which allowed arrays to break the 64KiB size barrier.
I also have enough machinery to start generating the background images needed for that parallax effect. For efficiency reasons, I'll probably end up storing them as vertical strips. But before I could do it though, I had to think about how the UI should be like; in LED2, the play area was about 320×176, with two lines at the top and one at the bottom used to convey game information. I was thinking that I would use the full screen, with UI elements ``floating'' on top with the background showing through. I haven't done up thumbnail sketches yet, but I do have a vague idea of what I want. Think of how (say) Bayonetta, Dark Souls and other modern action RPG's UI elements---I think I'd like to re-create that, but in QuickBASIC.
Anyway, that's about all I want to talk about for now. Till the next update, I suppose.
No comments:
Post a Comment