HexChat @nick completion for Gitter

Composed on
April the 23rd, 2017

Gitter is a chat room system used by GitHub developers, that has an IRC "gateway" which allows users to access it via any IRC client; I usually have HexChat connected, then I prefer to use it instead of having yet another webpage open somewhere.

Since IRC mentions use simple suffix characters ("nickname: message") this doesn't work well with Gitter, which uses a much modern @nickname style; then I created a small Python script that allows this.

It works exactly like the default behavior, you begin typing the letters of the nick you want to refer to, then press the <TAB> key for completion. It's easy as it gets: it automatically adds the @ before the nickname and lets you cycle between all nicknames in the current room that match the letters you wrote.

Just as the other plugins, it has its small GitHub repository:

https://github.com/MaurizioB/hexchat-gitter-nick-completion

Hexchat notifications on alternate ALSA devices

Composed on
April the 23rd, 2017

As pointed out on Another post, I've a peculiar system with more than one sound card.
I use HexChat for IRC (a fork of the XChat project, almost dead by now) and I used to have sound notifications when anybody would type my name on a channel. HexChat uses Gtk2 and I don't use Gnome as my DE, hence I can't set a specific sound card for notifications; it can use libcanberra, but the problem persists.

Since HexChat has a Python builtin module for plugins I coded a custom plugin for it.
It allows you to set a custom sound file for nick notifications, and, most important, it allows you to set which ALSA device use for them. At this moment it can use hardware devices only, but I'm planning to support also "virtual" devices too, usually set using files like ~/.asoundrc or /etc/asound.conf.

The only requirement is pyalsaaudio, which you might already have if you are some sort of audio nerd like I am ;)..

You can download the script from my GitHub repository: hexchat-alsa-notify.

New morning.

Composed on
April the 23rd, 2017

I finally decided to do something with my website. It has been stuck like forever, and I really wanted to have a personal place for my music and gather other things.

I'm having a little blog too, where I plan to write just little updates, like this one. Apart from music, I've always had an interest in computer and technology, I usually think of a nerd/geek of myself. From time to time I've found myself lost in some little computer problem, a new piece of hardware, a software issue or a simple need transformed in a programming challenge. That's why there will be a computer related section of this website, about experiments (mostly on linux and/or python): things I had to try to solve using long and trying searches around the web, forgotten forum threads, unsolved issues posted by somebody who was so frustrated that gave up or didn't bother to post the solution.

So, that's it... Welcome to my little island!

NoLaE, a Novation LaunchControl Editor

Composed on
April the 23rd, 2017

About a month ago I bought a Novation Launch Control XL, it's a USB MIDI compliant controller, with 3 rows of 8 knobs, 8 faders and a lot of buttons.

It's a very well designed and versatile controller, and can be configured with up to 16 "templates", each of them sending different MIDI events for each operated controller.
Unfortunally, its editor is obviously available just for Windows and OSX.

It's not a big deal, but can be frustrating in some special cases: for example, some programs ignore certain CTRL values, so you would need an actual PC or Mac to edit it, and it seems that the editor doesn't work using virtualization.

So, I decided to write something on my own. It's called NoLaE.
It is a filter/mapper (actually, a sort of "proxy layer") that works between the Launch Control and your midi programs/outputs, and it's named NoLaE, which stands for Novation LaunchControl Editor, and means "little bells" in latin. Cool, uh? ;-)

NoLaE is written in Python 2.7, requires PyQt4 and mididings, which is a powerful MIDI router and processor based on Python, supporting ALSA and JACK MIDI.

That's how it looks, while in "live" mode:

The interface mimics the same layout of the Launch Control, so you'll be able to recognize what each knob/fader/button does at a glimpse, while hiding disabled controllers.

By default NoLaE will use factory default mappings, but you can map it to the current mapping using its mapping mode.
Once NoLaE has been correctly mapped, you can create configuration files that will use any of the existing 16 templates, and can be set to any of the output ports you want.

Using the editor mode you can enable every controller you want, set which LED (if any) you want to connect it to and tell what it will do using mididings patches.
You can also set output ports (up to 8 right now) and tell it to try to connect to MIDI devices (virtual or physical).

Right now NoLaE is still in "beta" stage, it's still buggy and some features don't work as expected, but it should be stable enough for live use. Just remember to test it carefully before using it for a live gig.

As soon as possible I will add a dedicated page for it, with a light but comprehensive manual, in the meantime I will correct major bugs and issues, but you can help me if you want by sending me messages and issues from its GitHub page.

Here is the NoLaE project page on GitHub.

Notifications using multiple ALSA devices

Composed on
April the 23rd, 2017

I have a really customized system, with 2 internal audio cards (the built-in HDA based one and an old SB Live! with a Live Drive module) and an external FireWire that I use for audio related work and study using the Jack Audio server.

Most of the *standard* audio is from web browsing (which means not only Youtube and general video, but also Netflix) and uses the default sound card, which I set for the Live! card, and is connected to the main jack system output. This can be annoying and distracting, expecially if you have a high volume set while working on audio stuff.

Then I realized that one of the monitors I use has its own embedded small speakers, which I don't use since they're obviously cheap and creaky. But they would come handy for system notifications, we don't need high-end quality for those, do we? The main "sub-layer" I use for my system is KDE based, even if I use fluxbox, so I dig up and found out I could set type based priorities for that.

So, if you have a KDE based system just run `systemsettings`, go to the multimedia panel, then go to the "Audio and Video settings", select "Notifications" in the "Audio Playback" section, find the preferred audio device and change its priority. As you can see, I've the "HDA Intel PCH [...]" card set with a higher priority than the "SB Live!".

(sorry for the italian localization, I couldn't set the english one, but I think you could figure it out anyway).
Then I just connected the audio input of that monitor to the audio out of the embedded sound card, and that's it! No more annoying notifications from the main sound monitor speakers!