The Random Ramblings of a Software Developer

IEM Equalization Extravaganza

Sat, 08 Oct 2022 22:40:00 +0000

Audiophiles see In-ear monitors (IEMs) as an inexpensive way into audiophilia. Sure, with the recent rise of the “chi-fi” it has never been so cheap to have access to good sound quality. Still, a certain sound signature might not be to the tastes of everyone, not to mention different ears will literally hear things differently. In such cases, one has the possibility of applying equalization to change the signature of audio hardware.

The legendary Moondrop Blessing 2:Dusk

Before we proceed

Before we dive into IEM equalization, there’s a few topics I need to introduce to make sure we’re all on the same page.

Tonality

Tonality is basically how a sound reproduction device outputs each part of the frequency spectrum. That is to say, it will determine how much bass, mids and treble the sound will ultimately have.

As with every hobby, it can always get more complicated. Usually we divide tonality into sub-regions, such as “sub-bass”, “upper-midrange” and “air region” (high treble). There are no precise definitions of where exactly in the frequency spectrum each area is located, and the terms only provide a general idea.

The famous IEM reviewer crinacle has his own definitions, which are as follows:

• 20Hz to 80Hz: Sub-bass;
• 80Hz to 200Hz: Mid-bass;
• 200Hz to 800Hz: Lower midrange;
• 800Hz to 1.500Hz: Centre midrange;
• 1.500Hz to 5.000Hz: Upper midrange;
• 5.000Hz to 10.000Hz: Treble;
• 10.000Hz+: Upper treble/”air”.

IEMs vs headphones vs speakers

At this point, it is important to understand that different types of devices should have different frequency response curves.

In a way, speakers have it easy. The sound they output travel along your room, and reach your body like any other “natural” sound would. That is, it will reflect on surfaces, shake your body, interact with the fine structure on your ear’s pinna, until it finally reaches your eardrums. Therefore, whatever influence these things have on the sound, the speakers’ job is merely to reproduce audio like a natural source would, and both will go through the same interactions.

Now headphones, on the other hand, have a trickier job to perform. They do not interact with the environment, and also bypass most of the interaction with your body. Over-ear headphones do interact with your pinna, but they do so blasting sound at a direct angle onto your ear canals. This is quite different from what a natural sound goes through, and if a headphone does not account for that in its sound signature, it will not sound correct to our brains.

Finally, IEMs have it even worse, because they bypass the pinna completely and output sound directly down your ear canals (which are also sealed by the IEM).

All of that is to say: different types of devices will aim for different types of frequency response targets.

Frequency response targets

For the remainder of this post, I will focus on IEMs. One of the most famous target response curves in the IEM world is the Harman IE target (official paper).

The Harman target curve

The Harman curve is meant to capture the taste of what most people would consider “good”. It has what audiophiles sometimes describe as a “V-shaped” tonality: lots of bass (mostly focused on the sub-bass area) and goes up again on the treble region. It also accounts for an increased output in the region around 2~5KHz, meant to emulate the effect the ear pinna has on the sound that reaches our ears (remember, an IEM bypasses the pinna completely). This is usually referred to as the “pinna gain”.

Another important curve is the diffuse field target curve, created by Etymotic Research. This curve is meant to emulate the frequency response reaching the eardrums of a dummy head when sound is arriving at it coming from all directions uniformly. It is usually perceived as a “bright” signature, having more energy in the treble region that a Harman-tuned IEM would.

Other curves exist, such as Moondrop’s own in-house Virtual Diffuse Sound Field (VDSF), or reviewer curves such as crinacle’s IEF Neutral.

“Technicalities”?

Usually audiophiles divide the sound signature analysis into two groups: tonality and technicalities. Some aspects of the sound signature are hard (or maybe impossible) to describe using frequency response (the tonality) alone. This is where other, more abstract terms start to show up: “soundstage”, “imaging”, “attack speed”, “texture”, “details”, etc…

Crinacle goes over these topics in great detail on this article, where he states:

Do note that whatever I write here is still mostly “pseudoscience” in that most of the things here aren’t peer-reviewed or academically researched (or scientifically accurate, for that matter!)

I find it quite surprising that in this day and age most of what we use to describe audio is still highly unscientific, veering into the “it’s an art” territory. But nevertheless, this is the state of things. My own personal, unscientific view, is that most of the “detail” stems from a reproduction of the treble region in an accurate and devoid of peaks fashion. Regarding “soundstage” and “imaging”, these are heavily tied to the Head-Related Transfer Function (HRTF), which varies from person to person and is especially hard for IEMs to emulate properly, which is why they tend to fare poorly in this aspect.

Measurements

Now, what use would target curves be if there were no way to measure and analyze how an IEM responds?

Measurements are a very complicated subject, which I do not have a lot of property to talk about, so I will give you some general pointers of where to go.

To measure the frequency response of IEMs instruments known as couplers are used. The IEM is inserted on the opening, and usually a sine wave sweep is performed on the IEM, which is then used to graph the amplitude of the sound reaching the coupler.

Due to ressonances inside the coupler, IEM frequency response graphs will always end up with some peaks in certain treble frequencies. For consistency, usually reviewers try to position the peak in the same place for every measured IEM, by varying insertion depth. For instance, Super* Review targets 8KHz for the ressonance peak.

As such, frequency response graphs should be used with care, and its limitations have to be considered. They are most useful when used as a comparison tool between measurements taken with a consistent methodology. Frequency response graphs can be used as an aid for equalization, but one has to be mindful of such limitations, and also differences from person to person (your ear is not a GRAS coupler!), unit variance, etc…

Crinacle goes in-depth into IEM measuring equipments

Equalizers

If you’re here, I assume you’re reasonably familiar with the concept of audio equalization. Still, I will expand a bit on the two most common types of equalizers: band and parametric.

Band equalizers have filters at specific, static frequencies. They usually provide the user with a simple interface containing multiple bands at certain set frequencies, and the user is able to increase or decrease the amplitude of the audio around each frequency. These are fine for some coarse corrections, but due to the fixed bands it’s often not possible to execute corrections exactly as desired.

xnor's band equalizer for foobar2000

For more precise corrections, we use parametric equalizers. I will leave it to the folks at PreSonus to provide a more in-depth explanation, but I will very quickly go through the main concepts intuitively. A parametric equalizer filter is composed of three parameters: frequency, Q and gain. Q stands for “quality” (which is a bit of a deceiving title).

• Frequency: the frequency at which the filter is centered at;
• Q: the “spread” of the filter. A small Q value means the filter is very wide, and a large Q results in a very narrow filter;
• Gain: The amplitude at the center of the filter.

Different Q values, image courtesy of JRiver

A very useful tool to build and analyze parametric equalizers is crinacle’s graph comparison tool. It is an open-source tool available on GitHub, made by Marshall Lochbaum. However, my favorite implementation of it is Super* Review’s Squiglink. I even have my own deployed here!

There are many softwares which you can use to apply band and parametric equalizers, I will mention some which I use and enjoy.

Wavelet is an Android app that allows you to use system-wide equalization. It has a built-in band equalizer with 9 bands, and a convolution equalizer. I will not go into details about convolution equalizers, but suffice to say we will be able to export a Wavelet settings file using CrinGraph’s parametric equalizer (more on that later).

AutoEQ is a project and not a software per se, but a very relevant one.

AutoEQ is a project for equalizing headphone frequency responses automatically, and it achieves this by parsing frequency response measurements and producing equalization settings which correct the headphone to a neutral sound.

It includes a huge database with over 4000 measurements, and parametric equalizer settings tuned to the Harman target. Wavelet has built-in support for the AutoEQ database using its AutoEQ function. However, we will export our own equalizer curve later.

Finally, we have Equalizer APO, an open-source Windows equalizer. It has graphic, parametric and convolution equalizer support, among other features. It’s usually used in conjunction with the Peace interface.

We are now ready to go into the densest part of this whole thing, which is how I came with my own target curve to help me equalize my own IEMs.

My own target curve

I’m not a huge fan of the Harman curve. It has too much bass for me, and I’m also quite sensitive to the 8KHz region, which is very prominent in the Harman curve. The new Super 22 target curve made by Super* Review is much closer to my own personal tastes, and served as the basis for my own target curve.

Super22 target curve

The only things I have decided to change in the Super 22 curve were:

• added slightly more sub-bass to increase the feeling of bass extension;
• removed the scoop between 6~8KHz, which seems arbitrary to me personally.

Hence I came up with the VitorMach target:

VitorMach target curve

But wait, how did I get here? Now, it’s time to dive deep into the technical part.

Room EQ Wizard (REW)

We’re going to use Room EQ Wizard (REW) to create the target curve.

Super* Review kindly provided this spreadsheet to help building the input file for REW. In the first tab (“Custom”), we will be filling in amplitude values (dB) for each relevant frequency we wish to key in. It is recommended that the 1000Hz value is kept at 100, and the other frequencies to be adjusted relative to it. You only need to fill in some of the frequencies, and when you export it, the target curve will be interpolated along them. Switch to the “Export” for more information on how to export the curve.

Here are the exported keypoints of my own target curve:

Frequency	SPL (dB)
10	107.5
20	107.2
30	106.7
40	106.2
50	105.6
80	104.2
100	103.5
150	102.0
300	100.5
500	100.0
600	100.0
1,000	100.0
1,500	102.5
2,500	107.1
3,000	107.5
3,500	107.1
5,000	105.0
10,000	100.0
20,000	94.0
22,000	93.5

Obs.: I have manually added in values for 10Hz and 22.000KHz to make the edges of the REW output smoother (the range we will export from REW will be 20Hz to 20.000KHz).

In REW, go to File > Import > Import frequency response. Choose your keypoints .txt file, and you should see this:

Keypoints file imported in REW

Go in the Graph menu and choose one of the smoothing options to make the curve less “jagged”. In my case I went full smooth and choose 1/1 smoothing (the strongest), but feel free to experiment.

With that done, go to File > Export > Export measurement as text. Make sure your options look like this:

REW measurement export dialog

Click OK and save a new txt file. You will notice this file is much larger than your input, because it contains the interpolated values for the entire curve, not just your keypoints.

Using the target curve

With the target curve file in hands, it’s simply a matter of going to Squiglink’s Equalizer tab and clicking on “Upload Target” to use your own target curve.

With the target curve loaded, we can begin to use the parametric equalizer, and the AutoEQ function.

First, choose your IEM model in the Models tab. Hopefully it’s been measured, but if it hasn’t, check “Other IEM databases” down in the footer for other CrinGraph databases, maybe you will find yours in one of these.

Now, back to the Equalizer tab, and we are ready to hit the AutoEQ button. You should see something like this:

Squiglink's AutoEQ feature

There are a few things to note here.

First, the number of filters on the left sidebar will determine the maximum number of filters AutoEQ will use. The AutoEQ Range parameter specifies the frequency range which AutoEQ should try to equalize. I would heavily recommend not changing this range, because like I said before, the treble region measurements are very unreliable.

Speaking of unreliability, I would try to avoid using aggressive (high gain) and narrow (high Q) filters above 7KHz, because this might result in a “correction” that does not work well with your particular unit, or on your own ears. In the treble region, prefer wideband adjustments (low Q) and modest gain settings. Use the AutoEQ result only as a basis, and tweak the values on the left sidebar.

You should end up with something like this after some tweaks on the treble region:

A much less aggressive treble EQ

When you are ready, you can hit the “Export Graphic EQ (For Wavelet)” button if you wish to export a convolution settings file for Wavelet, or you can simply reproduce the parametric equalizer values on your equalizer software of choice.

As an added tip, you can hit this button to flatten one of the curves:

Original squig flattened

This makes it easier to judge how aggresive your equalizer curve is.

Custom CrinGraph

As I mentioned before, CrinGraph is an open-source software available on GitHub. I have decided to host my own instance using GitHub Pages, which is free. The repository contains documentation on the basic configuration for deploying your own instance.

Conclusion

I hope this was useful to you, and feel free to contact me using the Disqus chat below!

Resources

Update: November 13, 2022

I have come with a new variant of my target curve. Visit my CrinGraph instance to check it out. I also came up with an EQ for the Dusk conforming to this target. Please note that the first and last filters are shelf filters (LSQ and HSQ respectively) instead of the usual peak (PK) type.

• EQ settings - Dusk (Nov22)

Tutorial: Vaporwave VHS effect using GIMP

Sat, 12 Sep 2020 21:25:00 +0000

After a while searching for a good vaporwave effect, I ended up deciding to do it myself using GIMP.

Ready for some ａｅｓｔｈｅｔｉｃ?

Before we start, I suggest you get in the mood:

Some classic vaporwave

Here’s our starting image (photography by yours truly):

A lovely vintage alarm clock

Our first step will be to decompose the image into the YCbCr color space, which is how video is actually stored (analogically) on an actual VHS tape. We will need to process each channel separately to achieve an authentic effect.

Colors > Components > Decompose…

Decompose the image into YCbCr ITU R470

Next, we add a bit of noise to the luma channel only. It will be smoothed out later.

Filters > Noise > RGB Noise…

Add a bit of gaussian noise to the luma channel

After that, it’s time for good ol’ gaussian blur on the luma channel. Take note of the values, they will be different later on for the chroma channels due to the effect of chroma subsampling in actual VHS.

Filters > Blur > Gaussian Blur…

Some gaussian blur to the luma channel

It’s time for the unsharp mask (a.k.a. sharpening). Turns out VCRs add some rudimentary sharpening to the luma channel to attempt to alleviate some of the blurriness. It introduces the halo effects we are used to seeing in VHS footage.

Filters > Enhance > Sharpen (Unsharp Mask)…

Unsharp mask for some nice halos

This might be a good opportunity for a bit of a curve adjustment on the luma channel. VHS doesn’t have that great dynamic range, let’s replicate some of that.

Colors > Curves…

Adjust the curves of the luma channel

Now it’s time to add gaussian blur to both of the color channels. Repeat this process for both the redness and blueness channels.

Filters > Blur > Gaussian Blur…

Some gaussian blur to the color channels

We will shift the blueness channel a bit to the left to reproduce some of the fringing distortion that usually appears during the reconstruction of the signal. It’s similar to purple fringing in photography, albeit with a different cause.

Moved the blueness channel a bit to the left

Set 'Layer to image size' to flatten the layer shift

We are ready to recompose the image onto RGB again.

Colors > Components > Compose…

Recompose the image from YCbCr ITU R470 back to RGB

Now comes the overkill programmer part. I have made a Node (or Deno) script, which is available here, to generate a Curve Bend tool .points file. This tool is used to add line distortions to the image, which we will use to mimic VHS tearing caused by tape degradation.

You can run it like this:

$ node vhs.js >> vhs-curve-bend.points

Or you can just use my .points file if you really can’t be bothered.

And then you can load it into the Curve Bend tool. Don’t forget to set the “Curve Type” to “Free”.

Filters > Distorts > Curve Bend…

Example output of the script (there are 256 values in total)

Curve bend tool

To increase the vaporwave factor we can add a bit of color balance effects and reduce saturation.

Colors > Color Balance…
Colors > Saturation…

Color balance: shift highlights to magenta

Color balance: shift midtones to cyan

Reduce saturation a bit

And that’s it! Here’s our final result:

Our vaporwave'd up photo

For great vaporwave.

Linting JavaScript and TypeScript

Sat, 12 Jan 2019 15:00:00 +0000

Linting consists of the usage of tools to analyze source-code, find and report errors, bugs, and bad coding style. This post is a guide to install and use the ESLint and TSLint linters with Visual Studio Code, while also using the extension Prettier to provide the stylistic opinions. We will also extend the Airbnb style guide in the ESLint setup. I will not lie to you, dear reader, the main objective of this post is to serve as future reference for myself when setting up this environment again.

Code formatted by Prettier, with TSLint highlighting my bad usage of var.

This was tested with Node.js 11.4.0 and Yarn 1.13.0.

Let’s begin by installing all the global dependencies we will need:


yarn global add typescript eslint tslint prettier eslint-plugin-import eslint-plugin-prettier eslint-config-prettier eslint-config-airbnb-base tslint-config-prettier

Notice that eslint-plugin-import is necessary because it is a peer dependency of eslint-config-airbnb-base. If you need support for React, consider using eslint-config-airbnb instead. It has additional peer dependencies, check the dependency page for more information.

The .eslintrc.json file goes into the user’s home folder (Windows: %UserProfile%, Linux: ~), and is as follows:

{
  "extends": ["airbnb-base", "prettier"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": ["error"],
    "linebreak-style": 0
  }
}

Notice that we are extending the Airbnb style guide, and then overriding it with the Prettier config. This is to make sure that ESLint and Prettier won’t fight with each other for the correct style.

The tslint.json file also goes into the user’s home folder, and is as follows:

{
  "extends": ["tslint:recommended", "tslint-config-prettier"],
  "rules": {
    "typedef": [
      true,
      "call-signature",
      "arrow-call-signature",
      "parameter",
      "arrow-parameter",
      "property-declaration"
    ]
  }
}

Notice this file’s name is not preceded by a dot (it’s not a hidden file).

Like before, we have extended a configuration to tell TSLint not to fight against Prettier.

At this point, we are ready to install the Visual Studio Code extensions. The ones we use are Prettier (esbenp.prettier-vscode), ESLint (dbaeumer.vscode-eslint) and TSLint (eg2.tslint). After installing them, add the following lines to the Visual Studio Code’s user settings:

"eslint.packageManager": "yarn",
"tslint.packageManager": "yarn",
"javascript.format.enable": false,
"typescript.format.enable": false,
"editor.formatOnSave": true

The lines “javascript.format.enable” and “typescript.format.enable” are set to false to disable the built-in formatter, and allow us to use Prettier correctly.

And we are done! Reload Visual Studio Code if you haven’t already, and the linting should work. Happy coding!

Emulating the Sharp X68000 and the Roland MT-32

Sun, 19 Nov 2017 12:05:00 +0000

Back then in the eighties there was this new technology called MIDI. It was the first attempt at a standard for electronic instrument synthesizers. Computers of the time, such as the Japanese Sharp X68000 usually came with some FM synthesizer such as the Yamaha YM2151, which modulates instrument sounds out of simple waveforms such as a square wave and changes its timbre by altering the frequency.

The Sharp X68000. Ain't that a beautiful piece of hardware?

Other more expensive devices however, had what’s called a wavetable. Wavetables are recordings of the actual instruments, of which many samples were taken and music was modulated by chosing the nearest ones and interpolating between them. One such device is the Roland MT-32 MIDI synthesizer, which cost almost US$700 back then in 1987 when it was released.

Are you ready to embark on an exciting adventure into emulation?!

The mighty Roland MT-32 MIDI synthesizer

Great! But before that, first a little bit of motivation (well, at least my motivation). There was this shmup I used to play in the Sega Genesis called Sol-Feace (which was actually known as “Sol-Deace” in the Genesis. Or as “Sol-Feaces” by the AVGN, but I digress). While reading about the Roland MIDI devices, I found out that one of my favorite games by Wolf Team, now Namco Tales Studio, supported the Roland MT-32 hardware in its Sharp X68000 computer version. I, of course, had to play that.

Front cover of the Japanese exclusive Sol-Feace release for the Sharp X68000

Now, we first actually need a Sharp X68000 emulator, which is not one of the top priorities in the emulation world, therefore there aren’t many quality options to be honest. Our best bet at this is the XM6 TypeG emulator (don’t worry, the actual emulator GUI is in English) (link updated on April 24, 2021). The installation is pretty straightforward, just extract the .zip you downloaded, and run the appropriate executable for your processor architecture, which are found in distinct directories inside the .zip file. You will also need the actual X68000 BIOS ROM files, which are public domain by now. Just google it, and put the files in the same directory as the emulator executable.

Note: People report that older versions of the emulator were region-locked to Japanese Windows for some reason. Given that I had no problems whatsoever, it appears this restriction has since been removed by the author.

Trouble, however, comes when you first try to figure out how you’re supposed to work with the 3 disks Sol-Feace is composed of. Yes, games spawned multiple disks back then.

The X68000 used 5.25" floppy disks, such as this glorious Wanderers from Ys one

The fact that most of the game is in Japanese doesn’t help matters too much. After fiddling with it for a bit, I figured out that you need disk 3 inserted into FDD0, and disk 2 inserted into FDD1 to get to the main menu. Disk 1 contains the intro, which you can skip entirely (if you wanna watch it, just put disk 1 in the FDD0 slot). At this point, you’ll be greeted with FM synth music being modulated by the internal Sharp X68000’s Yamaha YM2151 chip (emulated chip, of course).

The Yamaha YM2151 trying its best at "Cosmic Illusion", the first level music

You are, obviously, not satisfied. You need Roland MT-32 goodness in your life, right? At this point, you have two options: shell out around 170 bucks for a used Roland MT-32, and a USB-to-MIDI cable, both of which you can find on eBay. Some people go to great lengths to pursuit this kind of approach. Or you can use an emulator called Munt, which closely resembles the sound of the actual device, with some minor inconsistencies. You’ll also need the original Roland MT-32 BIOS ROM files, which are also public domain just like the Sharp X68000 ROM. Installation is also straightforward, and in the options you point Munt to the directory where the ROM files are located.

PhilsComputerLab posted this comprehensive guide for the installation of the Munt emulator. In our case, finishing step 2 will suffice

Now, while running Munt, open the XM6 emulator and go to the settings. There, you’ll find a tab for MIDI which you’ll have to set up like the screenshot below.

XM6 TypeG settings to pass-through the MIDI signal onto the Munt emulator device

To actually boot up the game in MIDI mode, you have to hold the 登録 key (the one next to the HELP key in the X68000 keyboard, and key number 53 in the emulator keyboard settings) right after you insert the disk onto the FDD0 port in the emulator. Hold it until the game’s splash screen appears, and you should see the emulated MT-32 LED display come to life in the Munt window. Success!!!

Munt emulator's screen showing the emulated LED display and the instruments' states

Note: After you make sure everything is working fine, you don’t need to have the Munt GUI opened to use the MT-32 emulation, it will work just the same regardless. Just don’t start playback with the window open, and then close it, or else it WILL break in this case.

Now you can listen to some proper game music!

"Cosmic Illusion" in its full Roland MT-32 glory

And thus, we have reached the end of our emulation journey, hope you’ve enjoyed the nostalgia trip, back to this era where stuff we take for granted today, was new and exciting!

As a bonus, here's further motivation with the Secret of Monkey Island theme!

The perfect programming font?

Sat, 22 Apr 2017 21:49:00 +0000

Ok I’ll share a secret here: I have a tendency to obsess over little details. A poet once said “it’s the little things that make the world”, and this is one of the greatest truths to me.

So let’s talk about one of these little things I can obsess about: fonts.

After having spent way more time than I probably should searching for the perfect programming font, I have come up with some candidates. My criteria includes first and foremost readability, but also character proportions, slashed/dotted zeros, l (L) vs I, and yes, even beauty.

One of the first fonts I remember using other than the Windows’ default Consolas was Inconsolata-dz (a variant of Inconsolata). It is a readable and beautiful font, but one of the little things that annoy me is the width and character spacing, which tends to spread stuff horizontally more than I’d like.

Then I tried Monaco, a font that ships with macOS (except I put it on Windows). It’s a very stylish one, for sure. I used it for quite a while, until I got annoyed by it’s, how should I put it, “opinionated” style. I don’t know, it’s as if it’s simply too stylish for a programming font. By the way, check out monofur if you DO like your stylish programming fonts.

Then I did try Source Code Pro for a while, but felt it suffered from the same problem as the Inconsolata family.

I stumbled upon mononoki, an awesome font. I ended up not using it after having some problems with JetBrains software, but I still think it’s a great font. Readable, good spacing, pleasant to look at.

I believe that’s around the time when I found about font ligatures. What it does is merge multiple characters into one, useful to turn stuff like ==, >= and =< that we use all the time into more pleasant-looking glyphs. So, the first ones I tried were Fira Code and Monoid. The problem is that, while the ligatures are pretty cool, for some reason I couldn’t get myself into liking these fonts’ styles.

Ligatures!

At this moment I felt like I’ve seen it all. As if I had mastered the Tao of Backup, but for fonts. That’s when I stumbled upon Input. It’s a non-monospace programming font. The blasphemy, right?! What about our carefully aligned ASCII art? Well, turns out you don’t really NEED a monospace font to program. It’s not like Sublime Text will yell at you or something. No, really, I promise. While I didn’t particularly enjoy Input’s look and eventually dropped it, I felt it’s a very important turning point for programming font development. You can design a font for programming and have it not be monospaced. I hope we get to see more of these with time…

So, what am I using right now? I’m currently testing this font called Iosevka. It’s a beautiful and readable font, and a pretty narrow one. Maybe a little bit TOO narrow, but I like it. Oh yes, it has ligatures too. Currently pairing it with the Hopscotch theme for Visual Studio Code (Yes, I think it’s better than Sublime Text, Atom and Brackets. No, it’s not a bloated mess like Visual Studio). I think it’s one of the most readable and pleasant-looking combos I’ve come up with so far.

My conclusion to this topic is that there’s no conclusion. Fonts are a very personal thing, people have different priorities and different aesthetics standards. So I encourage you to try out all these fonts and more to find the one that suits you the best. If you do, please report back in the comments!

Hopscotch + Iosevka in Visual Studio Code

Darkenizer - Dark theme generator

Sat, 08 Apr 2017 13:45:00 +0000

One of these days while I was preparing a dark version of a SCSS, I noticed this process could probably be automated with decent results. So I had the idea to make darkenizer.

darkenizer screenshot

It works by parsing the CSS/SCSS file searching for hex colors, and then transforms these colors into HSL color space. After that, it’s only a matter of inverting the “lightness” (L) channel to create a darker version of the color while preserving its original hue and saturation.

In the future I plan to add some configurations such as contrast, and an easy way to replace certain colors manually with a color picker.

It was developed using Vue.js, scss-parser + query-ast and hex-to-hsl + hsl-to-hex. I have to say it was a breath of fresh air using Vue.js after a year of Angular 2 development, but that’s subject for another post…

Trying out f.lux

Wed, 05 Apr 2017 23:55:00 +0000

I decided to try f.lux today. What is it you might wonder?

It’s a neat little software that adjusts the white balance of your monitor automatically according to your location and the time of the day. As such, you don’t get that harsh blue tint that keeps you awake at night (seriously, it can affect your sleep).

f.lux beta screenshot

Installation was very straightforward, and so are the options.

It does thake some getting used to, but after awhile if you look back at how it was you’ll squint your eyes in agony. So I’m guessing it’s doing its job.

Starting out

Wed, 05 Apr 2017 23:10:00 +0000

It’s time to start my own blog!

Here I will write about my software development findings, photography tips and ideas, music I like, or maybe some random thoughts I think are worth sharing.

The blog theme is based on Travelog.