Forem: Sam Pagenkopf

Is Rust Bloated?

Sam Pagenkopf — Wed, 27 Mar 2024 18:40:10 +0000

Hi, my name is Sam and I think a lot about language design. I have been using or at least paying attention to Rust since 2015, and have some thoughts to share.

There is an idea going around that Rust is a wonderful language, if only it wasn't so bloated. This implies that it is possible to create a "holy grail" systems language that has the same guarantees as Rust, but is comparable in language complexity to say, C. Is this true?

In this article, I will argue that Rust is big not mainly because of cruft or excess, but that Rust's scope is extremely wide, therefore big by design. That without new ideas to optimize between speed, safety, and complexity, there will never be a language better than Rust for the same purposes.

Rust is a Big Abstraction

C is much simpler than Rust. This is because C is a thin abstraction of a generalized CPU. There is a common set of operations between almost every CPU, such as math, memory access, and subroutines. C turns this into a set of constructs which, without optimization, are trivially conversible into assembly code. Because the core ideas of what a CPU should do are fairly small in scope, C is fairly small.

Compare this to Rust. Though also an abstraction of a CPU, crucially, Rust doesn't just abstract basic CPU operations, but the set of uses of these operations which conform to Rust's safety standard. Before optimization, a Rust program is like a high-level way of describing a safe C program (except using LLVM). Safe as in, free of clearly unsafe operations -- the guarantees chosen by Rust eliminate obvious memory errors and dangerous practices, but are not a formal verification that a program will execute safely. That is, of course, until we enter an "unsafe" block, where these guarantees no longer exist.

This leads to the first reason why Rust becomes bloated: when any given functionality is humanly verifiable to be safe, but the Rust compiler is not smart enough to know that fact, the Rust team would rather write it for you in their own "unsafe" codebase than encourage you to do it. This is a good thing. Rust adds a feature rather than forcing users to rely on unsafety or hand-rolled unpredictability. The "Any" type is better than creating your own void* with type info. Using Rc<RefCell> (reference counting) for shared mutable memory is better than either trying to access stale memory, or failing to deallocate shared memory.

By doing this, the burden of working safely with the underlying machine is transferred to that of using the built-in Rust concept that can achieve a given task. But is more always better? Since one of the goals of Rust is to eliminate the need for "unsafe" wherever possible, the ever-growing diversity of demands compounds with the infinite diversity of Rust-safe operations on a turing-complete machine. For example, Rust 1.77.0 stabilizes a function called array::each_mut, which transforms an array of T into an array &mut T -- it takes a mutable reference to each element of the array. This is something simple in an unsafe block, but now there's a method for it.

Though, why, if a function is in fact safe, must it contain an "unsafe" block? The standard response is that it involves unsafe operations such as pointer math or uninitialized variables. The deeper reason is that it is much harder to add a language feature than to add yet another standard library method. It is far more costly, and in some cases impossible, to make a compiler that can validate more operations as safe.

Though, there is also a danger here. Rust programmers are always looking at docs to figure out what to use, or the meaning of what has been used. Many trivial unsafe things are still added features, and it seems there's a widening gap between being a systems programmer and being a Rust programmer. Sure, at times it's easier to reach for "unsafe", but after all of the optimizations and Rusty memory tricks are put into place, do you even know what the system is doing well enough to use it correctly?

The Cost of Speed

Rust has an optimizing compiler, and one of its banner features is competitive runtime speed. When it comes down to it, run speed is second to safety in Rust's design, and everything else comes later.

The best way to allow for code optimization is to reduce the number of guarantees, assuming that said code is already using a fast algorithm, etc. For example, if the layout of a struct can be changed, if a pointer can be reallocated freely, or if a stack variable can be reused, this gives more freedom to the optimizer. Since Rust must optimize in order to be competitive, the number of guarantees is minimal and more explicit descriptions are required, increasing the complexity required to prove safety, and littering Rust codebases with little pieces of description syntax that feel unnecessary, and sometimes are.

Sadly, inferring usage to eliminate these descriptions would both slow down compile times and cause programmers to use slower patterns without realizing. One of the causes of slow C code is that implicit struct copying is built into the language. Rust avoids this pitfall by making struct copying explicit. Though modern C compilers are likely to remove any given copy of a large struct, even relying on it in the first place changes programmer behavior and can cause less optimizable code. So in another way, Rust is fast because in many cases going slower is more effort, by design, or at the very least a programmer using slow techniques is aware that they are using them.

Early Rust had the philosophy that explicit is better than implicit. This enabled them to move quickly by shifting the burden of compiler intelligence onto the programmer, which in many cases makes users smarter about what they're doing, despite the ugly code that resulted. In the last few years, the Rust team has taught the compiler to infer much more and reduced this load, as they will continue to do. Rustc has learned to infer lifetimes instead of forcing them to be declared, and added things to simplify the language such as "impl Trait". Rust is still working on Polonius, a new borrow checker to reduce the amount of gymnastics needed to satisfy rustc, and it surely has even more in the oven. Though, some things are just better when they're specified.

How Rust Avoids Bloat

Rust being bloated right now isn't the whole story. Rust has deprecated features such as green threads after they proved outside of Rust's philosophy.

Rust also has editions, where a new version is released not expected to work with existing code. This allows Rust to periodically revolutionize itself instead of becoming stale. For example in 2018, Rust overhauled their module system. Though, in 2021, Rust's edition was entirely additions to the language. It is possible that Rust has lost its plasticity, even though the potential still exists for less. Also, Rust must still maintain support for these old editions, with some crates still using 2015 edition. No feature is every truly removed, out of fear of breaking existing code. Does it now make sense why \$2.5 million per year goes to Rust?

Also, like any good FOSS team, Rust is resistant to adding new features, requiring them to go through an RFC process where each feature is proposed, described in detail, and may be approved. A long list of potential features has been tabled, or partially implemented behind a feature gate in nightly, only to be kicked down to a future stable if at all. Not that processes like this have kept C++ from becoming intimidating, it certainly helps and gives conscious direction to Rust's progression.

Finally, for better or worse, Rust also relies on an extensive package ecosystem of packages ("crates") in order to keep the core language smaller. Though one could argue that essentials like num-traits should be part of the standard language, this at least shifts responsibility away from the standard library in covering every possible use case. Even still, this poses the issue that multiple rust crates are likely to cover the same functionality, meaning that more work goes both into selecting the right crate and towards understanding the code written using a given crate. For many programmers, Rust isn't just Rust, but Rust with num-traits, rand, Serde, static_assert, lazy_static, clap, etc.

Room for Improvement

So, where is this holy grail language that is about as simple as C, but as fast and as safe as Rust? This design space needs elaboration -- is it even possible? Like any human creation, Rust does have excess complexity, though much of it is not derived from the fundamental problem space, but from the one Rust has chosen to solve. Instead of just a fast, safe systems language, Rust has decided to be much more.

Much of this stems from Rust being multi-paradigm, with both imperative in-place mutable patterns on one hand, and FP immutable patterns on the other. Paradoxically, FP is easier to check as memory safe, but imperative is more similar to how a computer operates. A new language would have to choose one paradigm and stick with it, rather than building out both in-place mutable APIs and immutable FP ones. This also is related to the duplicity between memory moves, mutable references, and immutable references, which all seem to warrant their own separate built-ins.

Rust also has a tendency, like C++, to duplicate functionality across similar but different concepts. Why are there both functions and closures? Why are there both generic parameters and associated types? Why do data types with "impl" and modules seem to duplicate functionality between one another, such as namespacing?

Also, why does Rust have both "const fn"s as well as macros and type genericity? If a function is "const" in Rust, it is guaranteed to work at compile time. Why, then, would const fns not be able to replace the functionality of macros, or to serve as type generators? Meanwhile, work still continues on const generics, which allow Rust functions to take values at compile time in the same place as type parameters. Surely this is useful for things like Arrays, which are oddly limited in Rust, but this feature adds even more overlap among compile-time concepts.

Not to mention the growth in Rust's standard library, which seems like it can't stop adding methods to built-ins. Why are there so many stream iterator methods? A dozen of these could be based on passing a simple function into another existing method, and others still would be perfectly fine as a "for" loop. Who is using the xor method on Option, or the billion slice methods? To me, much of this screams "put it in a crate!"

Though, doubtlessly the Rust team has thought over these decisions thoroughly and decided to stick with the result, not arbitrarily. Even though there is a lot of growth, the growth is largely self-consistent within the parameters Rust has chosen.

Conclusion

Rust has trailblazed within the design space of systems languages, and I am still going to use it because there is no other language that can do what Rust does.

That said, it is also time for Rust to push against bloat, even though in some ways it is already too late. What I'm hoping to see in the next edition of Rust is not expansionism like in 2021. I'm hoping to see that Rust refines its vision and addresses the public concern about the size of the language. Rust needs to decide what is "The Rust Way", and cut out anything that goes against its core philosophy.

If there is ever going to be a successor to Rust that aims closer to the "holy grail", it will likely either be not as fast, or it will rely on an even more complex compiler. It will, as any language, suffer from the results of its chosen limitations, which introduces a different set of problems than those in Rust itself. I will continue to watch this space closely, but not jumping off of the Rust ship.

And for those of you who avoiding Rust because of the sheer number of concepts, or feeling intimidated by this article, let me just say one more thing. I believe all systems programmers should know enough Rust to master its base concepts. Almost any well-written piece of systems code should be able to be rewritten in safe Rust without an issue. For experienced programmers, Rust is probably the best systems language to start with, since it will teach you many good practices right off of the bat.

I'm optimistic about the future of systems programming, and I feel grateful that software engineers can have access to such a great open-source ecosystem of languages and libraries, which is unprecedented compared to any other field.

It is also not a surprise to me when there is friction between the magical thinking rock that is a CPU and soft fleshy humans who are just trying to make life a little easier. With that in mind, I hope language designers will realize that every single thing they add is another thing to learn. Less is more, and simplicity will win the hearts of programmers.

Oops, that Sveltekit route conflict...

Sam Pagenkopf — Thu, 11 May 2023 06:35:32 +0000

All I wanted to do was take a game I made in love2d and embed it in my Sveltekit webpage. Simple, right?

Well, to get love2d working on web, I needed to use a page generator called love.js. But, the HTML pages generated by love.js contain a lot of code that I wouldn't touch with a ten-foot pole — the type of magic Javascript that makes you run away to the nearest framework. So, I did the sensible thing. I forked love.js to strip down the generated webpage to the bare minimum, moved that site into /static/games/dig/index.html, and referenced it from /src/routes/games/dig/+page.svelte, inside of an iframe where hopefully it would never touch my webpage. Svelte gave me a warning, saying I shouldn't include raw HTML, but if it works, it works.

It did work but, something inexplicable started to happen, something that nothing seemed to fix. Going from my homepage to the Dig game, the game loaded perfectly. However, going straight to the URL, the game would fail to load, and even more strangely, the webpage would have no elements on it except for the game.

Turns out, this is the issue that I ran into. By the time I realized that this was my issue, I had already solved it. Yes, since two different files were competing for the same route, Sveltekit would serve either the raw HTML from the /static folder, or it would serve the correctly rendered Svelte webpage, all depending on how the user navigates to the page. To fix it, I renamed index.html to _index.html, and now it loads perfectly. Admittedly, I didn't even know that client-side navigation was a part of Sveltekit until I encountered this issue. Well, now I definitely know!

Keep this in mind when using a web framework with this sort of magic routing — it's very easy to cause a route conflict by putting static content in the same place as your framework code. IMO /static feels like a hack, it's sort of a fallback for when the framework simply hasn't yet covered the ground you're trying to cover. When Svelte didn't allow me to put vanilla JS into my project, I fell back on putting things in /static. Maybe there's a better solution. Think so? Comment below.

An FM Synth for Web (Part 2: Audio)

Sam Pagenkopf — Fri, 10 Mar 2023 20:14:25 +0000

Demo Fazeoid here

What is Fazeoid?

I designed Fazeoid. Neonfuz and I implemented it in Svelte + Typescript.

Fazeoid is a fun web-based synthesizer. In part 1, I describe the technologies used to make Fazeoid. In this post, I talk about details of the synthesizer itself.

Fazeoid is a combination of an FM synthesizer with multiple Additive synthesizers (and I plan on adding filters, so it could also be subtractive). It uses a modulation matrix to create any possible pattern of frequency modulation, giving the user thousands of possible sounds.

The synth is integrated to give live feedback (both audio and visual), giving a high potential for creative freedom.

FM Synthesis

If you've ever used a Sega Genesis or a DOS computer, you may recognize the sweet sounds of FM synthesis. These game soundtracks are using FM synths almost entirely, except for any drums or voice samples.

If you want to hear the wide variety that FM is capable of, the channel GSTmix has a whole playlist of mixes. There are also many present day artists that use FM synths in their chiptune, as a step above the bleepy sounds of the NES and others. For example Savaged Regime and the artists of Ubiktune.

The synths used in old computers are actually PM synthesis, but at first I will call all of it FM. This class of synthesis actually dates much further back, since it is inherently simple, yet yields rich and varied results. Though, the 80s and onward is when it found its most common usage.

The FM synth has a distinct and harmonically rich sound that can't be compared to any other. It is not a single sound, but rather an entire class of sounds based on the special relationship between two or more oscillators.

Some people learn to recreate real sounds with FM synths, while others embrace the other-worldly potential of this funny oscillator. Some musicians have used it to create beautiful sound, while others have battered the FM synth into ear-splitting, tinny game soundtracks.

What actually is FM?

There are many ways to grasp FM synthesis, conceptually. Intuitively speaking, imagine that you have a constant tone. Now, imagine that you wobble the pitch of the tone up and down, kind of like a singer. Now, imagine that you increase the speed of that wobbling until the character of the tone actually changes. This is the essence of FM synthesis. The reason it is called "FM" is because the pitch or frequency of the audible tone is being modulated.

Another way to understand is that the amplitude of one wave is being used to alter the phase of another. Imagine the function sine(sine(time)). Don't even imagine it, look at it here, and adjust the slider.. See the complex pattern made by the output wave? This is the characteristic of an FM synth, responsible for its complex wave.

A third way to understand is that an FM carrier is much like a waveshaper. A waveshaper is an operation that changes the shape of a wave, for example rounding off the peaks of a wave, or stretching the wave out. Basically, each point on a wave is run through an operation F that transforms it into another point. To do nothing, F would be F(x) = x. To invert a wave, F would be F(x) = -x. In the case of an FM synth, F(x) = sine(x). So if you imagine X is a low number between 0 and PI/2, the rise of the sine wave will be very similar to a straight line, and it will not alter the input sound very much. But, when the amplitude of X exceeds PI/2, the wave will begin to wrap around, bringing the peaks of the wave back downwards towards amplitude 0. And of course, eventually it will wrap back up again, too.

Now, extend this thinking beyond sine waves. FM can refer to any type of wave modulating any other type of wave, each with distinct characteristics.

In the following explanations, I will use "Modulator" to refer to any wave which is used to modulate another wave, called the "Carrier", a wave which carries the signal of the other wave in its frequency or phase. This is similar to the carrier wave used in FM radio, where the amplitude of the radio signal translates to the frequency of the radio wave within its band. Just remember, Modulator => Carrier.

FM vs PM synthesis

Many people inaccurately describe PM synthesis as "FM", but they aren't the same. PM is Phase Modulation, and FM is Frequency Modulation. I initially wanted Fazeoid to be a phase modulation synthesizer, hence the name, but I accidentally did frequency modulation, and stuck with it.

Mathematically speaking, phase is the integral of frequency, and frequency is the derivative of phase. The way to translate between FM and PM is to take the derivative of integral of the modulator wave. With a sine wave, this does almost nothing, changing only the phase of the wave. Human ears are very bad at hearing constant phase differences, so for 2OP sine-based PM or FM oscillators, things are about the same. But the moment the modulator strays from a pure tone, things change. The difference between PM and FM is reflected in the tonal characteristics of the modulator wave. Taking the derivative of any given sound wave makes the wave sound much more harsh or tinny, and this is reflected in the "tight" or "tinny" sound of PM compared to the full-bodied sound of FM. Integrating a wave makes it more muffled, of course. Though one must be careful when integrating, since any DC bias (wherein the average amplitude of the wave strays from 0) will accumulate and cause the result to go far off the rails. This is why I center all of my waves at 0.

From a computer's viewpoint, PM is an P=A operation, where FM is an P=P+A operation. In the first case, the amplitude of the modulator is used to set the phase of the carrier. In the second case, it is used to add to its phase.

I believe the reason why old computers used Phase Modulation is because they could utilize look-up tables to simplify this operation in their sound chips, for example using logarithms to turn the multiply into an add. The operation of many of these old chips is fully documented and recreated. Since sine and multiply are pretty trivial operations today, I went whole hog and used FM. I suspect that there is an efficient way to create FM synths as well as PM synths on an 8-bit computer chip, and maybe an acute reader can correct me and point out a vintage chip, or a potential algorithm for doing so. It is possible that the real reason for this difference is based on avoiding patent infringement, or it is based on the tinnier sound of PM being better suited for tiny computer and TV speakers.

FM Pitch ratio

The full formula for a phase modulated pair is actually sin(sin(time * pitch0) * depth + time * pitch1)). Each oscillator has its own pitch, which is simply the rate at which the phase is incremented in Hertz, or cycles per second. This is also a very important part of their sound.

One design problem that still affects fazeoid today is that FM oscillators sound best when they have integer pitch ratios to each other, resulting in more uniform waves. Right now, the pitch knobs are set to behave as arbitrary values, which encourages users to put in sub-optimal values. I will at some point implement a new UI to facilitate this.

The FM Matrix

As you have likely observed, Fazeoid is not a two-oscillator (or 2OP) synthesizer. It has 4 oscillators right now, but it will soon be expanded to an arbitrary number of oscillators. Each oscillator can feed forward its modulation into any subsequent oscillator. This means that the first oscillator is only a modulator, the last is only a carrier, and all in-between oscillators can act both as carriers and modulators. Don't think in nouns here, but in verbs. An oscillator is a carrier or modulator insofar as it takes in modulation (carrier) or puts out modulation (modulator).

Connecting several modulators in parallel to one carrier (a horizontal line on the matrix) increases the potential of that carrier in a fairly linear way. The phase effects from every modulator is summed to create the phase effect on the carrier.

Connecting FM oscillators in series (a diagonal line on the matrix) exponentially increases the complexity of the output wave. The modulation isn't summed together, but rather each oscillator transforms the signal one more time.

I have considered adding self-modulation (aka feedback) and reverse modulation to Fazeoid, but I stray away from it because I'm not sure how to implement them while keeping the synth independent of sample rate. These types of modulation can have very chaotic results. In analog terms, self-modulation is like adding a tiny delay to the oscillator amplitude, and then feeding that value back into its pitch. On old sound chips, that delay would be one sample. But on a modern computer, the synth can demand an arbitrary sample rate, and in order to create a consistent sound I would have to decide on a fixed feedback delay interval, and implement an allpass filter in order to delay accurately. Even then, it may not have consistent results.

Additive Synthesis

Of course, I wasn't content with a sine-only FM synthesizer. But, I thought about the problem. The synths of yore used phase modulation with look-up tables, so it was easy for them to alter how the sine table was sampled in order to create new wave forms. When I implemented these same type of waves, there was a very annoying issue: aliasing aka foldover distortion noticeable in the higher frequencies. This is the audio equivalent of crusty pixel aliasing seen in video games. It's called "foldover distortion", because in the process of sampling a wave, any frequency which is above half of the sampling frequency will "fold over" and create inverted harmonics that cause nasty artifacts. Anything up to half of the sampling frequency, according to the Nyquist theorem, can be correctly represented, and anything above it causes artifacts.

This is when I came up with the idea of using additive waves to recreate the waves used in old-fashioned FM sound chips, meaning that instead of just having a simple sine function for each oscillator, I will generate many many sines for each one. Now, my initial idea was actually using these equations to recreate the spectrum of the fully modulated wave, but I can't read these formulas and I have no idea how they would be extended to a whole matrix of oscillators, and especially not a matrix with varying wave types.

So to avoid this aliasing issue, my additive synth generates the sounds in a loop, but refuses to generate anything above 1/4th of the sampling frequency. Why 1/4th and not 1/2? Well, when a high frequency wave is used as modulator, it can cause the carrier to alias. I found that this was a good compromise to reduce those artifacts, but there is likely a better way I have yet to find. If you have any insight, leave a comment on this issue. My code only knows immediate pitch by the velocity of the phase after the sum of all modulation, and by cutting out high frequency waves adaptively it has the potential to create new artifacts -- it's probably not the best solution, but what is? Also, as an optimization, I have a limit to the number of sines generated which will roll of the pitch of higher waves. This creates a softer sound than what could be, but I like the result of the compromise.

So, in order to know which sines to generate, I set about finding formulas to describe which set of sines, when added together, will recreate my desired sounds. AKA, finding the discrete fourier transforms for these waves. For the first few waves, this was easy -- I just found someone else who did it. But eventually, I wanted to create more waves, and I was having trouble. Nobody online, no Wolfram Alpha, no ChatGPT could help me out in creating the fourier transforms needed. I tried to do the math, but my math is too rusty. So, I solved the problem in code, of course. By taking the integral of sin(pitch * x) * f(x), you can determine the amplitude of a particular frequency of wave f(x). So, I generated my wave, multiplied it by sine and cosine at every potential frequency, and took a riemann sum of each. The amplitude of sine and cosine are used to create a vector in the imaginary plane, of length equal to the target amplitude, and angle equal to the target phase. I used this technique to find the amplitude and phase of the component waves for each target wave, and then I put the data into excel, did a curve fit, and used that to create my harmonic series. I intentionally chose 6 waves that have different harmonic profiles, as to make the synth as interesting as possible to use. Let me know if you want the code.

Future plans

Overall, the future plans for Fazeoid are here. Comment on these issues if you have any idea what I should do next.

Subtractive synthesis

Fazeoid is not yet subtractive. I probably need to crack open a DSP textbook and possibly calculus in order to really proceed how I intend to. I want to create resonant filters that can be envelope controlled, for example. The approach of cutting out waves during the additive synthesis step to emulate a filter is also possible, but I'm weary of the fact that this could multiply artifacts, rather than smooth them out.

Conclusion

Fazeoid has been a fun adventure in synthesis land and in web frontend land. It's a space I love to be in, full of practical math, engineering, and with immediate and fun results.

But, I want to pour my effort into things that will be rewarded. If you appreciate this project, please let me know however you can. If it goes ignored and unappreciated, it will never develop any further.

An FM Synth for Web (Part 1: The Website)

Sam Pagenkopf — Fri, 10 Mar 2023 18:45:42 +0000

Demo Fazeoid here

What is Fazeoid?

I designed Fazeoid. Neonfuz and I implemented it in Svelte + Typescript.

Fazeoid is a fun web-based synthesizer. I describe the synthesizer in detail in part 2. In this post, I talk about the technologies that made Fazeoid possible.

Why make Fazeoid?

Put simply, Fazeoid was made to learn and to show off. It is really amazing what's possible on the modern web.

I would classify Fazeoid under "software nobody asked for", but there is potential. I mean, why not? Writing application UI for web is already common practice, and synthesizers have UI with similar requirements.

The way Fazeoid generates its sound is novel, and by creating this app I was able to test it out easily. By using the Vite bundler, code changes translated to immediate differences in sound and behavior, making for a nice workflow. If you're interested, Read the source code here.

Also, writing the frontend and sound generation code both in typescript allows the visual and audio components of the synth to be integrated with one another, with a huge potential.

Development Process

Fazeoid started out as a simple idea on paper. We got the basic technology working in the web app, just to make sure it was even possible. Then, we mapped out possible designs in Figma, and finally implemented them gradually.

Fazeoid was developed as a team of two, using Git of course, and Netlify CI. Mostly, features were developed on a separate branch, and then later integrated using a Pull Request.

Github has a beta feature called "Projects", which has a variable-view interface integrated with the issue tracker. The main view we used was the Kanban-style view. We also planned "sprints", where I acted mostly as the "product owner". It wasn't really what you'd expect on a pro team, but the experience was valuable.

Also, with help from Netlify, we were able to quickly deploy the app, as well as get previews of our features branches that are publicly available, so that things can be easily tested.

Svelte

We chose Svelte for this project because of the tight integration of state and UI required, which Svelte excels at through its magical bindings. Placing code within HTML, rather than HTML within code, makes it feel a bit like writing an enhanced version of Vanilla Javascript. After having written quite a bit of React, Svelte felt very fresh, like breaking out of old chains. That didn't last, though...

Svelte made it very easy to get going, but we often times questioned whether React or Solid would be a better choice. Svelte errors are often inexplicable, sometimes even dumping code even into the UI itself. When Svelte scales, it often becomes ambiguous where to store the state, or where to track it. Svelte also doesn't allow creating multiple components within the same file, which was annoying at times.

Being a single static page, Svelte didn't limit us at all in terms of functionality, and we didn't have to use Sveltekit. Overall, I would use Svelte again for a project at small scale, but I would not use it to create a large website.

The DJ knob

Fazeoid has an ergonomic interface using a custom knob element.

Svelte-dj-knob is a custom component that captures the cursor to make it easy to tweak parameters just by clicking and dragging. This was an essential part of Fazeoid. It also works on touchscreens, and is super responsive. The visual design of the knobs is flexible, but for Fazeoid I designed the knob in Inkscape, then imported the SVG into Svelte, simplified the SVG, and added animation to it using transforms. If you want to use this knob in your own project, feel free to use the npm package svelte-dj-knob.

In the case that Svelte becomes a real way to build synthesizer or effect UIs, this and other elements would be the starting point for a whole toolkit of elements.

And why not use this element on a mundane website? I think that the web should be fun, not boring, and that user experiences should feel more like video games and less like filling out paperwork.

AudioWorklet

Fazeoid would not be possible without AudioWorklet. Before AudioWorklet, software synths in javascript were severely limited. Now, the possibilities are endless.

AudioWorklet is an awesome new web API that enables web applications to generate their own sound, and this has fueled a lot of cool homegrown audio projects on the web. The sound synthesis for Fazeoid is written entirely in Typescript, using the AudioWorklet more as a self-contained entity. Though the AudioWorklet API has a lot of abstractions such as BiquadFilterNode which could be used to extend this synthesizer, I kept its functionality contained for the sake of portability.

It is definitely a bit odd to write sound code in Typescript, but it works great. The DAW Reaper already allows plugins to be written in JS, with the advantage of being able to interpret the code on the fly -- albeit with a performance hit compared to C and others. Though, as I have found, Fazeoid's performance is good enough for my phone and my PC, and that's without much optimization. If you learn how Fazeoid works, this is especially surprising.

Configuring Vite to build this worklet separately and integrate it into the project was a bit of a headache, but we arrived at a simple solution. Neonfuz will eventually write a blog post explaining the process.

One odd aspect of this worklet is that it is truly running on a second thread compared to the main program, and has to communicate using messages. Javascript may be single-threaded, but AudioWorklet is running more than one Javascript, and they can't just freely interoperate. Sadly, these messages can't be passed in a type-checked way, as far as I know.

Oscilloscopes

Because of the fact that the audio worklet and frontend code are in the same language and source file, it was easy to make wave views by calling functions within the worklet synth. This gives the user satisfying visual feedback when turning knobs, in addition to the immediate audio feedback even on currently playing notes.

The oscilloscopes are not canvases. They were made by generating SVG paths on the fly, with smooth, scalable, and responsive results.

Conclusion

Despite the headaches, I love the modern web. I love what it is becoming. It's a playground full of potential. Not only can I create a fully featured synthesizer, but I can put it in a website that works on any random device, even someone's phone, without installing anything. It will even be possible to add MIDI to this synth, making it a more complete project -- though I think I would prefer to port it instead so that it can be used on conventional platforms by actual musicians.

I love Fazeoid, and I plan on extending it based on my time and on people's interest in the project. I hope that you love it too.

Rust impl Trait For Programmers

Sam Pagenkopf — Tue, 22 Jan 2019 01:22:27 +0000

Introduction
Examples
1. Return impl Trait
2. Argument impl Trait
3. Relationship to dyn/dynamic types
Commentary
1. Argument position controversy
2. Future of impl Trait
3. Where's the type theory?
4. Applied example (return position)

Introduction

Rust's impl Trait is a little useful.

impl Trait gives the ability to hide types in functions. It is best in -> return position, but is also usable in (argument) position.

Use it when you know what Trait you want something for, but you don't care what it really is.

Examples

Return impl Trait

Here it is:

    use std::fmt::Display;

    // First case: compiler wants more
    fn <T: Display>does_not_work() -> T {"Whoops!"}
    // Second case: compiler satisfied
    fn actually_works() -> impl Display {"Not whoops!"}

Without impl Trait, it looks like this:

    fn old_explicit_way_that_works() -> String {"Duh"}
    fn slow_way_that_works() -> Box<dyn Display> {Box::new("Hello")}

Sometimes, the old way requires you to write a big, awful type that has nothing to do with how it is actually used. This solves that.

Argument impl Trait

The following two things are almost identical:

    fn visible_type_parameter<T: Trait>(x: T) {}
    fn hidden_type_parameter(x: impl T) {}

It is sometimes helpful to specify T using turbofish_aka_explicit_type::<DesiredType>. This is not currntly possible with impl T. Don't overthink this one; I favor type parameters. See commentary for a debate.

Relationship to dyn/dynamic types

Runtime Trait objects specified by &'lifetime dyn Trait or Box<dyn Trait> can be converted to compile time types. This is a conversion from dynamic to static typing.

    trait Trait {}
    struct Type;
    impl Trait for Type {}

    fn dynamic_type(x: &dyn Trait) {}

    fn static_explicit_type(x: &Type) {}
    fn static_implicit_hidden_type(x: &impl Trait) {}
    fn static_implicit_visible_type<T: Trait>(x: &T) {}

    fn main() {
        let x = Type;
        dynamic_type(&x as &Type);
        static_explicit_type(&x);
        static_implicit_hidden_type(&x);
    //    static_implicit_hidden_type::<Type>(&x); doesn't work (yet?)
        static_implicit_visible_type(&x);
        static_implicit_visible_type::<Type>(&x);
    }

This only works when &dyn Trait refers to a single type; i.e. you can only return one type from one function.

Commentary

Argument position controversy

https://github.com/rust-lang/rfcs/pull/2444
I can't summarize this issue easily. Read for yourself, especially the last post, to get a sense.

Future of impl Trait

Official tracking issue:
https://github.com/rust-lang/rust/issues/34511
It's January 2019. Here's what I see:

Existential types (aka type x = impl Trait but in a way that makes sense)
impl X + Y for multiple traits.
Various other things to make it more complete.
Potential that ::<Turbofish> will appear a la "synthetic" type parameters. https://github.com/rust-lang/rust/issues/44721#issuecomment-330945507

Where's the type theory?

People have tried to explain it this way (existential? universal?), but take a step back to look at rust. impl Trait is a single step forward in type inference.

Recognize that I'm not using a powerful set of tools for understanding type systems that does exist. Give this article a read:
https://varkor.github.io/blog/2018/07/03/existential-types-in-rust.html

Applied example (return position)

Naive attempt:

    use std::fmt::Display;

    fn main() {
        println!("{}", make_value(0));
        println!("{}", make_value(1));
    }

    fn make_value<T: Display>(index: usize) -> T {
        match index {
            0 => "Hello, World",
            1 => "Hello, World (1)",
            _ => panic!(),
        }
    }

Fails because…

    error[E0282]: type annotations needed
     --> /home/sam/code/trash/impl-return.rs:4:20
      |
    4 |     println!("{}", make_value(0));
      |                    ^^^^^^^^^^ cannot infer type for `T`

    error[E0308]: match arms have incompatible types
      --> /home/sam/code/trash/impl-return.rs:9:5
       |
    9  | /     match index {
    10 | |         0 => "Hello, World",
       | |              -------------- match arm with an incompatible type
    11 | |         1 => "Hello, World (1)",
    12 | |         _ => panic!(),
    13 | |     }
       | |_____^ expected type parameter, found reference
       |
       = note: expected type `T`
                  found type `&'static str`

    error: aborting due to 2 previous errors

    Some errors occurred: E0282, E0308.
    For more information about an error, try `rustc --explain E0282`.

Okay, so I do this:

    use std::fmt::Display;

    fn main() {
        println!("{}", make_value::<&'static str>(0));
        println!("{}", make_value::<&'static str>(1));
    }

    fn make_value<T: Display>(index: usize) -> T {
        match index {
            0 => "Hello, World",
            1 => "okay",
            _ => panic!(),
        }
    }

Another dead end:

    error[E0308]: match arms have incompatible types
      --> /home/sam/code/trash/impl-return.rs:9:5
       |
    9  | /     match index {
    10 | |         0 => "Hello, World",
       | |              -------------- match arm with an incompatible type
    11 | |         1 => "okay",
    12 | |         _ => panic!(),
    13 | |     }
       | |_____^ expected type parameter, found reference
       |
       = note: expected type `T`
                  found type `&'static str`

    error: aborting due to previous error

    For more information about this error, try `rustc --explain E0308`.

Yet this succeeds:

    use std::fmt::Display;

    fn make_value(index: usize) -> impl Display {
        match index {
            0 => "Hello, World",
            1 => "Hello, World (1)",
            _ => panic!(),
        }
    }

(Generated using org-mode)

Rust Module Essentials

Sam Pagenkopf — Tue, 19 Dec 2017 04:35:11 +0000

Do you remember the first time you made a project with more than one source file? Was it with headers, with classes...or, with modules?

Modules have certain traits. They allow various items to coexist in a unit, without being bound to a class. A module file generally has its interface (outward-facing public parts) on top, and its implementation (dirty inner details) on the bottom.

Understanding Rust's modules comes from understanding the keywords mod, pub, and use. To state them simply:

mod declares a module.
pub exposes.
use pulls things in.

Let's begin with an example. Modules can be defined two ways. First in place:

// main.rs

mod food {
    pub fn eat() {
        println!("Good.");
    }
}
fn main() {
    food::eat();
}

Second, as a separate file:

// main.rs

mod food;

fn main() {
    food::eat();
}

// food.rs or food/mod.rs

pub fn eat() {
    println!("Yum.");
}

So more specifically:

mod X means: let there be a module X, defined either here, in braces, or in a separate file named X.rs or X/mod.rs.

pub fn eat makes eat visible to main. Without pub, main would not be able to call eat.

Note that without mod food in main, Rust would ignore food.rs entirely.

Next, let's expand the above to something more deeply nested:

// main.rs

mod food {
    pub mod lunch {
        pub fn eat() {
             println!("Take a break.");
        }
    }
}
fn main() {
    food::lunch::eat();
}

Or, as multiple files. Note the use of mod.rs, a special filename:

// main.rs

mod food;

fn main() {
    food::lunch::eat();
}

// food/mod.rs

pub mod lunch;

// food/lunch.rs

pub fn eat() {
    println!("Hamburger.");
}

Does this look like you expected? Notice how both fn eat and mod lunch are made pub. They must be carried up this way, one level at a time.

And of course, anything without pub is invisible outside its module.

Perhaps surprisingly, pub treats struct members and methods on an individual basis.

// food.rs

struct Meal {
    pub taste: String,
    price: u32, // cannot see price
}

impl Meal {
    pub fn eat(&self) {
        println!("I taste {}.", self.taste);
    }
    fn purchase(&self) { // cannot call purchase directly
        println!("Spent ${}. Ouch.", self.price);
    }
}

Having a private variable price means that you cannot make a Meal outside of food. A constructor method can help with that.

// food.rs

impl Meal {
    pub fn fancy() -> Self {
        Meal {
            taste: String::from("miracles on plate"),
            price: 44100,
        }
    }
}

// main.rs

mod food;

fn main() {
    let lunch = food::Meal::fancy();
    lunch.eat();
}

So, to recap:

pub exposes an item, either on module or struct level, to its surrounding level.

Do note that Meal::fancy could also be named Meal::new, or even other things.

Next, let's examine use to complete our set of three. use is a tool that pulls in words to reduce visual clutter and finger work.

mod food;
use food::Meal;

fn main() {
    let lunch = Meal::fancy();
    lunch.eat();
}

Or even:

mod food;
use food::Meal::fancy;

fn main() {
    let lunch = fancy();
    lunch.eat();
}

Pulling in fancy directly is an extreme example, but it does work. In the same way that pub can apply to structs, so can use.

A wrinkle with use is that it has absolute paths. To understand paths, consider this non-working example:

mod food {
    fn cheaper(a: &Meal, b: &Meal) -> u32 {
        std::cmp::min(a.price, b.price)
    }
}

This fails because std::cmp is the same as writing self::std::cmp, self here being food. It's a relative path. So, let's use an absolute path by adding :: to the start.

mod food {
    fn cheaper(a: &Meal, b: &Meal) -> u32 {
        ::std::cmp::min(a.price, b.price)
    }
}

This works, but the use keyword is also an absolute path, and can reduce typing in the long run.

mod food {
    use std;
    fn cheaper(a: &Meal, b: &Meal) -> u32 {
        std::cmp::min(a.cost, b.cost)
    }
}

Here's another way of doing it. Yes, use does respect its scope.

mod food {
    fn cheaper(a: &Meal, b: &Meal) -> u32 {
        use std::cmp::min;
        min(a.cost, b.cost)
    }
}

There is some light alternate syntax for use as well, in order to pull in multiple things.

mod food {
   pub mod bread {
       pub struct Slice {}
       pub struct Loaf {}
   }
   pub struct Plate {}
   pub struct Napkin {}
}

use food::bread::*; // pulls in Slice and Loaf
use food::{Plate, Napkin};

So, to be specific:

use brings module or struct items into the current scope from an absolute path.

Also note that pub use can be used as a flattening method.

mod food {
    pub mod breakfast {
        pub mod cereal {
            pub fn eat() {
                println!("Snip, crankle, porp.");
            }
        }
    }
    pub use self::breakfast::cereal;
}
fn main() {
    food::cereal::eat();
}

This enables you to divide into further modules for organization, without adding a burden to the outside world.

Overall, it is better to be more explicit (avoid too much *) and use judiciously. It's better to know where things are coming from when you see them later, but added visual clutter and typing are no fun.

To recap:

mod declares a module.
pub exposes an item by a single level.
use brings things from an absolute path to the current scope.

There is more, but I hope I have helped get things started. Let me know if you're interested in a second part.

Forem: Sam Pagenkopf

Is Rust Bloated?

Rust is a Big Abstraction

The Cost of Speed

How Rust Avoids Bloat

Room for Improvement

Conclusion

Oops, that Sveltekit route conflict...

An FM Synth for Web (Part 2: Audio)

Demo Fazeoid here

What is Fazeoid?

FM Synthesis

What actually is FM?

FM vs PM synthesis

FM Pitch ratio

The FM Matrix

Additive Synthesis

Future plans

Subtractive synthesis

Conclusion

An FM Synth for Web (Part 1: The Website)

Demo Fazeoid here

What is Fazeoid?

Why make Fazeoid?

Development Process

Svelte

The DJ knob

AudioWorklet

Oscilloscopes

Conclusion

Rust impl Trait For Programmers

Table of Contents

Introduction

Examples

Return impl Trait

Argument impl Trait

Relationship to dyn/dynamic types

Commentary

Argument position controversy

Future of impl Trait

Where's the type theory?

Applied example (return position)

Rust Module Essentials