Mostly a documentation week this week. Updated the project page, the demo video, and the home page to now reflect the massive changes made to the EQ. I also went through and made a professional GitHub README and put up the 1.0.0 release of the Semi-Pro-Q. Super satisfying to have this done and I'm so proud of it.

The majority of my week aside from the documentation has been taken up by some severe car trouble that needed solving and some interviews and applications for the job front.

Things are moving forward for the next project well though. Currently it is just ideas, basic architecture, and a list of which tools I will be using for the next project. What I have so far is that I want to make an audio visualizer for a Raspberry Pi. So, this will require a module to take in the audio samples, something to analyze peak, RMS, and FFT of the audio, then use a limited version of OpenGL to make shaders to visualize based on the hardware, and pass that audio and video through the HDMI port of the Pi. I'm really excited about this. It will give me 3 skills I have been looking forward to progressing: Linux Development, Hardware-based development, and OpenGL.

Looking forward to first steps of the next project next week, once this car is back up and running.

The final boss of this project really wound up being the spectrum analyser. Who would have thought? Well, I guess I kinda figured and thats why I saved it for last. Tons of work done this week. Focus was on the analyser, but also on finalizing input/output validation, which came out great on 3 separate DAWS. I really think I'm going to let the completed section speak for itself this week. All thats left on this now is a bit of refactoring, waiting on the logo/icon to come in, and a quick rebuild for a mono version. Then I'll fully update the home page to reflect how much better this thing is.

I really can't stress how happy I am with this plugin. For years, all I have wanted to do was make cool stuff on my computer, and this last month has been spent making the exact EQ I want to use. Now its onto the next thing with a super cool idea I have for what to do with this Raspberry Pi my partner got for me.

Below are some images of some of the white noise and pink noise test results.

They show exactly what they should given the goals of the analyser: 4.5 dB/octave slope, +12dB, and scaling according to the peak meters

Completed This Week:

Filter Architecture Refactor:

• Completely restructured filter/coefficients system to match ProcessorDuplicator/Filter/Coefficients setup with a more logical stage->filter->eq architecture
• Implemented idiot-proof interface with only four interaction methods (prepare, process, readCoeffs, update)
• Conducted massive refactor to ensure thread-safety and proper encapsulation. Its down to 0.5 kb per filter exactly, which was super satisfying

Spectrum Analyzer Improvements:

• Eliminated DC offset issue and fine-tuned smoothing parameters for clearer visual response
• Increased FFT_SIZE to 8192 for superior visual quality despite computational expense
• Implemented per-pixel calculations with cubic interpolation for the first half of the spectrum and RMS averaging for remaining bins
• Added 4.5 dB/octave tilt to better match music-focused analyzers
• Implemented dynamic scaling based on peak meter scaling plus ~12 dB offset for improved visualization
• Configured frame updates to refresh at 1/FFT_HOPS * FFT_SIZE with 75% window overlap
• Added timer callback functionality to paint next lerped value for smoother real-time feedback

Component Architecture & UI Enhancements:

• Created reusable MinimizableComponent class to handle minimize/maximize functionality across multiple components
• MinimizableComponent also houses the drag functionality for moving the components anywhere in the window
• Added ValueTree property storage for component positions with proper save/load serialization
• Replaced expensive label components with optimized black rectangles with white text for better performance

Comprehensive Validation & Testing:

• Validated peak meter, EQ interactions, gain interactions, button interactions, response curve, and spectrum analyzer
• Tested automation and bus channel routing across Studio One, Ableton Live, and Reaper
• Confirmed settings and state serialization functioning correctly
• Verified total memory usage from custom code remains below 0.5 MB

Parameter & Settings Updates:

• Extended all filter gain parameters to allow up to +24 dB boost

2 of my 3 big ticket items are done from last week, with a lot of progress on the 3rd. Zipper noise and parameter change clicks are now entirely removed, which is huge. The spectrum analyzer still shows minor inconsistencies in the low end, but it’s noticeably more stable, a bit faster, and much prettier than it was a week ago.

To follow up from last week's issues:

1. Response curve rendering no longer exhibits issues associated with high slopes. This turned out not to be a graphics problem at all. The curve was just too honest, exposing some inherent shortcomings of high-Q digital filters at very low frequencies.
2. Spectral analysis still shows occasional inconsistencies after extensive testing, but far fewer than before. Along the way, the component received major optimizations and quality improvements.
3. Noise from coefficient updates is completely eliminated!!! This was the big one.

There was a story I used to hear about Edison making the lightbulb, and how he failed 1000 times and said he didn't regret it because he learned 1000 ways not to make a lightbulb. That's how I feel after finally cracking IIR coefficient swapping without zipper noise or clicks. I have tried so many things with wildly varying degrees of success, but the solution is here now and I'm super excited about it.

If you prowl enough DSP forums, you’ll see a few common recommendations for this problem: switch to a state variable filter(SVF), smooth your parameter changes, or crossfade between double-buffered filters. You'll see a few other suggestions that will also most likely be bad, but these are the 3 most common.

I tried all of these and many other solutions while trying to make the JUCE classes work. Each of these changes generally require tons of changes throughout, and due to having so many filter types, often cascade down to affect that complexity as well. The SVF decision is clear. It's substantially less versatile than IIR filters. Having no noise is great, but with only 3 filter types, it's not feasible. Parameter smoothing alone doesn’t solve the core issue: coefficient swaps still cause recursive state variables to temporarily blow up without a reset, producing audible clicks. Lastly, the crossfade suggestion. Super expensive computationally, and takes up double space for all filter stages. It's brutal and will not scale properly volume-wise without some even more extreme math to account for loudness changes. Linear interpolation and dB don’t play well if you want to avoid a noticeable dip in volume during the crossfade. So then on top of all the other expenses multiplicative interpolation is needed and may need to be carried over across process blocks, and even when you get all of that it still has zipper noise, but just less of it. I knew there had to be a better way.

The True Zipper Noise Fix:

The hypothesis I gathered was this. Rather than lerp the parameters, lerp the coefficients themselves, because the large jumps in coefficients were what caused the zipper noise. This wound up being right, but also revealed a second issue: recursive state variables struggling to re-sync under large per-sample coefficient changes.

This ramp time issue with the Smoothed Value coefficients was super interesting. At anything over 20 ms, the state variables of the filters have trouble handling the changes per sample and would impulse-pop at low frequencies. At anything below 6 ms, the zipper noise comes back. At around 10 ms, both problems disappeared: smooth sweeps, no clicks, and no zipper noise across all parameter changes!

Achieving this required rebuilding JUCE’s Coefficients, Filter, and ProcessorDuplicator concepts from the ground up, since their implementations are tightly coupled. While doing so, I stripped out templated features I didn’t need and purpose-built everything for this EQ. The new system uses slightly more memory, but performance is comparable across the board, and in some cases faster, even with adding the internal smoothing, bypass handling, and coefficient replacement logic.

I can't stress how happy I am with these custom classes. They handle so much that they make my processor's logic so much simpler too, especially after housing both the coeffs and filter in a struct that covers all of the initialization. This was easily the trickiest problem to solve in this, and this solution was super satisfying to reach. The rest from here is just validation, polish, and cleanup. As far as functionality is concerned, these filters are officially of professional quality!

Completed This Week

Handrolled IIR Filter System(SmoothFilter, SmoothCoeffs, & EqStage in /Utils/Processing.h):

• Completely rewrote Coefficients & Filter classes to implement per-sample linear interpolation of coefficients on all parameter changes
• Entirely worked in mono/stereo compatibility with simpler and faster logic than the Juce Processor Duplicator class
• Maintained thread-safe reads for GUI while adhering to JUCE safety standards
• Reworked all parameter updates, filter initialization, prepare-to-play logic, and process block logic to accommodate custom classes
• Created parent struct to hold both classes and streamline initialization
• Successfully eliminated all zipper noise and clicks from parameter changes!!!

Response Curve Component(ResponseCurveComponent.h/.cpp in /Components/Visualization/):

• Implemented ideal analog equation from parameters for more accurate magnitude readings (Peak and Notch filters only)
• Squashed lingering bugs in curve rendering
• Further optimized repaint calls by caching the drawn path
• Aligned curve frame drawing behavior with spectrum drawing for consistency
• Reduced lag between response curve and button interactions to acceptable levels

Code Organization & Documentation:

• Added comprehensive documentation throughout codebase
• Separated all components into individual files
• Organized components into a logical directory structure

A lot has been moving forward for me on the job front this week (exciting!) and that has taken a bit of this week's time, but for the most part a decent amount still got done and this eq is nearly finished. That is... Outside of the hardest parts. Its ok though, since I knew enough testing and data validation would bring these problems to the top of my todo list now that all of the features are implemented. All in all, I'm super proud of this thing and once I have a solid fix for these three issues I'm going to consider this eq shipped and of studio quality.

The three current issues are: 1. Response curve drawing is having problems with drawing high slopes, 2. Spectral analysis is showing some inconsistencies, and 3. getting noise after coefficient updates from parameter changes.

For the response curve I have tried all sorts of clamps, entire reworks to the logic of getting the magnitude, hardcoded cases for notch and 10 q band pass filters with log scaling, and loads of other fixes. Nothing has quite nailed it yet, but it has led to some optimizations and better consistency. Its starting to look like its an issue deep within the JUCE::Path classes that are dropping the portions of the lines that are 1 pixel wide but have too high of a slope. I have a few more ideas to try out next week as I continue testing and getting validation on the other issues. This one is only an aesthetic issue that happens on edge cases. So, its last on the todo list, but the easiest to describe, which puts it first in this explanation. :)

Spectral analysis is specifically showing noise in the low end (less than 160 hz). I've done a lot to try to remedy this. Added a high pass to the buffer, added smoothing to the values, reworked path drawing to ensure it was a sampling issue, added clamps anywhere I could, tried multiple ways to rework how I am feeding the samples to the windowing function and FFT, but this issues persists as well. I still have a few more ideas to try out in my todo list, but the good news is that the output is looking great outside of the DC offset issue and will be finalized once that is fixed and a few more smoothed value tweaks happen.

Next is IIR filters dealing with potential fast and very large changes to their coefficients. This is a problem that has a lot of ways that it can be helped, but no perfect solution. The parameter smoothing did help a bit on frequency, gain, and quality changes, but brought along with it a lot of other changes to anything that used the parameter values. A full day was spent attempting to crossfade double buffered processor duplicators on filters, which led to a much more cpu intensive crackling sound that was worse than before. I've seen some claims about per sample coefficient updates, and, even though that sounds so wildly expensive, its the next on my attempt list for solutions to this problem. Zipper noise is a very common problem when dealing with IIR's and as much as I would love to write a whole book about it, I figure I should wait for that until next week when I, hopefully, can bring in a solution while explaining why this is such a tricky problem to solve.

Completed This Week

Peak Metering:

• Smoothing of the outputs with variable attack/release for when the signal is going up or down
• Complete clip notifier per channel implementation with a functionality to click on the meter to dismiss it
• Complete peak hold bar implementation with a variable hold time and linear sink to next highest peak per channel
• Optimized and refactored drawing

IIR & Coefficient changes:

• Added parameter smoothing to frequency, gain, and quality
• Attempted state resets for each type, db/oct, and bypass change
• Tried per sample coefficient smoothing
• Tried crossfading coefficients across changes between processor duplicators

Spectrum Analyser:

• Reworked lerping between bins to be much more optimized and consistent
• Optimized rounded path drawing
• Brought back smoothedValues and gave them the same attack/release logic as the peak meter
• Worked toward the DC offset issue: added slight highpass, clamped to avoid freqs less than 20 hz, loads of small changes to the logic, and concocted more ideas to implement for next week

General UI:

• Refactored all timers to the UI parent: now only one timer callback is triggered and it checks dirty booleans in each child component to trigger a repaint
• Tooltip flickering issue has been fixed
• Draggable button logic reworked to better keep up with the response curve changes
• Continued efforts to finalize the response curve, but slight flickering issues persist at high enough slopes

This doesn't look like as much done as last week, but that's due to the fact that a few of these things required entire structural reworks(listed below in the State Management bullet points), and the optimizations being put as one bullet a piece, when they were pretty intense. The spectrum analyser and response curve got some massive savings.

Now onto why I did those reworks and why its gonna be really important next week. Automation. In any DAW, a user has all parameters exposed to them to automate changes in the grid of the DAW, which means all logic has to account for changes from outside the GUI, and anything exposed as a parameter must be something you are ok with the user automating. Plus, parameters are way more expensive than the properties that I have replaced many of them with. Now, all parameters only affect filters, and anything affecting GUI is done in the properties of the ValueTree state. So, they still get saved and loaded in the same way as the parameters, without being exposed to the DAW. Properties being substantially smaller objects than parameters is a nice plus as well.

Also, there's the full rework to peak metering from RMS. Peak metering is much more common with these kind of tools. I'm sure the RMS component can be used later on for another plugin. So, it wasn't wasted time. There was also a day of looking into the possibility of implementing true peak metering rather than sample peak, which would be great for something aimed at mastering engineers, but this is more geared toward mixing engineers. Mastering engineers often have much less of a worry about CPU usage since they are generally just working with the stereo or 5.1 tracks of the mix. The mix on the other hand could have 100s of tracks, making this plugin much more useful for that environment. As much as I would like to try and get true peak, sample peak is way cheaper and is more in line with the initial goals of the plugin. I'll save the true peak implementation for something in the future.

I'll just end this with what is left and the good news, which is that I think this plugin should be 100% complete by the time I'm here next week! I currently need to rework a lot of the logic/drawing of the peak metering, possibly add in resizing(its not very common or expected in audio plugins. So, not necessary, but the UI cleanup I've been doing to prepare for it has made the codebase so much easier to work with. That alone was worth the work), getting a logo and an icon made, and a massive round of stress testing, particularly for parameter automation.

Here's some progress images from the initial iteration, to last week, to this week. Coming along nicely :)

Completed This Week

UX / GUI

• Peak on/off and pre/post mode buttons implemented
• Analysis settings buttons housed in new labeled, minimizable component
• Selected EQ color indicator now displayed in top corner of component
• General UI polish: continued progress toward resizing support and component sizing/drawing logic improvements across the board
• Finalized help and credits menus look and feel

State Management / Persistence

• All minimize values, spectrum analyzer & peak state booleans(power and mode), and selected EQ integer now saved and loaded with parameter tree as properties
• Moved initialization out of parameters into properties (front-end only changes)
• SelectedEQ logic reworked to save preferences and align with property values in tree

Performance / Optimization

• Response curve optimization variable added: 4× the speed while maintaining visual quality
• Spectrum analyzer fully reworked for more linear, smoother, and significantly faster operation
• Heap usage reduced by ~30 KB from spectrum analyzer improvements

Architecture / Refactoring

• Moved all value listeners to the editor to reduce juce::Value::Listener inheritance
• Required complete rework of filter visibility system in GUI
• SelectedEQ logic refactored for cleaner state management
• RMS metering fully reworked to peak metering system

Cleanup / Code Quality

• Removed vast majority of magic numbers from pixel placements
• Remaining magic numbers limited to size/topLeft variables, occasional single use variables, and numbers that are precomputed or have a clear use
• Component sizing and drawing logic standardized across the codebase

Christmas and New Year’s Eve were great, and I’ve gotten a ton done on this EQ. I’m having fun, so I’m going to keep it going until the todo list is empty. Getting back into C++ has reminded me why I love it so much, and this plugin is turning into one that I'll be using on all of my music projects!

At the bottom of this post there’s a quick list of everything I finished this week. Some of those changes uncovered new bugs. Others gave me ideas to improve safety and functionality. A few turned out so clean that I want the rest of the project to hit that same level. The todo list keeps growing as fast as the “done” list, but it will be worth it.

Most of this week was cleanup on the work from last week: the RMS meter, truly allocation-free coefficient writing, and reworking coefficient read and write paths to be fully thread-safe using a sequence lock that only spins the GUI thread(GUI will retry reads if the coefficients are mid-update, while the audio thread never waits). I’m pretty proud of that one. I also spent time on optimizations, especially in the response curve, and added an entire new set of features with three new filter types (Butterworth high-pass, low-pass, and notch).

The big remaining items, aside from ongoing testing and bug fixing, are adding resizing support, continuing to polish the GUI (hopefully with some new logos and icons from my graphic designer friend), and doing a few more optimizations and refactors I know are still needed. The spectrum analyzer in particular needs some love.

I want to talk a bit about JUCE and filter coefficients, because they can be a pretty massive footgun if you are new to audio or real-time programming. I really do love JUCE. This is said with a lot of admiration. But it is an insane choice to make the most obvious way to create filter coefficients (the Coefficients class) force a heap allocation on every coefficient update, which will happen from most parameter changes. For real-time safety, that is bad news. Heap allocations take an unpredictable amount of time, and real-time safety needs predictable timing, otherwise you risk glitches in audio playback or in the GUI.

To avoid that, you have to dig into the struct inside the Coefficients class and call its factory functions directly. Then you stash the results in your own pre-allocated array, and finally copy those values into the Filter’s StateType's coefficient space. It works, but it is not obvious the first time through.

And then you discover that the Coefficients object constructor factors out one of the coefficients so it can store fewer floats (a 2nd-order filter ends up with five rather than the normal 6). That is another detail you have to handle yourself. So you wind up re-implementing that logic too.

I am still grateful the API exposes everything. It is great that you can dig down and build what you need with the great references it provides. But it also makes it really easy to misuse, which is the opposite of what JUCE intends with this framework. Any person using an IIRFilter and updating it in the audio thread, like anyone would assume you should do, will wind up with an entirely malfunctioning eq. Also, any tutorial out there on the classes I have seen or read hasn't mentioned this, which leads me to wonder how many bad eq projects must be out there. So now my project never creates Coefficient objects directly, except for the ones required inside the filters themselves. And this concludes my JUCE Coefficients class rant 😄

Completed This Week

UX / GUI

• Prototype help and credits windows/buttons
• Minimize functionality for SelectedEQ and Gain components
• RMS lines added to show dB more clearly
• RMS meter color now matches analyzer mode
• Prepped response curve for future resizing
• Atomic “coalesce repaint” flag added to avoid redundant paints

Audio Engine / Real-Time Safety

• New struct for coefficient read/write that never allocates after startup
• Sequence-lock pattern added — GUI can spin, audio thread never blocks
• Removed unnecessary getRawParameterValue calls (only pre/post gains + 2 analyzer bools remain)
• Coefficients now only updated in processor constructor and process block
• Removed parameter magic numbers entirely (pixel magic numbers next 😢)

Performance / Optimization

• Smoothed values for analyzer and RMS using juce::SmoothedValue
• Spectrum analyzer now only updates when FIFO is full (based on fft_order)
• Refactored getMagnitudeForFrequencyArray(): preallocated freqs/mags, precomputed freqs, guaranteed safe coeff reads
• Response curve repaint triggers only on actual coeff or dB/oct changes (lambda + std::function + async message handler)
• More deliberate dirty-flag usage to reduce unnecessary coefficient rebuilds

Features

• Butterworth-style high-pass and low-pass filters
• Added notch filter type

Cleanup / Misc

• Spectrum analyzer fixes and general polishing
• Better architecture around coefficient handling

Well, that sickness took much more time than I would have liked, but the first project was chosen, I'm finally better, and the holidays have been great so far. The current progress on the eq is not the largest, but a small RMS metering component has been added and some initial actions for making the Coefficients class allocate substantially less and strengthening the thread safety of reading and writing those coefficients. The struggle with the RMS was keeping with the main tenet of this project, which was to keep it cheap. The best process I came up with for this is to have the rms happen directly before each spectrum analyser update to use the fifo setup I already had for both components. The next issue was ensuring that the rms could read for both channels separately, but the spectrum only reads a sum. There were a ton of options for how I could do this, but the solution that was chosen was to have 2 fifos. So, there's a bit more expense for stereo input signals now, but is basically free when using a mono signal. The rms operations and mono summing for the spectrum analyser now entirely happen on the gui thread just before the normal fft operations for the analyser. There still needs to be some testing and prettying up on the front end, but so far I'm really happy with the outcome. This was the last big feature I initially planned for this.

The other major work was eliminating heap allocations from the audio thread. Previously, every time a parameter changed (like frequency or gain), the plugin would create new filter coefficient objects in the real-time audio callback—causing unpredictable delays and potential glitches. The solution was implementing a lock-free double-buffer system: the GUI thread pre-computes coefficients and writes them to an inactive buffer, then atomically swaps which buffer the audio thread reads from. Getting this to work safely across three threads without locks was tricky, but the atomic operations approach worked perfectly. Now the audio thread just does a simple 24-byte memory copy instead of allocating objects. The result is substantially faster and safer filter updates and zero chance of audio dropouts during automation.

So, that's what is done for the little bit of the week that I've been able to work. My todo list is looking pretty large for next week and I'm excited. Plans are to finish the removal of heap allocations in the audio thread/process block, add a minimize functionality to a few of the components, add a "how to use" button, pretty up the gui, and smooth the output of the RMS meter and, maybe, the spectrum analyser as well. If I can get all of that done, I'd also like to add an option to use the Q parameter as 1-4 octave slopes for high/low pass filters (12/24/36/48 dB/oct) rather than traditional Q-based slopes, to better align with common pass filters in modern production.

While I'm here, why not do a small year end list :)

• Movies:
• Bugonia
• The Monkey
• Sinners
• Music:
• Gnostician - Unification as an Art
• Terrifying Girls High School - Sad Boys' Swimming Hole
• Infinity Knives/Brian Ennals - A City Drowned in God's Black Tears
• Billy Woods - GOLLIWOG
• For Your Health - This Bitter Garden
• Hayley Williams - Ego Death At A Bachelorette Party
• Games:
  • Demon School
  • Clair Obscur: Expedition 33
  • Honorable Mention for Pillars of Eternity 2: Deadfire. It didn't come out this year, but I played through it again and it was incredible

First devlog. This is exciting! All my final grades are in, which is also exciting! I have gotten sick 2 days after graduation! Substantially less exciting. Either way, time to hit the ground running. I've spent the last 6 months of college waiting for the moment where I get to work on my own stuff full time. I'm finally here. To start, I think my main goals (outside of some weekly job applications and daily interview prep) are to beef up the current 3 portfolio projects, work on something new that is at least adjacent to game development or audio tools, and get more comfortable in a few areas that I'm not where I want to be yet.

The areas I want to spend some more time in is the priority. These are:

• The Unreal Engine animation pipeline
• Unreal specific C++

The current list for possible additions to portfolio projects is:

• FPS Prototype:
• Ghosts to show prior best time runs(a speedrun classic)
• Fully embrace making Neon White's mechanics and build a card system(and scrap the pointless stamina system)
• Add more levels and enemies(a perfect excuse to get to know the animation pipeline better)
• Optimize, refactor, and polish using everything I've learned since the I did the project 6 months ago
• Horror Puzzle Game:
• Upgrading enemy AI, models, and animations (another good spot to engage with animation)
• Randomizing the maze while remaining solvable (BFS and some careful door/key placements)
• 12-Band EQ:
• Adding an RMS meter using short term fourier transforms
• Adding A- or K-Weighting to the spectrum analyzer to more closely mimic human loudness perception
• Multi-filter high and low pass that can be manipulated by octaves rather than Q to fit industry standard (I currently can only think of dynamically stacking filters for this. There has to be a better approach)
• Optimizing a bit of the memory use and rendering operations (I think everything can be done without the GUI coeffs and stay thread safe, and I know the response curve can be cheaper)
• If I don't optimize those out, at least set up a way where filter coefficient array reallocation is substantially less common (preferably not happening at all)

This section is new projects that I want to do and bring to completion.

• Sokoban & C++: (My sokoban love knows no bounds)
• This seems like a perfect small project to make to gain Unreal C++ knowledge and find any other gaps in Unreal knowledge outside of networks
• Perfect oppurtunity to see just how optimized I can get the runtime of an Unreal game
• An excellent skillset to get before diving back into the complexity of Liberators
• Raspberry Pi: (I love low level things and my wonderful partner got me a one!)
• While I'm not sure on what will be done with it, there are so many cool possibilities
• The current idea I would like is to emulate an NES. The memory and cpu ops of it are so well documented. I think that would be quickly doable and a lot of fun!
• A cheap and small LKFS meter: (why do audio plugin companies make these do too much)
• Would love to work on more audio plugins, and this could definitely be done in a week
• This would be another audio tool that I would use frequently like the eq
• I was an audio engineer during the loudness wars. I cannot overstate my appreciation for a good true loudness unit meter
• Liberators: (This is a turn based tactics game that I would love to work on again, but I'm afraid that the mess I made in it so early in my programming journey may make the work done mostly unusable)
• It will need one heck of a refactor, and last I remember some serious look into some very crazy build tool errors.
• Catch myself back up to speed and finish the enemy AI
• Refactor grid logic and pathing to C++
• Continue development based on the todo list I left myself. Animation pipeline was right around the corner.

This leaves me with a tough decision, but the plan is this: 1 week for each portfolio project to get all of the features I have listed, more polish, some refactoring, and make a devlog on each Wednesday with the updated project. This way I can have better portfolio projects and at least get more acclimated to Unreal's animation pipeline with the FPS and horror games. Next will most likely be the Sokoban game, but I'll cross that bridge when I get to it.

With the planning out of the way, the future logs oughta be much shorter. I've just been thinking about what I would do once I attained freedom for so long, that this is the place I could finally spill it all out. Plus, putting future work out there in the world will make me accountable for it. See you next week with a fresh coat of paint on one of the current selected projects :)