It should work! We’ve all been there. That feeling when you’ve been coding for hours and you’re almost done with a major chunk of the application. All the pieces are connected the way they should be but there’s some mysterious bug or runtime error. You scratch your head and start reading through your code, “Oh forgot a return statement!” Run the code again and get the same error. Sigh and keep reading, “Oh, I misspelled that variable name!” Run the code again and get the same error. Grind your teeth and keep reading, “This variable is instantiated inside this function and can’t be accessed in the outer scope.” Run code, same error. You scroll quickly through the file, your eyes unfocus a bit and everything starts to look the same and lose meaning. You start changing parts of the code that have nothing to do with part of the application causing the error because nothing makes sense anymore and you break more things in the process.
As a music producer, one of my go to software synthesizers is Massive by Native Instruments. A standout feature is its set of macro control knobs that can be connected to as many other parameters as you like, granting the user five customizable single points of control. The similarities between this and the Redux store are striking, and I thought it would be interesting to implement this macro control paradigm in a React application. I built three (melody, harmony, and bass) synthesizer components that use the Tone.js library. Each of these have parameters that are manipulated by the macros held in the Redux store. The final waveforms of these synthesizers are passed to analyser nodes that feed into the visualizer component. This component was built using the p5.js processing library. It receives the waveform data from the three voices as props, and for each voice renders three concentric circles that are made up of the voice’s waveform reflected across the y-axis. The macros in the store also control aspects of the visualizer. Particles shoot out from the three orbs at varying speeds and colors depending on the macro settings. There is also an ‘X’ made up of waveform data that fades in from the background that is controlled by macro settings. While I’m happy with the basic architecture of the project, I ran into some issues on the audio processing side of this application. The synthesizer components clip and pop a fair amount. I have a few guesses as to the cause that I will pursue as I moved this project past it’s MVP stage. At first I thought it was gain clipping, but many adjustments and the addition of gain limiter nodes didn’t solve the problem. It may have something to do with multiple AudioContexts being present in the same page, which will be tricky to work around with the compartmentalized nature of React but probably doable. Another theory is that the processing necessary for all of the oscillator and effect nodes to run in real time is just over stressing the browser. Whatever the source of the issue, this project demonstrates what Redux is best at: maintaining a single source of truth that can be easily disseminated throughout all levels of an application.
Many fictional universes, whether sci-fi or fantasy, have some sort of common language, some way for beings of disparate backgrounds to communicate. In real life, English seems to be trending that direction, due in large part to the colonial history of its native speakers. I’m no linguistic scientist, but I imagine if a group of such experts were to get together and pick a language to use as “common” based on simplicity, ease of learning, those sorts of factors; English wouldn’t make the top five. Consider these words: taught, though, thought, through, throughout, thorough, tough. Learning English is as much about learning exceptions to rules as it is about learning the rules themselves. It’s prevalence worldwide has nothing to do with its stylistic or effective qualities.
Story Vineyard is a graphical outlining tool, designed to give writers an easily digestible birds eye view of their project. It can be used for writing a novel, a screenplay, or other any domain utilizing a narrative structure. In the vineyard, a story is broken up into discrete chunks called scenes, which are represented graphically by the image of a vine. Each scene has three clickable areas: the grapes, the left red leaf, and the right red leaf. The grapes represent characters, the left red leaf represents themes, and the right red leaf represents plot points. When one of these is clicked, an info bubble will appear to show all the relevant data. The difference between plot points and themes is hazy and semantic, but in terms of this application: plot points are unique to a scene, whereas themes will pop up in different scenes over the course of the story.
Above the canvas on which the scene graphics are drawn is a collection of tools for growing and navigating the vineyard. There is a menu for selecting a story or creating a new one. There are menus to select a theme or character, and the canvas will draw all the info bubbles in which the selected element is present. Other tools include buttons to move a scene around the canvas, as well as create new scenes and delete unwanted scenes. Characters, themes, and plot points also have buttons providing CRUD functionality.
The process of writing this application felt quite different from the others I have completed. In past projects there always seemed to be some kind of snag, some little thing I was doing incorrectly that would lead to hours of searching StackExchange and head scratching. I didn’t hit any of those snags this time, which was a great feeling! However this project took about a week longer than I had anticipated.The user stories that I had written for this project all seemed easy to implement, but ended up being more involved and time consuming than I had expected. Which brings me to my resolution to plan much more thoroughly in the future.
In my database, themes and plot points share a model: meta_content, which just has a column for the content and a column called theme_or_pp to differentiate their use and depiction on the front end. Characters are a separate model with just a name attribute, which I realized much too late could’ve been folded into the meta_content model. I was locked into thinking about the application from the user’s perspective, where obviously characters and themes are entirely separate. And thinking about expanding the project down the road characters would certainly be given more attributes and use cases that would necessitate using a separate model. However for the more limited scope of this project, wrapping characters up in the meta_content model would’ve saved me from having to write separate forms on the front end, and routes and controllers on the back end. Best practices are called so for a reason, and if I had pseudo-coded even half of my project I’m sure I would’ve realized that restructuring my models was an expedient choice.
One of my favorite parts of New York is the open mic scene. Whether your thing is music, comedy, or anything else that needs an audience; there is somewhere that’ll allow you to hone your craft. Finding the right one, however, isn’t always easy. I wanted to design a website to allow aspiring performers of all sorts to find their audience, as well as create a social space to foster connectedness, creativity, and collaboration.