RESULTS AND DISCUSSION

clicked. When the function is defined in the PluginEditor.cpp a conditional statement checks whether the button clicked is noteButton. If this condition is met, an if-else ladder determines the current state of emun instance noteState and assigns a corresponding lambda function to the callback object button.onClick. Each lambda function calls a method associated with the current note length which changes the state of noteState, the value of mNoteVal, noteButton colour, and noteButton text accordingly.

During the conversion from MATLAB to C++, the way that the bounds checking is accomplished is altered slightly. Because C++ is a programming language that indexes from zero, bounds checking can be achieved by taking the modulo of the read or write head against the buffer size. For any value before the read/write index meets the buffer size, ����/�����%���������� will return the current read/write index, however, when the read/write index reaches the buffer size, ����/ �����%���������� will return 0, resetting the index to the beginning of the delay line and restarting the process. This is what makes the buffers circular in the C++ implementation. This could not be attained in the same way in MATLAB as indexing starts at 0.

RESULTS AND DISCUSSION

The entirety of the testing is performed on the same two-channel delta function audio file, consisting of a regular delta function as the left channel and a delayed, attenuated delta function as the right channel (fig 2). The signal was created and used for testing in MATLAB before being rendered out as an audio file using audiowrite() and used as test audio for the final JUCE plugin.

Figure 2. Input Signal

The initial and most crucial test involves determining whether the ping pong effect has been successful i.e. are the delays bouncing back and forth between the left and right channel. For initial testing, a short simulation length of 250 samples and a short delay length of 20 samples are used. The plot in (fig 3) shows the MATLAB render for initial testing and (fig 4) shows the C++ render for comparison. The C++ render shows some minor differences in sample value as the feedback decays, but this may be attributed to the rendering process within the DAW.

Figure 3. Base Case Ping Pong Delay Algorithm MATLAB Prototype (�������������� =20)

Figure 4. Base Case Ping Pong Delay Algorithm C++ Render (�������������� =20)

Before implementing the tempo-synced delay options the algorithms for the MATLAB and C++/JUCE Plugin were tested with various hardcoded (non-tempo synced) delay time values based on seconds of

delay with min delay time = 0.1 second and max delay time = 2 seconds. The resulting plots can be observed in (appendix I).

Tests were also performed for various values of the feedback coefficient, comparing the left and right channels for both the MATLAB and C++ render. The feedback value needs to be < 1 to ensure that the output of the delay is being multiplied by a value < 1 and therefore decaying in amplitude over time (Reiss and McPherson, 2015). The resulting plots show the expected relationship between feedback value and the number of repetitions of the signal. For a larger feedback value, the impulse decays at a slower rate and therefore has many repetitions. These repetitions are theoretically infinite, though, over time, they fall below the audible range and become imperceivable (Tarr, 2019). The ping pong effect can be observed noticeably in (fig 5) for feedback = 0.9 where the distinction and alternation between the input signal’s left channel feedback and right channel feedback are evident. The same can be observed for the corresponding C++ render (fig 6).

Figure 5. Various Feedback Values MATLAB Prototype (Left Channel) (�������������� =20)

Figure 6. Various Feedback Values C++ Render (Left Channel) (�������������� =20)

Figure 7. Various Feedback Values MATLAB Prototype (Right Channel) (�������������� =20)

Figure 8. Various Feedback Values C++ Render (Left Channel) (�������������� =20)

The following plots involve the testing of the tempo-synced delay time implemented in the final JUCE plugin. For this testingphase,the expected delay timesbased on notelength and beatsPerMinute were first calculated in MATLAB, before testing whether the C++ render was producing the same results.

%Tempo-Sync beatsPerMinute = 100; %use 100bpm for all tests beatsPerSecond = beatsPerMinute/60; %find seconds per beat by taking the inverse secondsPerBeat = 1/beatsPerSecond;

noteLength = 1; % test for 0.5 = 1/8th, 1 = 1/4, 2 = 1/2 delayInSamples = fix(noteLength * secondsPerBeat * Fs);

%for 100bpm 1/8th note delay = 14400 samples 1/4 note delay = 28800 samples 1/2 note delay = 57600 samples

The C++ render plots demonstrate both the first sample of delay (fig 9) and the resulting feedback (appendix II) (the following tests were performed with a fixed feedback value of 0.5). Here, the initial sample of delay is of the most importance as the tests aim to determine whether the same delay length calculated in MATLAB is being produced in the C++ renders. It can be seen in the three C++ renders for initial delay length (fig 9, 10, 11) that the initial delay lengths are equivalent to those calculated in MATLAB. The

Figure 9. 1/8th Note Delay 100bpm C++ Render (First Sample Only) (�������������� =14400)

Figure 10. 1/4 Note Delay 100bpm C++ Render (First Sample Only) (�������������� =28800)

Figure 11. 1/2 Note Delay 100bpm C++ Render (First Sample Only) (�������������� =57600) These final plots demonstrate a comparison for 1/8th , 1/4, and 1/2 note delay lengths for left (fig 12) and right (fig 13) channels when beatsPerMinute = 100.