audio device

This commit is contained in:
sejo 2021-10-12 20:22:33 -05:00
parent d2e771005e
commit 340e6d1032
1 changed files with 270 additions and 3 deletions

View File

@ -197,7 +197,7 @@ it has several fields that we can read, all of them based on the current system
* the year short corresponds to the number of year in the so called common era
* the month byte counts the months since january (i.e. january is 0, february 1, and so on)
* the day byte counts the days starting from 1
* the day byte counts the days in the month starting from 1
* the hour, minute and second bytes correspond to what one would expect
* dotw (day of the week) is a byte counts the days since sunday (i.e sunday is 0, monday is 1, and so on)
* doty (day of the year) is a byte counts the days since january 1 (i.e. jan 1st is 0, jan 2nd is 1, and so on)
@ -219,9 +219,276 @@ remember that for timing with a little bit more resolution, you can count the ti
# the audio device
at last, the audio device!
at last, the audio device! or i should say, the audio devices!
varvara has four identical stereo devices (or "channels"), that get mixed before going into the speakers/headphones:
```
|30 @Audio0 [ &vector $2 &position $2 &output $1 &pad $3 &adsr $2 &length $2 &addr $2 &volume $1 &pitch $1 ]
|40 @Audio1 [ &vector $2 &position $2 &output $1 &pad $3 &adsr $2 &length $2 &addr $2 &volume $1 &pitch $1 ]
|50 @Audio2 [ &vector $2 &position $2 &output $1 &pad $3 &adsr $2 &length $2 &addr $2 &volume $1 &pitch $1 ]
|60 @Audio3 [ &vector $2 &position $2 &output $1 &pad $3 &adsr $2 &length $2 &addr $2 &volume $1 &pitch $1 ]
```
similar to how in the screen device we can draw by pointing to addresses with sprite data, in the audio devices we will be able to play sounds by pointing to addresses with audio data ("samples").
stretching the analogy: similar to how we can draw sprites in different positions on the screen, we can play our samples at different rates, volume, and envelopes.
we'll briefly discuss these concepts in order to use them, assuming that you might not be familiar with them.
## samples
as we mentioned above, we can think of the sample data as the equivalent of sprite data.
they have to be in program memory, they have a specific length, and we can refer to them by labels.
the audio.channels.tal example in the uxn repository, has several of them, all of them 256 bytes long:
```
@saw
0003 0609 0c0f 1215 181b 1e21 2427 2a2d
3033 3639 3b3e 4143 4649 4b4e 5052 5557
595b 5e60 6264 6667 696b 6c6e 7071 7274
7576 7778 797a 7b7b 7c7d 7d7e 7e7e 7e7e
7f7e 7e7e 7e7e 7d7d 7c7b 7b7a 7978 7776
7574 7271 706e 6c6b 6967 6664 6260 5e5b
5957 5552 504e 4b49 4643 413e 3b39 3633
302d 2a27 2421 1e1b 1815 120f 0c09 0603
00fd faf7 f4f1 eeeb e8e5 e2df dcd9 d6d3
d0cd cac7 c5c2 bfbd bab7 b5b2 b0ae aba9
a7a5 a2a0 9e9c 9a99 9795 9492 908f 8e8c
8b8a 8988 8786 8585 8483 8382 8282 8282
8182 8282 8282 8383 8485 8586 8788 898a
8b8c 8e8f 9092 9495 9799 9a9c 9ea0 a2a5
a7a9 abae b0b2 b5b7 babd bfc2 c5c7 cacd
d0d3 d6d9 dcdf e2e5 e8eb eef1 f4f7 fafd
@tri
8082 8486 888a 8c8e 9092 9496 989a 9c9e
a0a2 a4a6 a8aa acae b0b2 b4b6 b8ba bcbe
c0c2 c4c6 c8ca ccce d0d2 d4d6 d8da dcde
e0e2 e4e6 e8ea ecee f0f2 f4f6 f8fa fcfe
fffd fbf9 f7f5 f3f1 efed ebe9 e7e5 e3e1
dfdd dbd9 d7d5 d3d1 cfcd cbc9 c7c5 c3c1
bfbd bbb9 b7b5 b3b1 afad aba9 a7a5 a3a1
9f9d 9b99 9795 9391 8f8d 8b89 8785 8381
7f7d 7b79 7775 7371 6f6d 6b69 6765 6361
5f5d 5b59 5755 5351 4f4d 4b49 4745 4341
3f3d 3b39 3735 3331 2f2d 2b29 2725 2321
1f1d 1b19 1715 1311 0f0d 0b09 0705 0301
0103 0507 090b 0d0f 1113 1517 191b 1d1f
2123 2527 292b 2d2f 3133 3537 393b 3d3f
4143 4547 494b 4d4f 5153 5557 595b 5d5f
6163 6567 696b 6d6f 7173 7577 797b 7d7f
@sin
8083 8689 8c8f 9295 989b 9ea1 a4a7 aaad
b0b3 b6b9 bbbe c1c3 c6c9 cbce d0d2 d5d7
d9db dee0 e2e4 e6e7 e9eb ecee f0f1 f2f4
f5f6 f7f8 f9fa fbfb fcfd fdfe fefe fefe
fffe fefe fefe fdfd fcfb fbfa f9f8 f7f6
f5f4 f2f1 f0ee eceb e9e7 e6e4 e2e0 dedb
d9d7 d5d2 d0ce cbc9 c6c3 c1be bbb9 b6b3
b0ad aaa7 a4a1 9e9b 9895 928f 8c89 8683
807d 7a77 7471 6e6b 6865 625f 5c59 5653
504d 4a47 4542 3f3d 3a37 3532 302e 2b29
2725 2220 1e1c 1a19 1715 1412 100f 0e0c
0b0a 0908 0706 0505 0403 0302 0202 0202
0102 0202 0202 0303 0405 0506 0708 090a
0b0c 0e0f 1012 1415 1719 1a1c 1e20 2225
2729 2b2e 3032 3537 3a3d 3f42 4547 4a4d
5053 5659 5c5f 6265 686b 6e71 7477 7a7d
@piano
8182 8588 8d91 959b a1a6 aaad b2b5 b8bd
c1c7 cbd0 d5d9 dde1 e5e5 e4e4 e1dc d7d1
cbc5 bfb8 b2ac a6a2 9c97 928d 8884 807c
7977 7574 7372 7272 7273 7372 706d 6964
605b 5650 4d49 4643 4342 4244 4548 4a4d
5052 5556 5758 5554 5150 4c4a 4744 423f
3d3c 3a38 3835 3431 3030 2f31 3336 393e
4449 4e54 5a60 666b 7175 7b82 8990 989e
a6ab b1b6 babd bebf bfbe bbb9 b6b3 b0ae
aaa8 a6a3 a19e 9c9a 9997 9696 9798 9b9e
a1a4 a6a9 a9ac adad adae aeaf b0b0 b1b1
b3b3 b4b4 b4b3 b3b1 b0ad abab a9a9 a8a8
a7a5 a19d 9891 8b84 7e77 726e 6b6b 6b6c
6f71 7477 7776 7370 6c65 5e56 4e48 423f
3d3c 3b3a 3a39 3838 3839 393a 3c3e 4146
4a50 575b 6064 686a 6e70 7274 7677 7a7d
```
=> https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/examples/devices/audio.channels.tal audio.chanels.tal source code
and what do these numbers mean?
in the context of varvara, we can understand them as multiple unsigned bytes (u8) that correspond to amplitudes of the sound wave that compose the sample. a "playhead" visits each of these numbers for a given time, and uses them to set the amplitude of the sound.
for example, in the case of the saw sample, if we look at it as single bytes instead of shorts, we can see that it consists in a series of numbers going from 00 to fd, increasing by 03 at a time:
```
@saw ( as single bytes )
00 03 06 09 0c 0f 12 15 18 1b 1e 21 24 27 2a 2d
( etc )
```
the sound wave will have the shape of a ramp going up over time. and if we loop it, over time we would have a ramp going up, and then returning quickly to 00, multiple times: i.e. a "sawtooth" shape.
similar to how we have dealt with sprites and with the file device above, in order to set a sample in the audio device, we just have to write its address and its length:
```
;saw .Audio0/addr DEO2 ( set sample address )
#0100 .Audio0/length DEO2 ( set sample length )
```
the frequency at which this sample is played (i.e. at which the wave amplitude takes the value from the next byte) is determined by the pitch byte.
## pitch
the pitch byte is similar to the sprite byte in that it makes the sample start playing whenever we write to it.
the first 7 bits (from right to left) of the byte correspond to a midi note (and therefore to the frequency at which the sample will be played), and the eighth bit is a flag: when it's 0 the sample will be looped, and when it's 1 it won't.
normally we will want to loop the sample in order to generate a tone based on it. only when the sample is long enough it will make sense to not loop it.
regarding the midi note bits, it's a good idea to have a midi table around to see the hexadecimal values corresponding to different notes.
=> https://wiki.xxiivv.com/site/midi.html midi table
middle C (C4, or 3c in midi) is assumed to be the default pitch of the samples.
so in theory, the following program should play our sample at that frequency, or not?
```
( hello-sound.tal )
( devices )
|30 @Audio0 [ &vector $2 &position $2 &output $1 &pad $3 &adsr $2 &length $2 &addr $2 &volume $1 &pitch $1 ]
( main program )
|0100
;saw .Audio0/addr DEO2 ( set sample address )
#0100 .Audio0/length DEO2 ( set sample length )
#3c .Audio0/pitch DEO ( set pitch as middle C )
BRK
```
almost there! in order to actually hear the sound, we need two more things: to set the volume of the device, and to set the ADSR envelope!
## volume
the volume byte is divided in two nibbles: the high nibble corresponds to the volume of the left channel, and the low nibble corresponds to the volume of the right channel.
therefore, each channel has 16 possible levels: 0 is the minimum, and f the maximum.
the following would set the maximum volume in the device:
```
#ff .Audio0/volume DEO ( set maximum volume in left and right )
```
## ADSR envelope
the last component we need in order to play audio, is the ADSR envelope.
ADSR stands for attack, decay, sustain, and release. it is the name of a common "envelope" that modulates the amplitude of a sound from beginning to end.
in the varvara computer, the ADSR components work as follows:
* the attack section is the time that it takes to bring the amplitude of the playing sound from 0 to 100%.
* then, the decay section is the time that it takes to bring the amplitude from 100% to 50%
* then, during the sustain section the amplitude is kept at 50%
* and finally, in the release section the amplitude goes from 50% to 0%.
each of these transitions are done linearly.
in the ADSR short, there is one nibble for each of the components: therefore each one can have a duration from 0 to f.
the units for these durations are 15ths of a second. for example, if the duration of the attack component is 'f', then it will last one second.
the following will set the maximum duration on each of the components, making the sound last 4 seconds:
```
#ffff .Audio0/adsr
```
ok, so now we are ready to play the sound!
## playing the sample
the following program has now the five components we need in order to play a sound: a sample address, its length, the adsr durations, the volume, and its pitch!
```
( hello-sound.tal )
( devices )
|30 @Audio0 [ &vector $2 &position $2 &output $1 &pad $3 &adsr $2 &length $2 &addr $2 &volume $1 &pitch $1 ]
( main program )
|0100
;saw .Audio0/addr DEO2 ( set sample address )
#0100 .Audio0/length DEO2 ( set sample length )
#ffff .Audio0/adsr DEO2 ( set envelope )
#ff .Audio0/volume DEO ( set maximum volume )
#3c .Audio0/pitch DEO ( set pitch as middle C )
BRK
```
note (!) that it will play the sound only once, and it does it when the program starts.
i invite you to experiment with the ADSR values: how does the sound change when there's only one of them? or when all of them are small numbers? or with different combinations of durations?
also, try changing the pitch byte: does it correspond with the midi values as expected?
and how does the sound changes when you use a different sample? can you find or create different ones?
## playing more than once
once we have set up our audio device with a sample, length, ADSR envelope and volume, we could play it again and again only by (re)writing a pitch at a different moment.
keep in mind that every time you write a pitch, the playback of the sample and the shape of the envelope starts over.
what if you implement playing different pitches by pressing different keys on the keyboard? you could use our previous examples, but writing a pitch to the device instead of e.g. incrementing a coordinate :)
or what about complementing our pong program from <(uxn tutorial day 6)> with sound, having the device playing a sound whenever there's a bounce of the ball?
or what if you use the screen vector to time the repetitive playing of a note? or what about you have it play a melody by following a sequence of notes? could this sequence come from a text file? :)
## playback information
the audio device provides us with two ways of checking during runtime the state of the playback:
* the position short
* the output byte
when we read the position short, we get the current position of the "playhead" in the sample, starting from 0 (i.e. the playhead is at the beginning of the sample) and ending at the sample length minus one.
the output byte allows us to read the amplitude of the envelope. it returns 0 when the sample is not playing, so it can be used as a way of knowing that the playback has ended.
## polyphony
the idea of having four audio devices is that we can have all of them play at once, and each one can have a different sample, ADSR envelope, volume, and pitch.
this gives us many more possibilities: maybe in a game there could be a melody playing in the background along with incidental sounds related to the gameplay? maybe you can build a sequencer where you can control the four devices as different tracks? or maybe you create a livecoding platform to have a dialog with each of the four instruments?
in any case, don't hesitate to share what you create! :)
# the end
hey! you made it to the end of the tutorial series! congratulations!
i hope you enjoyed it and i hope you see it just as the start of your uxn journey!
we'd love to see what you create! don't hesitate to share it in mastodon, the forum, or in the irc channel (or even via e-mail!)
=> https://llllllll.co/t/uxn-virtual-computer/ uxn in lines forum
=> ./contact.gmi {contact}
irc channel: #uxn on irc.esper.net
but before doing all this, don't forget to take a break! :)
see you around!
# support
if you found this tutorial to be helpful, consider sharing it and giving it your <(support)> :)
if you enjoyed this tutorial and found it helpful, consider sharing it and giving it your <(support)> :)