Building a MIDI console with Arduino

I have recently been overwhelmed with what can be done with Audio on Linux. The DAWs, like Ardour, are not only free but also so extremely powerful you can actually do lots with it. I don't know if it would stand against the big guys but knowing there's no limitation for tracks, buses and the use of plugins it seems like the sound editing capabilities are only limited by the CPU power. Or are they?

Hardware to be made

In point of fact I am not a professional. I did take some piano lessons (my mum was a piano teacher and I was forced to follow in her footsteps for 5 years that I would rather forget) but beyond that and a few years of learning the theory of music I have no idea what I have set out myself to do. So what is it exactly that I'd like to do?

Well, it is not all that difficult. I think it is far more enjoyable to tweak all the knobs in a DAW if you have... welll.. knobs :D Moving them all with a mouse is just such a pain in the ass. So I have decided to make some hardware that will allow me to control the DAW with physical knobs.

Following are some basic ideas that I have that will allow me to complete my mission:

• Every mixer console has a slider for volume - I need one of those
• Every mixer console has a number of knobs that can be turned from left to right that will then change some parameter in the DAW - configurable. I need at least 8 if not 12 per channel
• I need a set of buttons that will control solo, mute and record per channel. I don't feel like pressing a key combination to achieve any of those
• I need a section that will have a master volume control as well as a set of knobs to control the output parameters. At least 8-10 for that purpose.

That brings me to a whopping 13 potentiometers per channel plus 3-5 push buttons and 11 for the master control plus some 10+ push buttons. No microcontroller can handle that amount of analog inputs alone. This is why I came up with the idea of modular design that will help me accomplish my goal (some time in the unforeseeable future :D).

The grand design

I don't want to be limited by the number of inputs at any stage. That'd be ridiculous. So instead of making an all-in-one design I am going for a modular, expand-as-you-go design that will allow me to basically define two types of modules:

• A channel module that will pretty much be a device on its own, handling all the analog and digital inputs and being an I2C slave that will allow a master to read the state of all the knobs at once
• A master module capable of recognizing all the connected slaves and sending their values over MIDI as they change

Each module will run its own ATMega382p (Arduino) with the necessary I2C hardware (like additional ADCs over I2C or I/O expanders if I choose to go with encoders rather than potentiometers). That way every module will be a slave and the master can ready the values of each control at a time of its choosing leaving the combining and transposition to MIDI commands to the master controller. Cool, ain't it?

Let the fun begin

So here I am, 3:40am, with that crazy idea in mind, putting it all on the blog. I really would like to make a big console for 32 channels but I think I'll start with 1 or 2 channels and the master to validate if the design scales.

Have fun! I know I will!

Vue.js and dialogs

Let's think for a moment about modal dialogs. What is their usage pattern? What are they for, I mean conceptually...

Dialog unveiled

When we create a dialog it is usually to gather some feedback from the user. It might be either a simple Yes / No or some form that the user needs to fill in and return that input after some form of interaction with that dialog.

Unfortunately there is no direct support for this kinds of interactions in Vue.js (nor in any other reactive framework, to be honest). This means that we need to resort to stuff like this:

data() {
  return {
    isConfirmationDialogVisible: false
  }
},
methods: {
  showConfirmationDialog() {
    this.isConfirmationDialogVisible = true
  },
  hideConfirmationDialog() {
    this.isConfirmationDialogVisible = false
  },
  handleConfirm() {
    this.hideConfirmationDialog()
    // the dialog ended with "OK" - perform some action
  },
  handleCancel() {
    this.hideConfirmationDialog()
    // the dialog ended with "Cancel" - do nothing
  }
}

The reason why we're doing all the state mutation nonsense in every place where we want to use a dialog is that the general approach in framework such as Vue.js is to base everything on state and we're completely ignoring the imperative nature of some of the processes. What is even more disturbing is that quite frankly the isConfirmationDialogVisible doesn't really belong with the place of use of the dialog. It should be an internal implementation detail of the dialog itself. But since we don't have implicit support for imperative programming with Vue.js it is sort of necessary to resort to stuff like that. But is it?

API is not just props and events

You might be tempted to think about the API of a component in terms of props that component accepts and events it emits. And even though they form a very important way of communication between parent and childs it is only 2/3rd of the story. Each method you define in the methods block is essentially part of the API of a component.

Suppose we have a dialog component that has the following two methods:

methods: {
  open() { ... },
  close() { ... }
}

Now if we use that dialog component somewhere it is quite easy to call those methods:

<template>
  <MyDialog ref="dialog" />
</template>

<script>
export default {
  mounted() {
    this.$refs.dialog.open()
  },
  beforeDestroy() {
    this.$refs.dialog.close()
  }
}
</script>

This means that we can imperatively steer when the dialog is open and when it closes. This way the state of visibility of that dialog is stored with that dialog and not in every place that uses that dialog which improves the usability quite a bit.

Promises, promises

Knowing that we can actually call methods on components let's move on to the concepts of modal dialogs.

Modal dialogs are dialogs that limit the possibility of user interaction to their content and usually finish with some result of that interaction. A good example is a popup that asks a question to which a user can say Yes or No or prompts the user to enter some data in which case there are usually two outcomes too: either the user entered the required information and approved his/her choice by pressing OK or resigns from proceeding, usually with the user of a Cancel button. It all bears a lot of resemblance to the alert() and confirm(), doesn't it?

The way it is usually handled in other frameworks (the Windows API, GTK just to name a few) is that the call to the framework method is blocking and once the user interaction is done it returns some result. In the browser a blocking code like that would result in everything going sideways. However, and this is where JavaScript really shines, there is a built-in concept of values that will be delivered later in time. This is the concept of Promises.

What if our dialog would expose a function like that:

methods: {
  async show() {
    return new Promise(resolve => {
      this.resolve = resolve
      this.show = true
    })
  },
  onOkButtonClick() {
    this.show = false
    this.resolve && this.resolve('ok')
  },
  onCancelButtonClick() {
    this.show = false
    this.resolve && this.resolve('cancel')
  },
},
data() {
  return {
    show: false,
    resolve: null
  }
}

Now that we have this we can use it in the code of a component that needs this kinds of interaction in a very nice way:

methods: {
  save() {
    const confirmation = await this.$refs.dialog.show()
    if (confirmation === 'ok') {
      // do something, the user is OK with it :)
    }
  }
}

The most important part of that approach is that you're not multiplying state that doesn't need to be multiplied and as a bonus your code expresses the intent: show a modal and react to the result of its interaction with the user

Have fun!

How to be successful when coding from home?

These are extraordinary circumstances for many organizations. The corona virus has forced a lot of people to stay home. This means that many people have found themselves in a situation they have never been before and might not feel very comfortable just being alone. In this post I'll try to share my tips for working remotely that I have gathered for over 7 years and being quite successful in it. Quite frankly I would never go back to the way things were before...

The bottom line

If you're like me and you don't feel like reading long posts here are the highlights:

• Control is good - trust is better and pays off in spades! It is especially difficult for managers when they have no oversight over their workers but it is absolutely necessary to hold your horses and let the situation settle. This is where many managers will fail and only the best ones will prevail. That being said it is equally hard on employees to trust themselves.
• If you're an employer you must believe in your people. They will do a good job even if it will take them time to adjust and get comfortable in the new situation. Judge the effects of work - not the workers - and remember that chemistry doesn't happen over night. Manage your expectations!
• If you're an employee know that working from home doesn't mean you're off work. It just means that you have a really small office. It needs to be properly equipped and comfortable. Keep up the good work and you will prevail
• Communication is key! Learn to use the tools at your disposal. Things like Skype, Hangouts, Zoom, Slack, Teams and Discord are there for you to take full advantage of what they provide. Make sure you have more than one tool at your disposal.
• Limit the necessary communication. It is the key to not getting distracted. There is no such thing as an urgent email. And it also means you need to have a discussion about it with your wife and kids. Be fair to your family!
• If you like working in pair use it to keep connected with your peers. Tools like VS Code combined with a voice call help you do that!
• Make sure you have more than one option to connect to the Internet. LANs do break and having a backup LTE connection will let you concentrate on work and it will put yours and your manager's mind at ease :)

And one last thing...

The thing I found most difficult is to accept yourself. There's nothing in the whole wide world that's worse than judging yourself over and over again to the point where you are so down you can't take anymore. There are times when we're overly productive and times when we suck, big time. No matter how you want to slice it the sine wave is the most perfect shape in the world. It's the rule all living things live by, no matter if they like it or not. Accepting it will help you understand where you are, where you are coming from and where you're headed.

Have fun!!!

If you made it here and want to learn more about my experience with working from home - read on :)

The circumstances

My adventure with working from home begun some 14 years ago when I joined Sabre inc. It was the first company that employed proper VPN technology and gave us all laptops to work on. Since many teams were dispersed throughout different continents it was obvious that from time to time you would work in crazy hours. For example we have had regular team meetings every Thursday at 8pm CET. Staying at work for so long, although possible, was in fact not very practical (not to mention my wife was not very happy about it).

On top of that there were times when I needed to work directly with a guy that lived on Hawaii. That's 12h difference from CET! To put it in perspective if some of you end your day at 5pm it was 5am (yes! the middle of the night!) for Walker. Walker was a very important person (a VIP you might say) because he was the original author of the software we were working on. So he has had all the intimate knowledge of the system and was the best person to learn from. Frankly I wouldn't like to be in his shoes getting up 4am just to have a call with some guys across the globe :) And did I mention I am not really a morning person?...

The solution

And so I came to the conclusion that it would make sense for me to start working in a timezone that's a bit of both: 2pm to 10pm. This would mean I would have plenty of overlap with Walker and the rest of the team based in the US yet enough time to take care of my daily business. The downside, though, was that there was nobody in the office after like 6pm and staying alone in a huge office wasn't my idea of fun. So I worked remotely for half a year. There were no papers to be signed, no permissions to be given - just my personal decision to have more time with the guys overseas.

The first few days it felt really strange. I was organizing my home office for a few hours, reorganizing my desk every now and then to fit the new situation, then doing a bit of project work, having lots of time with the rest of the team in the States and in the evening watching a movie with my wife after work. The adjustment period went on for about a week and after that it felt like I was doing it forever.

Now that I think about it in fact I was doing it forever - just didn't realize it! I am a self learner. I didn't finish my study at the university, I wasn't particularly good in high school and even in ground school things were not looking very up for me. All because I preferred spending time coding. Yes, I started coding at the age of 12 and I knew I wanted to be a programmer when I was 6 years old :)... Quite frankly I don't know how I managed to meet that wonderful girl that I spent over 23 years with :) I think I just got lucky!

Communication

I am an introvert. My wife would say that's not really true but I know how I feel inside. It isn't a bad thing - it just means I can concentrate better when there's less people around me. Sure there are times when I am fed up with just my 4 walls and I am looking for some company. But that grows old very soon for me. Even though I can literally see the office from home with a naked eye I go there maybe once a month, often times even less. I found that it is way more productive if I can shut out everybody and just do coding. That led me to employing rules like checking emails only in the morning, keeping to the necessary minimum my interactions on Skype - you know what I mean.

How does that help you?

Using multiple ssh keys with Github (or any other host)

Imagine you're working on one machine with multiple clients. In that case each client might require you to have a separate account on Github. This means that you need to have separate SSH keys for those accounts too and that in turn means is a pain in the butt to have it working.

If you're on Linux (and probably MacOS too) there's hope for you! Follow those simple steps to get everything setup so that you won't even notice it is there!

Step 1: Add a host entry in ~/.ssh/config

Host client-github.com
     Hostname github.com
     User git
     IdentitiesOnly yes
     IdentityFile ~/.ssh/client_rsa

This allows you to connect to a host named client-github.com which will in fact connect to github.com but with a specific identity file (ssh key)

Step 2: Add the following 2 entries to your ~/.gitconfig

[url "ssh://git@client-github.com/client"]
        insteadOf = ssh://git@github.com/client

[url "ssh://git@client-github.com/client"]
        insteadOf = git@github.com:client

Using client-github.com is not really practical. There are instances (like linked npm modules from github.com) where you're not directly in control of the hostname. That's where the URL substitution in Git comes in handy. Whenever someone requests a URL from the client's namespace we substitute it with our custom address and everything's golden

Obviously if you substitute the client part of the custom hostname with the name of the client it will be easier for you to manage multiple such cases :) Just sayin'...

Have fun!