small changes

src/content/blog/gsoc3.md

@@ -39,12 +39,16 @@ When I first wrote my proposal, I looked at other popular code editors (like VSc
 
 Next was MIDI support, while the implementation for it was straightforward, there were a lot of problems with parameters not updating. For example, when a MIDI message changes a parameter, it won’t be updated in the interface. To fix this, I had to check if the values are the same in the [AudioProcessorValueTreeState](https://docs.juce.com/master/classAudioProcessorValueTreeState.html) which I used for storing parameter state, and the parameter state within the Faust instance. While I came up with a more efficient way of checking at the time, MIDI isn’t the only way to modify parameters. So while inefficient, it’s what my mentor, Stéphane Letz, and I have decided on.
 
-For polyphonic support, I used regular expressions to get the metadata within ```declare options```. So if the user has ```declare options "[midi:on][nvoices:n]";``` in their code (where n is the maximum number of voices that they want to use), it means that they want to use a polyphonic instrument. For more information, check out the (official documentation)[https://faustdoc.grame.fr/manual/midi/#midi-polyphony-support]. However, I was getting an “undefined effect” error when compiling, this is due to the Faust compiler itself complaining. For polyphonic instruments in Faust, the user can define an ```effect``` value which will then automatically be connected to the process. However, if the user doesn’t define it, an error will appear. Thus, I had to append a line of code to the user-defined Faust program source code to make it go away. It defines the effect to nothing: 
+For polyphonic support, I used regular expressions to get the metadata within ```declare options```. So if the user has ```declare options "[midi:on][nvoices:n]";``` in their code 
+(where n is the maximum number of voices that they want to use), it means that they want to use a polyphonic instrument. For more information, check out the (official documentation)[https://faustdoc.grame.fr/manual/midi/#midi-polyphony-support]. 
+However, I was getting an “undefined effect” error when compiling, this is due to the Faust compiler itself complaining. For polyphonic instruments in Faust, the user can define an ```effect``` value which will then automatically be connected to the process. 
+However, if the user doesn’t define it, an error will appear. Thus, I had to append a line of code to the user-defined Faust program source code to make it go away. It defines the effect to nothing, if the user doesn’t define it themselves: 
 ```
 effect = _;
 ``` 
-if the user doesn’t define it themselves. With Libfaust, there are two factory classes used to generate a Faust instance, a regular DSP factory and a polyphonic DSP factory. 
-At first, I wanted to have one factory and cast between them, but due to the polyphonic factory being a subclass of the regular factory, I could not cast upwards. So in the situation where the user compiles polyphonic code and then tries to compile without it, the program will crash. So as a solution, I included both regular and poly factories and selected the appropriate factory two depending on whether the user writes Faust code that requires polyphonic support.
+With Libfaust, there are two factory classes used to generate a Faust instance, a regular DSP factory and a polyphonic DSP factory. 
+At first, I wanted to have one factory and cast between them, but due to the polyphonic factory being a subclass of the regular factory, I could not cast upwards. So in the situation where the user compiles polyphonic code and then tries to compile without it, the program will crash. 
+So as a solution, I included both regular and poly factories and selected the appropriate factory, depending on whether the user writes Faust code that requires polyphonic support.
 # The current state
 ## Here’s what the current plugin looks like:
 ### Editor
@@ -60,7 +64,7 @@ At first, I wanted to have one factory and cast between them, but due to the pol
 
 In the original, the faust script is compiled right as it loads, and I didn’t like that. I feel like the user should have full control over when the program should compile. Thus I changed it so the user has to press the compile button for the program to compile. I have also added a start and stop button so the user can choose when they want to run the Faust program, as opposed to starting right away.
 
-There’s also a new MIDI keyboard section that the user can use, just in case the DAW/or whatever the user is using doesn’t have a virtual keyboard.
+There’s also a new MIDI keyboard section that the user can use, just in case user's audio plugin host doesn’t have a virtual keyboard.
 
 For polyphonic and MIDI, the plugin should know automatically if they are required through the use of metadata like this:
 ```