Symphony

Create something amazing.

˙ ˙ ˙

Overview

Symphony is a music creation software for people of all skill levels. With a strong focus on intuitive design, Symphony takes away the usual learning curve that makes many creatives shy away from conventional tools. For drawing up a simple musical idea, conventional DAWs are far too complex, requiring lengthy project setups, and catering to high-power users, which can clutter the interface for simple experimentative sessions. Symphony aims to provide that space where users can jump right in and start drafting, keeping the user experience simple yet powerful.

When you're ready to move on to the more technical phase, Symphony gives you power features like stacking multiple sounds or playing with wave types, but also lets you export your projects into a myriad of standard music file types (.midi, .mscz, etc), ensuring you can continue your creative flow without restarting.

Codebase Information

Symphony is made with what I'm calling the RENSP stack (I don't think that'll catch on). It consists of React, Electron, Node, SDL2, and Pygame.Mixer; A slightly unconventional stack, but it's tailor-fit at each step of the column to ensure maximum efficiency and minimal boilerplate.

• React on the Front-End: Symphony uses a conventional React component structure for handling all the frontend logic of the Project Manager. We build with Vite for rapid hot-swapping, which accelerated dev time.

• Electron as the RT Environment: Simple, and avoids the complexities of config needed for "faster" frameworks. Fast debugging with the native browser DevTools window were really useful for quick testing.

• Node for the Backend: This is really as a sub-layer of Electron, which interfaces with Node's IPC renderer to handle file management and state logic of the Project Manager.

• SDL2 for the Editor Interface: This is done via Python's Pygame library, and allows us to essentially take advantage of precise, pixel-level rendering of complex elements beyond the capabilites of traditional DOM-style renders, and since we're doing it all inside of the Python main process we can handle all system functionality under the same hood as the frontend without needing compartmentalization hell with endpoints and external calls. This did mean we spent a good while reconstructing basic UI functionality from scratch, like scrolling, selecting, dragging, etc, but the end result is total program control, which is worth it when designing a tightly integrated editor and playback system.

• Pygame.Mixer for Audio: Another just... obvious option. We initially experimented with the Simpleaudio library when starting out, but found that switching to Pygame.Mixer was a small migration effort that completely eliminated what used to be frequent, inexplicable crashes from segmentation faults in the Simpleaudio library. Mixer also runs significantly faster, reducing playback latency.

Design Language

Symphony has a clean, consistent UI design language we're calling Slate. It features a dark, yet contrast-rich look with plenty of design flair, while adhering to strict principles of design.

Typeface Choice

There are two major fonts used across Symphony: Instrument Sans, and Inter.

• Instrument Sans is recognizable by its slightly wide stance, smaller natural kerning, and low x-height. This makes it great for big titles, where legibility is not an issue. It also has a touch of character, with features like the tilted terminals visible in letters like the lowercase 't', without being too bold or divisive.

• Inter is characterized by its simplicity, sacrificing uniqueness for legibility. It's designed to be readable at even tiny sizes, with very high x-height and consistent minimum internal spacing to avoid clashing. As both the project manager and editor feature text at small sizes throughout, Inter was a clear choice.

Button Design

Across the system, we have buttons that accomplish different tasks, from small, single-step actions that are stateless, to heavier tasks that advance UX flow in some way, all the way up to huge actions that move the program to a completely different state. To communicate each of these three abilities, we have a design language built into the buttons.

• Standard Buttons can be seen in the toolbar or in left and right panels. They are often stateless (but not always), and don't command user attention, since if all such buttons were bold, they would be fighting for attention.
• Heavy Buttons can be seen in modals, often reading "Next" or "Done" or "Delete". These perform big actions, including closing the modal itself, and need to distinguish themselves from the rest of the options on the modal.
• Call-to-Action is used in the "Open in Editor" button. This is a special button as it launches a whole separate window, and represents the program state changing. This button style is used incredibly sparingly (so far, only once) as it is very commanding of attention.

Optical Spacing

A common example used to explain optical sizing is the circles and squares example. In Symphony (and many other softwares) a more common optical sizing problem is seen: large and small text. A common misconception is that all left or right-justified text should align to the same pixel -- however, this will lead to the smallest text feeling pushed further to the edge than the larger text, since more of its details are optically closer to the edge. We must shift smaller text away from the edge to keep them feeling optically aligned.

As you can see in the above example, the red line is several pixels to the right of the blue line, however the text is optically aligned; without the lines pointing it out, the text actually appears more natural than if they were pixel-aligned. Additionally, the image shows the effect of optical kerning as well -- the percentage of letter widths that is proportional to the empty space increases as the text gets smaller. This keeps text feeling breathable at all sizes. In Symphony, this can be seen in the small letterforms in the toolbar, where wide kerning allows the text to remain readable even at < 9px.

Directing Attention

Symphony has many modals. These are floating widgets that display task-sensitive information, and require the user's immediate attention. To direct the user's attention to the content of the modals, in a manner that does not clutter their view, we employ a subtle blur to everything else.

Other Design Choices: Bold Size Effects, Intuitiveness

Little known fact: Bold text optically looks smaller than thin text. The reasons for this phenomenon are multilayered, but the primary reason is that your eyes see the size of text as the distance between the centers of parallel curves in the letterform, which, if the text gets bolder without getting taller, actually decreases in length. In some modals in Symphony, where simply bolding the text could make it appear slightly smaller and throwing off the visual hierarchy, we increased the size by around 1px to compensate. This effect is incredibly subtle, but it's more noticeable when it's not used.

On top of our extensive button design considerations, we also need to work practicality into design aesthetics. While plain text is great at describing the purpose of a button, practically it is impossible to give text to every button on the screen. In areas like the toolbar, we use icons instead. Here, we are trading initial affordance with better space usage. But to keep users from having to guess what buttons do, we employ hover tooltips on all icon-only buttons, and for any text fields where internal text is truncated for space. This ensures that all navigational information is accessible, even if not visible at once.

Footnote: Technical Challenges & Future Considerations

Symphony is still under active development, but we can already identify some pain points in development and crutches that might hinder its widespread adoption. However, these we want to see crop up post-beta-release, because, to be honest, I really don't know how big each one is until it's in the hands of testers. (I'm subtly urging you to download this and test it yourself *wink wink*)

• Growing codebase: Codebase management as a solo developer is definitely a major challenge. Pieces interact with each other across the entire platform, components calling other components from wildly different places -- I do believe that with this project, it was almost a must to keep my components and styles organized. Thus, the repo, while large, is well-fragmented into digestible pieces.

• Monofile editor: Initially a method to keep function call order consistent (and Z-layering easy) and essentially create a easy-to-access single file to handle the editor processes, has now become an absolutely gigantic "monofile" editor that is over 1,400 lines of code long. Making changes in this file is cumbersome, as it often involves injecting new code at precarious locations in the file. If I had the time, I would completely refactor the inner editor to adopt a similar component structure as the project manager, if not for the visuals then at least breaking up various tasks of the Editor into multiple files to avoid this "hunting".

• Performance Limits: While not imminent, the Editor, which runs on a realtime loop rather than an Event-based DOM, can put strain on lower-end PCs, since when in fullscreen, the app is pushing a lot of pixels manually. This is in part due to Python being a slower language but also a lack of optimization in the rendering process -- we have optimized a lot WHAT we are rendering (screenspace culling, hashmapping, object-oriented buttons) but not HOW we are rendering it (example: pausing screen updates when blurred focus, event-based UI updates, etc.).