Tutorial Sketches - Explanations » History » Version 38

Giulio Moro, 2015-12-25 11:05 AM

1 1 Astrid Bin
h1.  Tutorial Sketches - Explanations 
2 1 Astrid Bin
3 38 Giulio Moro
Find the tutorial sketches in Respository > Projects, or click this link: https://code.soundsoftware.ac.uk/projects/BeagleRT/repository/show/projects
4 1 Astrid Bin
5 1 Astrid Bin
Below is a list of the sample sketches, and what they do.
6 1 Astrid Bin
7 38 Giulio Moro
h3. The structure of a Bela project
8 3 Astrid Bin
9 38 Giulio Moro
A collection of Bela files are called a "project".
10 3 Astrid Bin
11 38 Giulio Moro
If you open a project folder in the above repository, you'll see that each of these Bela project contains two files: main.cpp and render.cpp (some projects have additional files, but every project has at least these two). The main.cpp file you don't really have to worry about; it contains helper functions and things that run command line arguments. Most work is done in the render.cpp file.
12 3 Astrid Bin
13 3 Astrid Bin
h3. The structure of a render.cpp file
14 3 Astrid Bin
15 28 Andrew McPherson
A render.cpp file has three functions: @setup()@, @render()@ and @cleanup()@.
16 3 Astrid Bin
17 28 Andrew McPherson
@setup()@ is a function that runs at the beginning and is called once when the project starts.
18 3 Astrid Bin
19 28 Andrew McPherson
@render()@ is a function that is regularly called, over and over continuously, at the highest priority by the audio engine. 
20 3 Astrid Bin
21 28 Andrew McPherson
@cleanup()@ is a function that is called when the program stops, to finish up any processes that might still be running.
22 3 Astrid Bin
23 3 Astrid Bin
Here we will briefly explain each function and the structure of the render.cpp document
24 3 Astrid Bin
25 3 Astrid Bin
h3. Before any functions
26 3 Astrid Bin
27 3 Astrid Bin
At the top of the file, include any libraries you might need.
28 3 Astrid Bin
29 29 Andrew McPherson
Additionally, declare any global variables. In these tutorial sketches, all global variables are preceded by a @g@ so we always know which variables are global - @gSampleData@, for instance. It's not mandatory but is a really good way of keeping track of what's global and what isn't.
30 3 Astrid Bin
31 29 Andrew McPherson
Sometimes it's necessary to access a variable from another file, such as main.cpp. In this case, precede this variable with the keyword @extern@.
32 3 Astrid Bin
33 3 Astrid Bin
h3. Function arguments
34 3 Astrid Bin
35 29 Andrew McPherson
@setup()@, @render()@ and @cleanup()@ each take the same arguments. These are:
36 3 Astrid Bin
37 38 Giulio Moro
@0ext *context
38 3 Astrid Bin
void *userData
39 29 Andrew McPherson
@
40 30 Andrew McPherson
These arguments are pointers to data structures. The main one that's used is @context@, which is a pointer to a data structure containing lots of information you need. 
41 3 Astrid Bin
42 38 Giulio Moro
Take a look at what's in the data structure here: https://code.soundsoftware.ac.uk/projects/BeagleRT/embedded/structBeagleRTContext.html
43 3 Astrid Bin
44 30 Andrew McPherson
You can access any of these bits of information about current audio and sensor settings and pointers to data buffers that are contained in the data structure like this: @context->name_of_item@
45 3 Astrid Bin
46 30 Andrew McPherson
For example, @context->audioChannels@ returns the number of audio channels. @context->audioSampleRate@ returns the audio sample rate. @context->audioIn[n]@ would give you the current input sample (assuming that your input is mono - if it's not you will have to account for multiple channels). 
47 3 Astrid Bin
48 30 Andrew McPherson
Note that @audioIn@, @audioOut@, @analogIn@, @analogOut@ are arrays (buffers).
49 3 Astrid Bin
50 37 Giulio Moro
h2. analogDigitalDemo
51 37 Giulio Moro
52 37 Giulio Moro
This sketch showcases many different ways to write and read digital pins, including generating clocks and creating binary counters.
53 37 Giulio Moro
The code as it is will not work properly, as the direction of the pins is not set. As an exercise, you will need to set the pin mode before writing or reading the digital pins. This is for advanced users only.
54 37 Giulio Moro
55 1 Astrid Bin
h2. audio_in_FFT
56 1 Astrid Bin
57 5 Astrid Bin
This sketch performs an FFT (Fast Fourier Transform) on incoming audio. It uses the NE10 library, included at the top of the file (line 11).
58 5 Astrid Bin
59 5 Astrid Bin
Read the documentation on the NE10 library here: http://projectne10.github.io/Ne10/doc/annotated.html
60 5 Astrid Bin
61 31 Andrew McPherson
The variables @timeDomainIn@, @timeDomainOut@ and @frequencyDomain@ are variables of the struct @ne10_fft_cpx_float32_t@ (http://projectne10.github.io/Ne10/doc/structne10__fft__cpx__float32__t.html). These are declared at the top of the file (line 21), and memory is allocated for them in @setup()@ (line 41).
62 6 Astrid Bin
63 31 Andrew McPherson
In @render()@ a @for@ loop performs the FFT is performed on each sample, and the resulting output is placed on each channel.
64 5 Astrid Bin
65 1 Astrid Bin
h2. basic
66 1 Astrid Bin
67 27 Robert Jack
This sketch, better known as bleep, produces a sine tone.
68 7 Astrid Bin
69 32 Robert Jack
The frequency of the sine tone is determined in a global variable, @gFrequency@ (line 12). This is produced by incrementing the phase of a sin function on every audio frame.
70 18 Robert Jack
71 38 Giulio Moro
The important thing to notice is the nested for loop structure. You will see this in all Bela projects and in most digital audio applications. The first for loop cycles through the audio frames, the second through each of the audio channels (in this case left 0 and right 1). It is good to familiarise yourself with this structure as it is fundamental to producing sound with the system.
72 7 Astrid Bin
73 1 Astrid Bin
h2. basic_analog_input
74 1 Astrid Bin
75 27 Robert Jack
This sketch produces a sine tone, the frequency and amplitude of which are affected by data received on the analog pins. Before looping through each audio frame, we declare a value for the frequency and amplitude of our sine tone (line 55); we adjust these values by taking in data from analog sensors (for example, a potentiometer).
76 8 Astrid Bin
77 8 Astrid Bin
The important thing to notice is that audio is sampled twice as often as analog data. The audio sampling rate is 44.1kHz (44100 frames per second) and the analog sampling rate is 22.05kHz (22050 frames per second). On line 62 you might notice that we are processing the analog data and updating frequency and amplitude only on every *second* audio sample, since the analog sampling rate is half that of the audio.
78 8 Astrid Bin
79 32 Robert Jack
Note that the pin numbers are stored in the variables @gAnalogInputFrequency@ and @gAnalogInputAmplitude@. These are declared in the main.cpp file; if you look in that file you will see that they have the values of 0 and 1. Bear in mind that these are analog input pins which is a specific header!
80 9 Astrid Bin
81 1 Astrid Bin
h2. basic_analog_output
82 1 Astrid Bin
83 27 Robert Jack
This sketch uses a sine wave to drive the brightness of a series of LEDs connected to the eight analog out pins. Again you can see the nested for loop structure but this time for the analog output channels rather than the audio.
84 10 Robert Jack
85 19 Robert Jack
Within the first for loop in render we cycle through each frame in the analog output matrix. At each frame we then cycle through the analog output channels with another for loop and set the output voltage according to the phase of a sine tone that acts as an LFO. The analog output pins can provide a voltage of ~4.092V.
86 10 Robert Jack
87 32 Robert Jack
The output on each pin is set with @analogWriteFrame@ within the for loop that cycles through the analog output channels. This needs to be provided with arguments as follows @analogWriteFrame(context, n, channel, out)@. Channel is where the you give the address of the analog output pin (in this case we cycle through each pin address in the for loop), out is the variable that holds the desired output (in this case set by the sine wave).
88 10 Robert Jack
89 19 Robert Jack
Notice that the phase of the brightness cycle for each led is different. This is achieved by updating a variable that stores a relative phase value -- this is advanced by pi/4 (1/8 of a full rotation) for each channel giving each of the eight LEDs a different phase.
90 10 Robert Jack
91 1 Astrid Bin
h2. basic_blink
92 1 Astrid Bin
93 35 Robert Jack
This sketch shows the simplest case of digital out. Connect an LED in series with a 470ohm resistor between P8_07 and ground. The led is blinked on and off by setting the digital pin @HIGH@ and @LOW@ every @interval@ seconds (set it in the @render()@ function). 
94 35 Robert Jack
95 35 Robert Jack
Firstly the pin mode must be set to output mode: @pinModeFrame(context, 0, P8_07, OUTPUT);@. The output of the digital pins is set by the following code: @digitalWriteFrame(context, n, P8_07, status);@ where @status@ can be equal to either @HIGH@ or @LOW@. When set @HIGH@ the pin will give 3.3V, when set to @LOW@ 0V.
96 35 Robert Jack
97 35 Robert Jack
h2. basic_button
98 35 Robert Jack
99 35 Robert Jack
This sketch brings together digital out with digital in. The program will read a button and turn the LED on and off according to the state of the button.
100 35 Robert Jack
101 35 Robert Jack
- connect an LED in series with a 470ohm resistor between P8_07 and ground.
102 35 Robert Jack
- connect a 1k resistor to P9_03 (+3.3V),
103 35 Robert Jack
- connect the other end of the resistor to both a button and P8_08
104 35 Robert Jack
- connect the other end of the button to ground.
105 35 Robert Jack
106 35 Robert Jack
You will notice that the LED will normally stay on and will turn off as long as the button is pressed. This is due to the fact that the LED is set to the same value read at input P8_08. When the button is not pressed, P8_08 is @HIGH@ and so P8_07 is set to @HIGH@ as well, so that the LED conducts and emits light. When the button is pressed, P8_08 goes @LOW@ and P8_07 is set to @LOW@, turning off the LED.
107 35 Robert Jack
108 35 Robert Jack
As an excise try and change the code so that the LED only turns on when the button is pressed?
109 34 Robert Jack
110 1 Astrid Bin
h2. basic_network
111 1 Astrid Bin
112 17 Robert Jack
This sketch allows you to send audio and sensor data over UDP to a DAW on the host. The host needs to run Udpioplugin which you can find here https://code.soundsoftware.ac.uk/projects/udpioplugin. Note that this sketch and the accompanying plugin are still in testing.
113 16 Robert Jack
114 1 Astrid Bin
h2. basic_passthru
115 1 Astrid Bin
116 34 Robert Jack
This sketch demonstrates the simplest possible case of using audio: it passes audio input straight to audio output.
117 1 Astrid Bin
118 38 Giulio Moro
Note the nested for loop structure. You will see this in all Bela projects. The first for loop cycles through the audio frames, the second through each of the audio channels (in this case left 0 and right 1). 
119 13 Astrid Bin
120 32 Robert Jack
We write samples to the audio output buffer like this: @context->audioOut[n * context->audioChannels + ch]@ where n is the current audio frame and ch is the current channel, both provided by the nested for loop structure.
121 13 Astrid Bin
122 32 Robert Jack
We can access samples in the audio input buffer like this: @context->audioIn[n * context->audioChannels + ch]@.
123 13 Astrid Bin
124 32 Robert Jack
So a simple audio pass through is achieved by setting output buffer equal to input buffer: @context->audioOut[n * context->audioChannels + ch] = context->audioIn[n * context->audioChannels + ch]@.
125 11 Astrid Bin
126 1 Astrid Bin
h2. cape_test
127 1 Astrid Bin
128 14 Astrid Bin
This sketch is for testing purposes only. Each analog input should be connected to each analog output 0-0, 1-1, etc. The board will then produce either a 880Hz pulse if the every channel is functioning or a 220Hz continuous tone if one of the channels is not working. A message will be printed to the terminal window that details the particular channel that is not working.
129 14 Astrid Bin
130 1 Astrid Bin
h2. d-box
131 1 Astrid Bin
132 38 Giulio Moro
These files are from the d-box hackable musical instrument. See https://code.soundsoftware.ac.uk/publications/128?project_id=BeagleRT for more information.
133 15 Astrid Bin
134 1 Astrid Bin
h2. filter_FIR
135 1 Astrid Bin
136 20 Robert Jack
This sketch implements a finite impulse response filter.
137 20 Robert Jack
138 1 Astrid Bin
h2. filter_IIR
139 1 Astrid Bin
140 20 Robert Jack
This sketch implements a infinite impulse response filter.
141 20 Robert Jack
142 23 Robert Jack
h2. oscillator_bank
143 1 Astrid Bin
144 27 Robert Jack
These files demonstrate an oscillator bank implemented in assembly code that is used as part of the d-box project.
145 20 Robert Jack
146 1 Astrid Bin
h2. samples
147 20 Robert Jack
148 22 Robert Jack
This sketch shows how to playback audio samples from a buffer.
149 20 Robert Jack
150 32 Robert Jack
An audio file is loaded into a buffer @SampleData@ as @gSampleData@. This is accessed with a read pointer that is incremented at audio rate within the render function: @out += gSampleData.samples[gReadPtr++]@.
151 20 Robert Jack
152 32 Robert Jack
Note that the read pointer is stopped from incrementing past the length of the @gSampleData@. This is achieved by comparing the read pointer value against the sample length which we can access as follows: @if(gReadPtr >= gSampleData.sampleLen)@
153 20 Robert Jack
154 38 Giulio Moro
The sample is triggered by keyboard input: (a) starts sample playback, (s) stops sample playback. The triggering is treated as a lower priority task to the audio. You can see this at the bottom of the render function: @Bela_scheduleAuxiliaryTask(gTriggerSamplesTask)@;
155 1 Astrid Bin
156 1 Astrid Bin
h2. tank_wars
157 21 Robert Jack
158 22 Robert Jack
This sketch uses the analog outputs to draw a tank wars game using vector graphics. Best viewed on an analog oscilloscope.