#TIL the direction of a pcbnew (KiCAD) selection changes its behaviour. LtoR only selects completely surrounded parts, RtoL selects partially selected parts.
I can’t find this feature documented anywhere, but the selection colours are different so I assume it’s supposed to be like this.
EDIT: apparently it’s something of a de-facto UI standard in CAD apps, probably started by AutoCAD.
It just took me about 30 mins to figure it out, so here’s how to install python plugins in KiCad 5.0 on a Mac.
- Make sure your build of KiCad has scripting enabled. It looks like fresh downloads have it by default, but it doesn’t hurt to check. Go KiCad → About KiCad → Show Version Info and make sure that all of the
KICAD_SCRIPTING_flags are set to ON. - Find pcbnew’s plugin search path list. Open pcbnew, and open Tools → Scripting Console. Run
import pcbnew; print pcbnew.PLUGIN_DIRECTORIES_SEARCHand you’ll see a list of folders which pcbnew will search for plugins - Move your plugin files/folders to one of these locations
- In pcbnew, Tools → External Plugins… → Refresh Plugins. Your Tools → External Plugins menu should fill up with plugins.
For anyone building theSlowGrowth’s Monome Arc clone project, here are the avrdude commands required to set the ATMega88p fuses, based on this fuse calculation:
avrdude -V -p m88p -c YOUR_PROGRAMMER_ID -P YOUR_PROGRAMMER_PORT -B 10 -e -u -U lfuse:w:0xD6:m -U hfuse:w:0xDF:m -U efuse:w:0xF9:m -U lock:w:0xFF:m
and then flashing the precompiled firmware is pretty straightfoward. USB board: (swap arc4_ for arc2_ in the unlikely event you’re building an arc2):
avrdude -V -p m88p -c YOUR_PROGRAMMER_ID -P YOUR_PROGRAMMER_PORT -B 2 -U flash:w:./firmware/compiled_hex/arc4_firmware_usb_board_atmega88p.hex:i -U lock:w:0xFF:m
and for each ring:
avrdude -V -p m88p -c YOUR_PROGRAMMER_ID -P YOUR_PROGRAMMER_PORT -B 2 -U flash:w:./firmware/compiled_hex/firmware_pot_board_atmega88p.hex:i -U lock:w:0xFF:m
Note that the verion of avrdude I’m using (5.8, from an old crosspack install I was using to compile some MI AVR code) doesn’t support the ATMega88p, and in order for any of this to work, you may need to edit the avrdude config file according to the instructions in the arc clone repo. Mine was in /usr/local/CrossPack-AVR-20100115/etc/avrdude.conf, and all I had to do was duplicate the config block for the ATMega88 and make the following changes:
id = "m88p";
desc = "ATMEGA88P";
and
signature = 0x1e 0x93 0x0f;
Turns out that it’s possible to use cheaply available (~2€ each) 7-pin SPI OLED displays with the magpie modular 8hp microbraids PCBs. A hardware and software modification are required, although as the ATMega is using software SPI it may be possible to work around the hardware modification with further software modifications.
Please note that I would not recommend building the magpie modular micro braids module! Instead, try one of the newer adaptions (e.g. the one from Antumbra) which uses normal LED displays and have prettier panels. This guide is intended as reference for people who still have one of the old boards lying around and want to get it working without shelling out 20€ or more for a tiny OLED module.
The seven pin SPI header on the cheap OLEDs I bought maps to the eight pin header of the original Adafruit OLED (and therefore the microbraids PCB) like this:
CS DC RS MOSI CLK Vin GND | X X | \ CS RS DC CLK MOSI Vin 3.3v GND
I cut the relevant traces on the OLED board, scratched away some solder mask and used enamel-insulated wire to connect the traces to their new pins. Then, I installed a 7 pin female header on the braids PCB, and bridged the 3.3v and GND pins, which sounds like a terrible idea, but the board doesn’t make any use of the 3.3v pin, I’m just using it as a convenient way of connecting the OLED GND pin to the braids GND pin.
If your OLED module has the same layout as mine, it should end up looking something like this:
The display ends up being in a slightly different place to the original, but five minutes of filing the aluminium panel fixed that. It ended up looking a little bit messy, but the panel (from pusherman, not a magpie modular original) is extremely ugly anyway so it didn’t make much difference. I quickly cut out and filed a 3mm acrylic screen, wedged it in place and secured it with some high-viscoscity superglue.
After reflowing and flashing both the ATMega and STM, everything was working perfectly, except the display was upside-down. Looking through the Adafruit graphics library led to a simple solution: adding the following line to the init function on line 39 of mbraidsv3.ino:
display.setRotation(2); // Invert display for use with cheap Aliexpress 7-pin OLED
After re-flashing the ATMega, everything worked perfectly.
It was only after I made the hardware modification that I noticed the ATMega is using a software SPI library, with the pin definitions on lines 9-13 of mbraidsv3.ino. It should therefore be possible to achieve exactly the same result by leaving the OLED module unmodified, bridging the 3.3V and GND pins on the 8 pin OLED header on the PCB, and swapping the pin definitions around so they look like this:
#define OLED_MOSI 10 #define OLED_CLK 9 #define OLED_DC 13 #define OLED_CS 12 #define OLED_RESET 11
The display rotation mod will still be necessary, unless your display module is oriented differently. If anyone attempts the software modification please let me know, I’d be curious to know if it works!
It is possible, if somewhat awkward, to update the Mooer Ocean Machine firmware on a mac using Wine and a cheap USB MIDI cable.
WARNING: if the firmware update doesn’t complete successfully, it will not permanently brick your unit (as the update can always be attempted again) but the pedal will not work until a firmware is successfully installed! Attempt at your own risk, and definitely not 10 minutes before a gig.
First, download the update from the Mooer website. The update and update software comes in a .rar archive, so you’ll need something like The Unarchiver to unpack it.
You’ll need the latest version of Wine for Mac from winehq.org. I successfully installed the firmware update using 3.0.2. Using version 2.0 consistently failed.
Power on the Ocean Machine in firmware update mode and plug in your USB MIDI cable as specified by the update readme. Check in Audio MIDI Setup that it’s working and recognised. Then, launch the updater using Wine. Select the firmware update file, then click “Update”. You might get a popup window helpfully saying “MIDI Device Error!!”. Try pressing Update again, if you’re lucky it will work. If not, open Terminal and try the following solution.
The problem with (old versions of) Windows, Wine and this updater program is that they rely on the “MIDI device mapper” utility to decide which MIDI device to use. This would be fine, but under Wine for Mac there’s no easy way of seeing a list of devices or configuring which device to use.
It is possible to change the default MIDI device used by the MIDI mapper, by creating a text file with the following code:
REGEDIT4
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap]
"CurrentInstrument"="#1"
#0 is the default device, so start at #1.
I saved mine in MMap.ini. Then, run the following command:
wine regedit MMap.ini
and re-open the update app. If after two presses of Update you still get “MIDI Device Error!!”, then quit the updater, change #1 to #2, run wine regedit MMap.ini and try again. Repeat until successful. Yes, the update process sucks.
Finally figured out how to format a memory stick for optimal compromise between compatibility and file sizes.
The goal is to be able to stick this memory stick in anything from the last 15 years and be able to load files on and off. The implementation idea was to have two partitions, one FAT32 for compatibility with everything, and one ExFAT for wide compatibility allowing larger files.
The mistake I made last time was using a GUID-based partition map, which rules out compatibility with older hardware which uses a BIOS. This can be rectified by using the older Master Boot Record partition map, which has some restrictions, but nothing particularly relevant in this case.
I had no end of problems trying to achieve this with the Gnome Disks tool and GParted, and on Mac OS 10.11 it’s not possible in the Disk Utility GUI. It is, however, very easy using the command line Disk Utility tools.
Firstly, run
diskutil list
to find out the descriptor for the device you want to format (e.g. /dev/disk2, referred to in future examples as /dev/diskX), then
diskutil unmountDisk /dev/diskX
to unmount it in preparating for formatting. I’m formatting a 64GB flash drive with 62.1GB actual capacity into two equal portions, so my command ends up looking like this:
diskutil partitionDisk /dev/diskX MBR ExFAT NAME_OF_FIRST_PARTITION 31.1g FAT32 NAME_OF_SECOND_PARTITION 0g
where the format is pretty self explanatory:
volume partition_map partition_1_format partition_1_name partition_1_size partition_2_format partition_2_name partition_2_size
The size of partition two is given as 0g, which results in the rest of the available space being taken.
A list of available filesystems for formatting can be browsed with:
diskutil listFilesystems
I just tested the newly formatted universal memory stick with a computer with which it previously didn’t work, and it worked perfectly, so I’m confident that this approach achieves my original goal.
How to emulate standard #php front-controller behaviour of routing static assets statically, otherwise calling index.php using the PHP 5.4 built-in server:
// file: index.php
// Route static assets from CLI server
if (PHP_SAPI === 'cli-server') {
if (file_exists(__DIR__ . $_SERVER['REQUEST_URI']) and !is_dir(__DIR__ . $_SERVER['REQUEST_URI'])) {
return false;
}
}
// do usual front-controller stuff
I just faked having a task queue for #taproot #indieweb note posting tasks using Symfony HttpKernel::terminate() and it was the easiest thing ever.
Instances or subclasses of HttpKernel have a terminate($request, $response) method which, if called in the front controller after $response->send(); triggers a kernel.terminate event on the app’s event dispatcher. Listeners attached to this event carry out their work after the content has been sent to the client, making it the perfect place to put time-consuming things like POSSE and webmention sending.
Once you’ve created your new content and it’s ready to be sent to the client, create a new closure which carries out all the the time consuming stuff and attach it as a listener to your event dispatcher, like this:
$dispatcher->addListener('kernel.terminate', function() use ($note) {
$note = sendPosse($note);
sendWebmentions($note);
$note->save();
}
Then, provided you’re calling $kernel->terminate($req, $res); in index.php, your callback will get executed after the response has been sent to the client.
If you’re not using HttpKernel and HttpFoundation, the exact same behaviour can of course be carried out in pure PHP — just let the client know you’ve finished sending content and execute code after that. Check out these resources to learn more about how to do this:
- FPM, specifically
fastcgi_finish_request() flush()HttpFoundation\Request::send()as a sample implementation
Further ideas: if the time consuming tasks alter the content which will be shown in any way, set a header or something to let the client side know that async stuff is happening. It could then re-fetch the content after a few seconds and update it.
Sure, this isn’t as elegant as a message queue. But as I showed, it’s super easy and portable, requiring the addition of three or four lines of code.
Optimal video-splitting workflow on a mac:
- In Logic/QuickTime 7, figure out each of the ranges of video you want
- Open the movie in QuickTime 10
- Cmd + T to enter trim mode
- Set the handles to your range
- Cmd + shift + S to save as
- Close movie (export will continue)
- Repeat from 2 until complete
Toggle commentedness in CSS with just the first /*:
/* css.code:to { be: toggled; } /**/