Author: yucongw

Over thanksgiving, I found out that the mouse click processed based on the location on the screen. While it is possible to hardcode some of the buttons we want with mimicking a click at a specific location, the sheet music rescales as more notes are being added, so it become essentially impossible to hardcode that. After discussing this issue with the TA and my teammates, we found out that MuseScore has built in keyboard shortcuts that I can use.

This week I looked into how these keyboard presses are implemented, and find out they are implemented through the Qt package that I installed to run the application with. I read the official documentation because unfortunately the application does not make the function call to the function I want to be calling in my code, and the package all come in executable format. I was able to find out how to call the function, but is unable to verify if that is correct yet.

I finished implementing the algorithm part in my code, and tested it with some sample test cases. It now outputs a line saying which note, note type (e.g. whole) is being pressed for (lightly, medium, hard) on command line, and this also gets written to an output file in real time so the data can be saved.

I had a meeting with Olek where we integrated our separate parts of the code together, that went relatively smooth and we can now read in inputs from the pi (currently randomly generated) and convert that to outputs in the command line through my code.

I tried to compile my part of the code with the application, but the application compilation is too complicated and I have not made significant progress on how to modify the make file to make everything integrated correctly.

Next week I will be focusing on working on the final presentation (on Sunday) as I am the main presenter for this presentation. I will also keep working on integration with the MuseScore application, if not trying to rescope the project for an alternative solution. I am not as on schedule as I would like as the application turns out to be much different than I expected, but I am relatively happy with what I have so far in terms of having the code I wrote working correctly.

This week I focused mostly on trying to find where to inject our code section into the API. This ended up being much harder than I expected as they do not have very well written documentation online, the documentations I was able to find were very random, and either contained no useful information or just outdated and wrong information. It took me quite a while to figure it out but I ended up finding where to add our code to. Next week I am hoping to be able to run the system on some sample inputs to display them on the screen.

This week I was out during both classes for my lab’s retreat so I did not participate in the interim demo with the rest of my group mates. I did a separate demo for my part with the profs and the TA to update them on what I have accomplished.
Aside from attending the retreat, I did more code base exploration and has successfully located where I would be connecting my code section with the API. Other than that, I wrote more code on processing the inputs from raspberry pi to incorporate the previous sliding window implementation that I completed.
I am more caught up to date with my previous planned schedule now. Next week I am hoping to finish the software system code and hopefully be able to connect my code with the API, and able to put notes on the sheet with test inputs generated from the python script.

Now that you are entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run.  In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?
I have written sample python scripts that will generate fake test cases that resembles inputs from the raspberry pi. I am expecting that the sample test case generated will have 100% accuracy to be translated into notes on the sheet music, as all of our errors are expected to be coming from sensor and data processing on the raspberry pi.

I made quite descent progress on the project this week. After a lot of struggle with the code base, the dependencies and some logistics things with the new M2 chip and apple architecture, I was able to finally successfully compile the code from the MuseScore API and have it up and running on my machine locally. I also had a meeting with Olek and we discussed and came up with the architecture design of how the data is going to be transferred from the rasper Pi to the API on my machine. At the same time, I am working on writing some sample code on how to process the code from the pi into sample input into the API.

I think I have caught up a little bit in my progress. I will not be attending class next week because I will be going to pdl retreat. I wish to dig more at the code base and start connection the code with the API next week.

This week I focused mostly on evaluate the ethic concerns about our projects. I brainstormed some possible scenarios where our projects can be used with malicious intent and how to prevent these situations from happening. I also evaluated the idea of using different components in our design to potentially eliminate the potential harm.
Other than the ethics component, I looked at some official documents of how the API is being composed and set up. I also looked at some part of the API source code but has not finished looking at everything yet.
I made descent progress this week, but a lot more needs to be done with regards to the software API component. Next week I plan to continue the work with the API and move on to see how additional code can fit with the API.

Last week, our primary focus was on the composition of the design review report document. I have made significant progress, contributing to sections such as the Abstract, Introduction, use-case requirements, and the relevant software subsystem within the design requirements. Additionally, I have worked on sections covering design traits, system implementation, and testing and verification.

However, there has been a slight delay in the schedule, particularly in completing the initial setup of the API interface, which remains a work in progress. To mitigate this delay, I intend to allocate more time in the coming week to expedite the API preparation and align with our project timeline.

In the upcoming week, my goal is to finalize the exploration of the API’s functionality and engage in discussions with my team members to strategize and ensure the seamless cohesion of our project components. This collaborative effort will be instrumental in achieving our project milestones.

 

As you’ve now established a set of sub-systems necessary to implement your project, what new tools are you looking into learning so you are able to accomplish your planned tasks?

As for my role in the software system, my primary focus involves mastering the MuseScore API and its integration within the project. While it may not be a completely novel tool, this endeavor entails gaining a deeper understanding of the API and effectively utilizing it to set up a comprehensive system. Personally, I have limited prior experience with configuring an entire system using an API, making this a notable learning curve and a unique challenge that I am committed to overcoming.

This week we mostly focused on the design presentation during class. We presented our presentation and received some valuable feedback on the content in our presentation. me and the teammates discussed the choice of some of the hardware component that we plan to be using in our design, and based on these choices, I placed an order for the keyboard that we plan to build our project on. I also did more digging in the code base for the API MuseScore, as well as how the signal from the raspberry pi is going to look like / connect to the software component.

This week we focused on completing the design presentation as well as nail down some of the details in the design.
I completed the Use Case/Application/Design Requirement, Test, Verification and Validation slides as well as the software data processing side and the software components of the block diagram in the presentation.
I also forked the open source repo MuseScore and started looking at how the different files in the repository works together and where we can add our implementation into the repo.