| |
lft
Registered: Jul 2007
Posts: 369 |
Playroutine coding: A new way to represent pitch
Introducing the 9-bit pitch technique:
http://www.linusakesson.net/programming/9bitpitch/index.php |
|
... 24 posts hidden. Click here to view all posts....
|
| |
algorithm
Registered: May 2002
Posts: 707 |
@mixer. Things get a bit more fiddly if you are mixing more data into a single channel. One of the fastest approaches this way is probably to have fixed sample rate and have 8 interval based adds from a pitch table to the sample pointer which should allow pitch changing in around 5hz increments. This is an approach I am using in my new sine based Amiga decoder which can mix 16 channels at 14khz on 68000. |
| |
lft
Registered: Jul 2007
Posts: 369 |
soci: With that approach, the conversion is certainly easier to grasp.
But it would be slow for three reasons:
1. The octave shifting itself. A 96-semitone range would involve a maximum shift of seven. That's 7 * 12 = 84 cycles with a straightforward implementation.
2. Decoding the 11-bit pitch value into an octave and a note index within that octave. This is basically division and modulo by 12 performed on the MSB. If you handcode it, you still need three compares with branches, for a total of 15 cycles. Then you need to combine the four-bit remainder with the three least significant bits to obtain the correct table index, which is 21 cycles with straightforward code.
So far that's 120 cycles per voice, compared to 46 using my approach (with the similarly-sized table).
But the real killer is probably this:
3. All the rest of your playroutine needs to work with 16-bit math. Granted, code that transposes by whole-semitone offsets only needs to deal with the MSB. But if you do arpeggios that way, you can't reuse the arpeggio engine to get vibrato for free, as in my approach.
The real strength with the 9-bit technique is that all computations in the playroutine work with 8-bit numbers, and then the two resulting 8-bit values are combined into a 9-bit sum right at the end.
So while the conversion routine itself is a bit cryptic, the rest of the code becomes cleaner and easier to follow. And everything gets faster. |
| |
Stone
Registered: Oct 2006
Posts: 176 |
I have thought about implementing microtone frequency tables myself, but I thought there would be too much overhead. Your ideas about table folding and base_pitch+offset_pitch have convinced me that I have to try this! Excellent work, lft! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1423 |
Working with log(frequency) until the last minute is indeed an excellent plan.
Just a thought though - most parts don't span more than an octave or two, three at most; why not have each instrument have an implied base-note, then use (eg) 240*log(frequency/base)/log(4), to have ten steps per semitone over two octaves, happily fitting within 8 bits? |
| |
Mixer
Registered: Apr 2008
Posts: 460 |
Regarding the 16 step semitone, 192 long table. http://6581.fi/sidwiki/doku.php?id=sid-knowledge has a section Expanded note table, that has an old example of the 192 long octave table discussed.
It uses 8.4 bits system per note, arpeggio and transpose only add to high byte. Vibrato and slides use low byte also.
Solution is split to two functions, first one figures out what the 8.4 bit note value is after all the pitch effects and second function translates that into a frequency value within some octave and then shifts the value depending on the octave value.
You can see how fast/slow that is. |
| |
Hein
Registered: Apr 2004
Posts: 964 |
Interesting. The base_pitch and offset_pitch need to be converted from regular 12-tet values to usable 48-tet values, if you'd want to provide musicians the conventional arpeggio tables/pattern notes, right?
I've also been thinking about microtonal music (esp. middle east stuff) but always thought this would either need a big frequency table or an additional quarter-note finetune command, if it's a 24-tet scale. Maybe I should fiddle with the 9-bit method. It's just that mastering microtonal music doesn't seem easy and requires alot of practice. I've found some nice info and examples at http://www.maqamworld.com. |
| |
Hate Bush
Registered: Jul 2002
Posts: 469 |
some great resource on Arabic music there, Hein - thanks! |
| |
lft
Registered: Jul 2007
Posts: 369 |
Hein: That's right, the user could still use normal C-1, C#1... syntax, and these are converted to integers in the normal way. Then the integers are shifted two steps to the left. |
| |
Perplex
Registered: Feb 2009
Posts: 257 |
Has anyone implemented or considered implementing an editor and player for 31-tet music? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1423 |
Perplex, I wasn't familiar with 31 equal temperament before today. It does seem to present something of a sweet spot for interval accuracy.
Personally I've occasionally considered leaning towards just specifying frequency per note - everything beyond that is just data compression, and arguably shouldn't be musician-facing. If they want a perfect fifth, give them a perfect fifth! Generating tables of frequencies used should be a compile time operation, not a musical constraint.
31-tet does look like an intriguing abstraction, mind, as well as fitting nicely in five bits. |
| Previous - 1 | 2 | 3 | 4 - Next |
