>>13207
I base my work on resources I have read, along with my own research. Main works cited are:
"Voice Processing And Synthesis By Performance Sampling And Spectral Models" by Jordy Bonada
"Understanding Digital Signal Processing", Third Edition, by Richard G. Lyons (RIP)
"The Science Of The Singing Voice" by Johan Sundberg
In addition to these, I have read many dozens of other papers and theses. Also, I have done my own research. Although I am still working on it, and a lot of it has yet to be tested, I think I may have made some improvements in areas. A big reason for how I have been able to achieve this was actually because I was so quick to cast doubt on my own work. Originally, I thought I had come up with a brilliant innovation. One night, from looking at figures, I actually had a little bit of doubt. Instead of just brushing it aside, I spent hours obsessing over minute details in figures. Eventually, I re-read some things and then I came to the conclusion that my algorithm was based on a fundamental misunderstanding of how the voice system works (although it would actually work some types of sound sources; for example a theramin).
I think about a week later, I was back with a new idea. Long story short, this was also wrong. I spent a good portion of a day experimenting and seeing it all break down, which on the other hand strengthened my understanding. As I went to bed, feeling a bit devastated. I began thinking about ideal trains of voice pulses. This led me to come up with a rough idea that the harmonics of a series of overlapping pulses are exactly equal to a sampling of the spectrum of a single pulse. This made me feel a lot better. The next day, I wrote down a proof in LaTeX. A few days later, I came up with a third iteration of the solution to this particular problem. A few days later, I came up with a better idea. A few weeks later, and I came up with an even better idea based on the same principle. Since then, it has stayed mostly the same, although with a few minor tweaks. I think it should work now, although it is still not implemented.
This is an example of just one of many things I have worked on within this project.
>To find mistakes in your code, for example.
I've been hearing a lot from people that LLMs can find the sort of bugs people miss for decades. I very recently caved and decided to run an LLM on most of the codebase. I posed not as myself but as an external reviewer. Needless to say, it found some issues. Many were "pedantic", but this was actually kind of what I wanted to find. There were some false detections. On the other hand, there were some real bugs I thought were false detections at first. Anyway, I should note that every issue that was found were basically minor programming mistakes, but no issues with the program design itself or the algorithms used.
Anyway, what I did was I compiled a list of all the issues it found and began looking through them. In the process of fixing the issues, I actually found several more issues, which I also fixed.
>Or to explain stuff to you. Like when instead of actually reading the documentation you just ask an LLM.down
Not really applicable, since the main library does not have any dependencies. The GUI toolkit uses FLTK, but FLTK has pretty good documentation, which I've read a good amount of.
