Arduinos, FDTI and general grief

This is more of a note to self than anything else.

I inadvertently purchased some clone Arduino Mini Pros, insted of Minis, the difference being that that latter has a USB port onboard. Oh well, that meant securing an FTDI board or two, no problem there.

When they arrived, however, the pinouts on the FTDI boards were not labelled in a corresponding manner to the boards. Which wire went where? Who knows?

Some hunting later it ocurred to me that by simply plugging them both into a breadboard they would probably work just dandy. So, in went an arduino and an FTDI board head-to-head. Nada.

The magic happened once I downloaded a driver from here: from http://www.ftdichip.com/FTDrivers.htm and that’s all it took.

A sticky Alt key

Blender offered up a strange problem the other day. For some reason, the Alt key was behaving as if it was sticking, making it impossible to Alt-select edges.

I finally tracked this down to a keyboard shortcut I had set up for alternating between languages. This is quite simple to do in Ubuntu and offers up all sorts of possibilities, and I had set it to change when pressing both Shift keys simultaneously.

Once that was changed to something else (Windows key and Space bar) everything worked hunky-dory.

Update:

In a recent re-install of Ubuntu, I cam across the same problem, but this time the above solution did not work. It was resolved by doing the following:

Use CompizConfig Settings Manager (ccsm – install it if you need to), click through to the “Windows Management” subsection and then click into “Move Window”. In the “Initiate Window Move” option, change the button value from <Alt>Button1 to (for example) <Super>Button1. Hey presto, you can now move windows by holding down the Windows key and Button1 on your mouse, and Alt for loop select will work just dandy!

Sound advice

For ages I nursed along the previous incarnation of my computer until finally the day came when it’s fragmented memory gave up the ghost.

One new motherboard, processor and handful of RAM sticks later, I booted up my existing Ubuntu installation to find…that it was business as usual, just at hyper-speeds. Whereas previously I had 4GB of RAM, now I had 16GB, with space for another 16GB should the need arise. Against the previous 2.8GHz was 4GHz, and the motherboard made little difference other than having a shiny new BIOS.

One small spanner in the works though was the sound. It was horrible. It did not take long to discover that the on-board sound of the MSI Z97 Gaming motherboard was the issue, as ALSA did not like the Realtek ALC1150 Codec. Gah.

MSI have not yet discovered Linux, so I did what would appear to be the obvious and installed the Linux drivers from Realtek which was a whopping disaster. All manner of horrible things went wrong. Avoid like the plague.

I tried so many different things and forget what most of them were, but the very last thing I did was to try this advice from this page, albeit using Synaptic instead.

In short, I reinstalled the current kernel, linux-sound-base, alsa-base, alsa-utils, linux-image-“insert your kernel version here”, did not bother with linux-ubuntu-modules-“insert your kernel version here”, but did with libasound2.

Took a deep breath. Rebooted. Cranked up the amp, the volume on my PC, woke the dead.

Epson Perfection 1650

This is a little by-the-by, an aide-memoir.

After upgrading some hardware and hacking around my Ubuntu 14.04 installation, my Epson Perfection Scanner refused to do anything but whine. Literally.

Some frustrating hour later – frustrating because I have gone through this process on a previous occasion and forgotten to record the results of my cyber perambulations – I finally discovered the magic that would calm the whining little thing down and get it to do useful things, like scanning.

It is is simply this: open /etc/sand.d/dll.conf and place a # in front of the word epson2 and remove the # from in front of the word epson.

You should have something that reads like this:

dell1600n_net
dmc
epjitsu
epson
#epson2
fujitsu
#gphoto2
genesys
gt68xx

Convert in python shell script

This is really more of a reminder for me than anything else.

Convert is a tool from the same stable as Mogrify, and is an absolute life-saver when working with large batches of images.

Just the other day I was using it to crop some 2000 jpegs which were scans of pages from a rather thick book. The odd and even pages were offset, by which I mean that the space on the outside of the page was greater than on the inside, and I wanted to crop the pages so that they looked pretty even.

Not wanting to do this all by hand, I wrote a Python shell script to process the files.

 

#!/usr/bin/env python3

import subprocess
import os
import sys

path_to_jpegs = "/home/dani/big fat book/pages/"

path_to_output = path_to_jpegs + 'cropped/'

print('starting...')

file_path = path_to_jpegs

# loop through all the images in the specified folder
for filename in os.listdir(file_path):
    if ('.jpg' in filename):    
        print('@@@ processing file: ' + path_to_jpegs + filename)

        # file number is needed in order to determine of the file is an odd or even page
        dot_pos = filename.find('.')
        file_number = int(filename[:dot_pos])
        
        # switch coords depending if this file is even or odd
        # left page
        if (file_number % 2 == 0):
            #coords = '1940x2720+966+240'
            coords = '1940x2720+400+238'
        # right page
        else:
            #coords = '1940x2720+400+238'
            coords = '1940x2720+966+240'
        
        subprocess.call(['convert', '-crop', coords, path_to_jpegs + filename, path_to_output + filename])

Mogrify – more pleasant than it sounds

If you are lucky or smart enough to use Ubuntu, then you have a wealth of tools sitting just under your keyboard that you might know owt about.

Two of those are the convert and mogrify tools, which come from the Imagemagick stable. I use these quite frequently for batch conversion jobs.

Here is an example of what these tools can do, specifically mogrify which acts on batches of files.

I have a folder load of transparent images that the client wants on a white background, so I open the command line, navigate to that folder (or just open the command line in that folder directly using Nemo instead of Nautilus) and type the following incantation:

mogrify -format jpg -quality 100 -fill white -opaque none *.png

If we break this down into individual components, then

mogrify this is the command itself

-format jpg The output format, in this case jpg

-quality 100 for jpgs specifies the compression or quality levels. 100 is tops, 1 is rubbish.

-fill white the colour of the fill which will be determined by the next command.

-opaque none deals with the alpha (transparency) channel, by filling it with a colour, which has handily just been specified.

*.png simply tells mogrify to grab any file that ends in “.png”

 

Context woes

This hardly warrants anything more than a few quick lines.

This line was bombing out:

bpy.ops.object.modifier_apply(modifier = 'Bla')

Well, the “wrong context” error reared its ugly head. That’s because there was nothing selected in the scene, even though there was an active object.

So, when calling the above operator, ensure that there is a selected, active object in the scene.

Calling

bpy.data.scenes[0].objects.active = some_obj

can save lives.