Re: Octode on Arduino
For this particular application I didn't need to know exact cycle count or do assembly optimization. If I was to write AVR assembly code by hand, I sure would know how many cycles it takes - it is common practice to memorize opcode cycles (super easy on AVR), and count them in time critical parts when writing for 8/16 bit systems in assembler.
AVRs are like a 8 bit computer + peripherals, you might soon meet the situation where you would have to know the number of cycles between two events or between two conditions of the system.
I memorized a lot of Z80 opcode cycles and opcodes back in the 80s, I could write 20-30 byte long (or short? :-) ) routines directly in hex - without loading the assembler (Zeus or GENS). Now I still remember only #c9 and a few more opcodes.
What I needed was just to see compiler generated code, to check if particular changes in C code makes resulting code longer or shorter, which is totally enough to estimate efficiency of edits - another common practice when writing for 8/16 bit systems in C. It is super simple task, I don't see why it should be overcomplicated like that with all that porting to other environments, using simulators, debuggers, and stuff like that.
Well... Could you notice the interrupt happening just in between loading or storing the 2-byte variable and ruining the result by just observing the code? ;-)
), the vast majority of users prefer trackers nowadays. And this kind of sheet-music oriented format does not lend itself well to a tracker implementation, since trackers don't care about note lengths. It might be worth considering to "inverse" the length format, so that t1 would be the smallest unit (ie. semi-quaver). This way, it'd be still relatively convenient for transcribing sheet music, while at the same time making tracker support a little easier. The other thing you have to worry about is row transition length. The more complex the data format, the more time you need to decode it - time that you can't spend on synthesis. It's normally not such a big issue with PFM-based synthesis, but once you get into pulse-interleaving/volume faking, you will notice a significant impact on the sound quality. Of course, with something like 10 channels, you have to start worrying about data size as well (so it would make sense to have patterns per channel instead of one pattern for all channels). But for 2 channels, I find split patterns aren't worth it in most cases.
