Software section:

Last week, I finished the recording feature. But because the code was copied directly from the web, some of its functionality was not met by our project and some of the code needed to be changed to implement other sub-functions that we had planned.

• Naming of audio files. I found that the name of the audio file generated in the original code was a long string of letters. After looking at the code, I found that only the first few letters of the filename can be changed. For example, the part of the diagram that can be changed is "rec_". The next eight letters are randomly generated and the letters are different each time the recording file is generated. But after looking at the code I didn't see that the relevant information was describing how to generate random numbers.

• Storage location of audio files. We have set up a number of folders to store audio, such as "dropper", "test tube", "beaker" and "jar", to make the process easier to understand. This part of the code does the following: (a) store the resulting audio files in "dropper"; cut the audio files in "dropper" to "test tube"; cut the audio files in "test tube" to "beaker"; copy the audio files in "jar" to "beaker". These file moving features are what I need to be done in the next phase.
• Button controls. The original code was set to CTRL+C to pause the recording. To make it easier and more controllable to connect the Arduino later, when designing the keys, we need to change two keys to the spacebar to control the recording function. After I looked at the corresponding code, I did not find the relevant code. After querying the relevant code, I suspected that the MODE parameter might be related to user control, but after several attempts I did not find a relevant solution.

• Duration of recording. In our original design, the duration of the recording was determined by how long the user pressed the dropper. In the code section, however, there is no relevant code found about how the user can control the recording duration by pressing a button. So, after our discussion, this part of the code design will be deferred to the next iteration of the process, where we first default the sound recording time to a fixed value (temporarily set at 10s). This will not affect subsequent development progress.

In addition to these software features, I had some problems with the module installation. pyaudio could not be installed. The reason for this problem is that "portaudio.h could not be found". After I ruled out a lot of possible reasons, it turns out that it might have something to do with the way I installed portaudio. I installed it according to the method given on the official website (via visual studio) (http://portaudio.com/docs/v19-doxydocs/compile_windows.html), and the downloaded files are placed on the desktop, so if you install it via the pip command, your computer may not automatically recognize the relevant folder. I later saw in a user's comment that being able to install the WHL file was a good way to do so directly. Since the latest version of the official WHL file is currently 3.6 and my Python version is 3.8, this means that the latest version is not supported. I later downloaded the available WHL on an unofficial channel, but the installation still failed because the WHL file could not be recognized. Eventually, I found a Chinese version of the explanation document (https://blog.csdn.net/DeniuHe/article/details/77163482) and went through the installation according to its flow, but it also wasted a lot of my time.

During the installation period, I also tried to use other development environments PyCharm, the previous ones being Python IDLE, which was recommended by lecturer during a previous course of Introduction of Software. However, at this point in time, it's not the most ideal development environment because:

(a) it can't automatically identify and adjust errors/part of the code, which results in wasting a lot of time looking at the wrong code when rewriting it;

(b) it can't collapse the function content, which is also the most painful part for me because the software part has more functions, so it's hard to find a function quickly;

(c) it can't install some special modules, if I need to use a special module, such as pyaudio, then I need to search the tutorial and install, which wastes a lot of my time, but there are many ways to install these modules quickly in PyCharm.

But in the end the reason I didn't use Pycharm was still because I couldn't search for the corresponding WHL, but based on reason a and b, I generally use a combination of the two for development. Write the code in Pycharm and copy it to IDLE to run. Although this approach is more complex, it has helped me to some extent to improve my success rate in writing code.

Physical section:

We met and corresponded with each device, function and sensor. Since in the first phase we only needed to complete the core functions, we removed some functions for the time being (play and delete functions in the test tube) because the type of sensor we had didn't allow us to complete all functions. Although we also tried to replace these two functions with other sensors, such as photoresistors, we decided to drop them for now after some discussion (the reason: in concept we use vibration sensors, but we don't currently have them, and in the future we could use tilt switches instead of vibration sensors - this is still being discussed)

Next week:

• Combine with software parts written by other team members and complete the main() to mobilize all instructions
• Clarify the arduino's instructions
• Completion of physical connections
• Completion of documentation