Huffduffer Radiodan part 3 – using the switch with Radiodan code

Update: a step by step how-to is now available.

Yesterday I got a microswitch working – today I want to make it turn on the radio. Given that I can only start my podcasts in client-side mode at the moment, I’ll have to bodge it a bit so I can actually see it working (Andrew is going to help me understand the server side API better tomorrow).

So my plan is to

1. Switch back to the radiodan “magic button” radio
2. Make my switch replace the default on button
3. Make my switch turn the radio on when it’s open

and if I have time

4. attach a simple rotary encoder for volume
5. attach an RGB LED for the status lights

For the magic button radio, we have had some simple PCBs made to make the soldering easier for two RGB LED-rotary encoder-buttons, but it doesn’t fit in my new box, and anyway, I want to see how difficult it is without the PCB.

It’s 3pm now and I have about an hour free.

Switch back to the radiodan “magic button” radio

This is easy. I’ve sshed in and do this:


pi@radiodan-libby ~ $ sudo radiodan-device-type

Current device type: radiodan-type-huffduffer
Device type required. Valid types radiodan-type-example, radiodan-type-huffduffer, radiodan-type-magic

so I do


pi@radiodan-libby ~ $ sudo radiodan-device-type radiodan-type-magic

and reboot

Once we’re back up, if I go to http://radiodan-libby.local I should see the full-fledged radio interface, but I don’t, I just see my Huffduffer one.

huffer_screen1

I guess I messed up Monit or rc.d. Looking at ps ax | grep node, both versions are running.

looking at ls /etc/rc*.d

radiodan-huffduffer is in there but not magic, so I remove it from rc.d


update-rc.d -f radiodan-huffduffer remove

reboot

and that fixed it.

magic

I’m testing it by doing


sudo radiodan-device-type radiodan-type-huffduffer

reboot


sudo radiodan-device-type radiodan-type-magic

reboot

to check I’ve got it switching properly, and it is.


ps ax | grep node

gives us among other things


node /opt/radiodan/apps/buttons/current/bin/server /opt/radiodan/apps/magic/current/config/physical-ui-config.json

/opt/radiodan/apps/magic/current/config/physical-ui-config.json is the config file for the physical buttons, dials etc.

catting that file gives us (among other things)


{
"id": "power",
"pins": [
{
"pin": 3,
"pull": "down",
"pressedIsHigh": true
}
]
}

so I want to

  • move my button to pin 3 from 17
  • change pressedIsHigh to false (because I want it to trigger when not pressed)
  • is that it?

For now I’m just trying to see if the pin 3 works. If I touch the croc clips together and look in


tail -f radiodan-buttons.log

I can see this:


-1
1
-1
1
-1

so it seems to be working, but I can see in the web interface that it’s not turning on.

[debugging session with Andrew]

I had the pin wrong – we use the wiringpi ones, so 3 is the 8th on the left working downwards: http://pi4j.com/pins/model-b-plus.html

I was using one of the rotary encoder pins.

Also I need a pullup resistor because it’s attached to ground, not 5v (the rotary encoder-buttons work a bit oddly, a better example is “next” in the config file.)

and


{
"id": "power",
"pins": [
{
"pin": 3,
"pull": "up",
"pressedIsHigh": false
}
]
}

(then sudo monit restart radiodan-buttons )

This is the correct config, as the rotary encoder that usually does the ‘on’ button is usually connected to power. So now it goes and on and off when I touch the croc clips together. Fixing them to the switch as before, it goes on when I press it down. I need it to go on when my button is not pressed. I’m not sure how to do that, and I’m 30 mins over time so I’ll leave it till tomorrow.

Andrew also says: “you may want to copy that config file somewhere since any new software updates will overwrite it — a current limitation of our update software”

To see the things controlled by monit:

sudo monit summary

This stops it monitoring a script that turns the radio off when the power button is held down for 3 seconds:

sudo monit stop radiodan-cease

and this:

sudo monit stop updater_status

stops the updater (both between reboots)

Huffduffer Radiodan part 2 – a switch

Update: a step by step how-to is now available.

I wanted to make a nice box for the radio, and yesterday bought this jewelry-box-size one from “Craft and More” in Bristol for £5:

box

I was thinking at first I would drill a large hole in the top to replicate the current radio design, but then realised I was missing a trick: clearly, when you open the box, the radio should turn on. Damian suggested I use a microswitch – this one was £2 at Maplin:

microswitch

I’m going to have to rearchitect the whole software side, unless I really make it hacky – I need to put the load commands on the server side not the client side, and that will have to wait, but I figured at least I could test the switch before I hook it up to the Radiodan infrastructure.

I’ve temporarily bluetacked a bit of balsa wood into the box, and now I’m going to attach the switch to the GPIO, using these instructions to pin 17 on this diagram (I don’t need a pull up resistor as I can use one of the pins with a software pull-up later, I think, anyway, seems to work).


import RPi.GPIO as GPIO
import time

GPIO.setmode(GPIO.BCM)
GPIO.setup(17,GPIO.IN)

#initialise a previous input variable to 0 (assume button not pressed last)
prev_input = 0
while True:
#take a reading
input = GPIO.input(17)
#if the last reading was low and this one high, print
if ((not prev_input) and input):
print("Button pressed")
#update previous input
prev_input = input
#slight pause to debounce
time.sleep(0.05)


sudo python test_button.py

The microswitch has 3 legs, one for ground, one for triggering when open, and one closed. I want the middle one, so that it triggers when open (“NO”).

So now I can use a tiny screw I found in a drawer to fix the switch inside:

switch_box

and I had the wrong corner for the box, initially, and had to squish down my power and ethernet cables to test it, but it works.

Next steps: get it working with the Radiodan GPIO software.

Huffduffer Radiodan

Update: a step by step how-to is now available.

I’ve been wanting a physical radio that plays podcasts for a long time, and it’s something we’ve discussed quite a lot in the Radiodan team. There’s no real reason why not – Radiodan plays MP3s because it uses MPD. and I occasionally talk about a ‘Cambrian explosion’ of radios – we think that Radiodan will be able to let us quickly try out new ideas like this one.

So I want to do something very quickly – 1 day out of my 10% time, and see how far I get.

I also want to use Richard Pope’s checklist for new projects – so these are my notes (Richard’s point 6). This post will therefore change and be added to as I go along.

Background

Radiodan is a radio experiences prototyping platform that we are using at work to show what radio could be like. It’s a Raspberry Pi in a nice box with custom software written in node.js to play audio internet streams and run a webserver to help you control it. There are also physical buttons and dials and some work around easily(ish) getting it on the wifi. The idea is to show what’s possible and test what’s sensible. It uses internet streams – not DAB or FM – because we can quickly show interesting things using streams only. We can make something that acts like a radio without building all the pieces.

Browsing around yesterday I re-found Huffduffer, a really nice service and site by @adactio that allows you to find audio files on the web and add them to a collection – and RSS feed – and also to follow other people, subscribe to RSS feeds from specific events. That seems like a perfect fit for a podcast Radiodan.

Checklist

Here are Richard Pope’s checklist items, which you should read in full:

1) Know your history.
2) Read the legislation.
3) Draw the thing
4) Understand the state of technology
5) Seek out metaphors.
6) Keep notes, share notes.
7) Keep a list of user needs.
8) Sketch in code.
9) Get a prototype in front of real users.
10) Throw your prototype away.

To add to that, my colleague Tristan’s written about types of prototyping – I need to work out what fidelity I need to make the prototype. Obviously I’d like something that actually works, but probably don’t have time for that.

Initial idea

  • A physical radio that plays podcasts like a radio station
  • maybe with some sort of RFID(?) interface that allows you to flip between different collections

Todo list

00. Start a product checklist
0. start with a standard radiodan, set it up and get it working
1. Fork the simple version of the radiodan client (there are two types of radio currently)
2. See if it’ll play an mp3 as a stream
3. Hardcode an RSS feed and display the result in the controller webpage
4. Try RFID to flip between different RSS feeds?
5. Invent a nice case
6. Document everything
7. Fin

Know your history

I’m doing a quick search for:

  • projects that are very similar (e.g. raspberry pi podcast players)
    • Podcast downloader/player – can I use Podget? nice list of features needed at a minimum, and interesting “WiFi dongle with an antenna to keep one device in my car”
  • podcast players in general (for interface issues)
  • List of Radiodan postcards for similar things
    • I think the closest is ChrisG’s radio, though there are several where podcasts are one element of a more complex radio.

For podcast players in general, I think it actually makes more sense to try some out, but not sure I have enough time, so going with my current experience:

I do use the one on my iphone, and it’s very annoying

  • it seems not to delete things and so the disk fills up
  • it constantly nags to be online
  • its sleep timer doesn’t work properly so sometimes I end up listening to in our time all night while asleep, which is weird

however:

  • it does mark new things as new, and listened to as listened to
  • it remembers where I am in the podcast (that seems pretty important)

2) Read the legislation

I hope / think I can skip this one. Vaguely related, here’s a note on Huffduffer’s terms of use.

3) Draw the thing

We have a Radiodan ‘process’ for some of this. Here’s my postcard:

huffduffer_radiodan

I think the checklist item is more general than that though:

“Aim for something that represents the totality of the service – a mental model for yourself, and something to help you explain it to others.”

huffduffer_radiodan_story

A few things came out of this

  • I don’t know whether I can stream the mp3s or need to schedule their downloads
  • I don’t know if I need a Radiodan web interface or not. That’s sort of interesting.
  • Forgot to draw the RFID bit

4) Understand the state of technology

“Spend time understanding the state of technology and design right now. Assume it has changed since you started your last project and that your knowledge is out of date.”
“Actively seek out ideas that you can steal to solve the problem at hand.”

The research part missing here was to do with how radios handle these kinds of problems. Here’s a quick bit of research:

5) Seek out metaphors.

Something like “your home-made radio station”.

6) Keep notes, share notes.

These are them. Though maybe I should have used github so I got version control.

7) Keep a list of user needs.

A few are emerging, I’m sure there are more:

  • Remembers where you are in a podcast
  • Some way of managing of podcasts (maybe just the Huffduffer site? does that make any sense?
  • Somehow you need to decide what goes on the radio, so assuming Huffduffer, that means either pairing to an account or some other way of telling it the RSS feed you’re interested in
  • Maybe: new podcast available?
  • Mark new items as new (how?)
  • Volume, on / off

8) Sketch in code.

I’ve been working for about two and a half hours, so on my self-imposed timetable I need to get moving to make something. I’m going to try and adapt one piece of the current Radiodan codebase – a very simple interface – to try and use it for podcasts. Radiodan can have different brains swapped in – a more complex one is the magic button radio – which is a more fully-featured radio experience, but also more complicated to hack on.

Maybe I need lunch first actually.

0. start with a standard radiodan, set it up and get it working

I’m cheating a bit here. I already have one I prepared earlier. The basic steps are outlined here:

  • download a card image (we need to make a new one)
  • put it on a pi
  • assemble the bits
  • turn it on
  • do the wifi dance to get it online
  • turn it on using the buttons or the web interface

Here’s mine with the back off so I can ssh to it over ethernet shared from my mac – typically wifi is slower for that kind of operation.

radiodan

Intermission – Catwigs

Catwigs are a project I’ve been working on with Richard Sewell. They’re a way of talking and thinking about your project to make sure you haven’t missed anything important. I forgot to do them for this project. One moment please….

catwigs_huffduffer_radiodan

Basically you shuffle the 22 cards, pick 7 and then decide their orientation based on your project, and then talk about how to improve the ones facing downwards.

For this project, I think it’s reasonably clear what it is, I hope to make it usable, though probably only averagely so, given my limited UX skills; it solves a problem for me (but not a terribly important problem, and it might be quite niche); I think it will generate ideas because physical prototypes often do; it should benefit people (it certainly won’t take anything away and might even increase the amount of knowledge in the world), and it’s in our best interests in order to test Radiodan. It won’t make us any money, but that’s ok.

Sketch in code (cont)

TODO: 1. Fork the simple version of the radiodan client (there are two types of radio currently)


# check the example type radiodan works
sudo radiodan-device-type radiodan-type-example
sudo reboot
# go to http://radiodan-libby.local
# play a stream (works)

# make a new device type
# clone my fork
cd /opt/radiodan/apps
sudo git clone https://github.com/libbymiller/client-web-example.git
sudo mv client-web-example client-huffduffer
cd client-huffduffer
sudo chown -R pi:pi .
# change repo name in the web interface (https://help.github.com/articles/renaming-a-repository/) and in the client:
sudo git remote set-url origin https://github.com/libbymiller/client-huffduffer
# make a little edit so that we know the right one is running
# e.g. in /opt/radiodan/apps/client-huffduffer/static/index.html
git add .
git commit -m "Small edits"
git push
npm install # this takes a few minutes. I had to remove references to avahi and mdns to make it work, but we don't need that for now.

# add to init.d
cd /etc/init.d/
sudo cp radiodan-example radiodan-huffduffer
# make appropriate edits, including this:
# DAEMON_OPTS="/opt/radiodan/apps/client-huffduffer/main.js"
# then
sudo pico radiodan-huffduffer
sudo chmod 755 /etc/init.d/radiodan-huffduffer
sudo update-rc.d radiodan-huffduffer defaults
sudo update-rc.d radiodan-huffduffer enable

# add to monit so we can switch between them
cd /etc/monit/monitrc.d/
sudo cp radiodan-type-example radiodan-type-huffduffer
# make edits to replace radiodan-example in that file

# now:
sudo radiodan-device-type
Current device type: radiodan-type-example
Device type required. Valid types radiodan-type-example, radiodan-type-huffduffer, radiodan-type-magic
sudo radiodan-device-type radiodan-type-huffduffer
sudo reboot

After a bit of fiddling that worked, so I now have a basic radiodan instance with an interface I can change, and it’s all in github.

Todo: 2. See if it’ll play an mp3 as a stream

If it does, that’s great, because I won’t have to download them, manage files etc, but just the metadata about them.

I can test that within the web interface (for me, http://radiodan-libby.local), and yes they do seem to play fine.

Next I want to see if I can play them programmatically.

The main guts of the functionality are in ./node_modules/radiodan-client/, the Radiodan client library installed as module. This converts commands to events in rabbitmq. The commands available are in ./static/js/playback-controls.js.

This makes things very straightforward indeed I think for a hardcoded RSS file:

a. when the app is started, get the hardcoded RSS file
b. add all the media files to the playlist
c. start playing the first one
d. is that it?

Obviously that won’t provide a away to remember where you were on restart, which will be very irritating, and nor will the buttons work (e.g. for next, previous), but it’s a start.

TODO: 3. Hardcode an RSS feed and display the result in the controller webpage


# First, stop monit monitoring radiodan-huffduffer:
sudo monit unmonitor radiodan-huffduffer

# then make some edits and test
/usr/local/bin/node /opt/radiodan/apps/client-huffduffer/main.js

The slightly confusing thing here is that node is really just running a tiny website – everything’s happening in client-side javascript, but we want to do this server-side, because chances are Huffduffer doesn’t do CORS for RSS and indeed I think it doesn’t):


curl -k -H "Origin: http://example.com" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: X-Requested-With" -X OPTIONS --head https://huffduffer.com/libbymiller/rss

Copying the similar file in the original code, I think the best thing is to create a little file that adds the rss feed data to the playlist like that.

….time passes…

I wasn’t able to make the player play from node.js – I couldn’t find an example that helped. I’ll try again at some point. You can see my attempts in git.

My second attempt used javascript, with a very simple proxy for my url, like this:


// proxy our one url
var request = require('request');
app.get('/rss', function(req,res) {
//modify the url in any way you want
var newurl = 'https://huffduffer.com/libbymiller/rss';
request(newurl).pipe(res);
});

Then it was just a matter of a small change to xjr.js:

function getRSS(url, success) {
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.onload = function() {
var rss = xhr.responseText;
//console.log(rss);
var arr = rss.split("\n");
var urls = [];
for(var i =0; i< arr.length; i++){
var text = arr[i];
var m = text.match(/<enclosure url=\"(.*?)\"/);
if(m){
urls.push(m[1]);
}
}
console.log(urls);
success(urls);
};
xhr.send();
}

and then a call in app.js:


getRSS("/rss",function(urls){
console.log("ok");
console.log(urls);
if(urls && urls.length>0){
for (var i=0; i< urls.length; i++){
addToPlaylist(urls[i]);
}
play();
}else{
console.log("nothing to add to playlist");
}
});

and bingo.

It currently only works when the html page on the device is loaded. Not sure how to manage it with a button. There’s also no title or length, but maybe those can be passed somehow to it. But it plays!

I didn’t get to try the RFID reader, but you could also set the URL in the page for example.

That’s enough for today though – about 7 hours from start to finish – not bad.

Product Space and Workshops

I ran a workshop this week for a different bit of the organisation. It’s a bit like holding a party. People expect to enjoy themselves (and this is an important part of the process). But workshops also have to have outcomes and goals and the rest of it. And there’s no booze to help things along.

I always come out of them feeling a bit deflated. Even if others found them enjoyable and useful, the general stress of organising and the responsibility of it all mean that I don’t, plus I have to co-opt colleagues into quite complicated and full-on roles as facilitators, so they can’t really enjoy the process either.

This time we were trying to think more creatively about future work. There are various things niggling me about it, and I want to think about how to improve things next time, while it’s still fresh in my mind.

One of the goals was – in the terms I’ve been thinking of – to explore the space in which products could exist, more thoroughly. Excellent articles by Richard Pope and Francis Irving have got me thinking in this direction, and I’d been touching lightly on some related ideas for Radiodan, thinking about a ‘Cambrian Explosion‘ of radios.

wrongradios

Richard and Francis’ posts have got me thinking about it more specifically as a multi-dimensional space of possibilities, and the notion that you can very easily get stuck exploring a little part of it.

Imagine a bit of that space. You start somewhere. Social networks. Sharing. Someone picks this idea up and runs with it and everyone flips to that aspect and starts exploring it. Sharing while watching the TV. Chatting. Twitter for companies. IRC for business. Each step is quite incremental, each idea came from somewhere, and ideas tend to oscillate in a little ecosystem. Each idea changes peoples’ views a little, but not very much, and the same ideas go round and round, reinforcing each other.

So there are parts of product space you just never get to, and are unlikely to get to. It’s almost like the “equilibrium” that we used to get taught about in economics, or maybe a little force-directed connected graph stuck in a single place.

A analogous structure holds in production bits of large organisations, I think. It’s very difficult to think beyond the next few months, because your head is full of today, so the potential changes you can think of are incremental, and again, similar ideas bounce round in the group of people you talk to, the meetings you go to.

Maybe there’s two things going on here. One is the inability to even imagine a different part of the space. The other is this bubble of ideas that become more convincing as you discuss and think about them over and over again with the same people. So not only are you not getting into different bits of the space, you’re becoming more and more convinced of the rightness of your initial ideas. I think this happens to me, us, everyone all the time.

Does it matter? I think as Richard and Francis were hinting at, it matters if you’re not exploring parts of the space that are important to people who you are trying to reach. I think it’s also probably important to your organisation, whatever it is. Bluntly, organisations need to make these big moves this to advance, change and compete. The question is, how.

Let’s take an example of how they might. A friend of mine has a disability. I want to include him in an event. The location of the event doesn’t have easy access. He won’t feel comfortable and he won’t want to come. He’ll miss something fun because no-one thought about the venue from his point of view.

Ok, so in that case maybe it’s just tough on him, and it often is. But the rather heartless secondary point is that if someone had had those thoughts it could get them thinking about a whole set of problems they hadn’t considered. This thinking could move them to a different part of the product space, if they let it, and then they could start incrementally exploring that new bit in the usual way. It could be a bishop’s chess move diagonally to a completely different bit of the board. It could also help my friend and others with similar requirements.

To get back to my workshop. I try something new whenever I do these events, even though it makes them more risky, because we learn more, and it can make them more enjoyable (though people can’t relax as much, of which more below).

This time I asked a few people from different bits of R&D to talk about their work, and then used those as starting off points for group-based brainstorming sessions. My research suggested that people needed a jolt to get out of their usual pattern of thoughts, and this was supposed to be the jolt. I also read that Alex Osborn, inventor of the process and term ‘brainstorming’, thought that unless you were outrageous, embarrassing, illogical, and unpredictable when brainstorming, you weren’t doing it right, so I put this in my instructions to facilitators. (One thing I have learned from previous workshops is that all the processes and accompanying instructions must be very clear for these kinds of events, and written down, too).

I went through all of the Gamestorming book looking for ideas for structures we could use in the breakout sessions. I couldn’t find anything suitable, so I made one up.

Here I the instructions I gave the facilitators:

Brainstorming

0. You have 20 minutes total for each session, of which the last 5 should be a brief discussion about your results

1. Gather everyone together, try and create a comfortable, friendly, fun, atmosphere

2. Near the top of one sheet of flipboard paper, write down the name of the first prototype on the list below from the previous talk, in a circle, for example

"Binaural sound"
"Infinite music"
"Fob"
...

A list of them all is included below. The ordering is important - the aim is that each group tackles a different one first.

3. Write down the challenge statement at the very top.

4. Ask the group members to come up with ideas that occur to them when applying the challenge statement to the prototypes we've just heard about. Write them on the paper, on stalks from the starting point. Tell them to be outrageous, startling and surprising. If their idea is related to another, draw a line between them

5. If you get stuck, pick up a strategies card and make an honest effort to apply what it says to the problem

6. If you are still stuck, move on to the next prototype and start again

7. Spend the last 5 minutes discussing the results - what are you most interested in, what has the most potential?

8. Come back for the next talk

The strategies cards I was talking about were a mixture of Giles Turnball’s “Strategies for creatives” (not all the cards) and Brian Eno’s Oblique Strategies cards.

Being of a experimental mindset, I tested the instructions with the other facilitators. In that context it seemed to work very well. We came up with a lot of strange ideas in a few minutes, and had fun bouncing the ideas off each other.

In the eventual workshop groups, the ideas people came up with were interesting and sometimes built on others’ ideas, but at least in the group I was facilitating, the rate of idea generation and novelty dropped off a cliff after the first session.

So this is one thing I need to think about. Is it something to do with the composition of the group? or is it about better-constructed sessions or more assertive facilitation? I certainly was getting tired after around an hour, and so was less enthusiastic, less likely to pursue the “outrageous, embarrassing, illogical, and unpredictable”. Group dynamics are difficult to manage, and you can’t just tell people to be outrageous, apparently.

Perhaps the ideas that were generated were much more novel when they had a starting point that people had not seen before and that was quite different to their existing work, as happened to be the case in the arbitrary ordering of the talks. If so, this has some implications for what we should and what we should present in these circumstances. Maybe it also has implications for what we should be doing more generally.

Probably the biggest problem was that the day was much too long and tiring. People quickly get tired. Thinking new thoughts is hard. Talking with and listening to people is hard. It was very noticeable how comfortable people were when they were able to get back to their laptops during a break.

My final instruction was this:

Consolidation

0. You have 20 minutes, and the brief is "if you wanted to do something with this in the next 5-10 years" what could we make?

1. Survey your work so far. Ask the group which ideas jump out at them, which do they think are interesting and exciting

2. Pick one or two and draw them / write them up as scenarios that you can present to the whole group.

People need a consolidation exercise, something to round off the day with. I do think it’s important. You put a lot of effort in – but where’s it going? what’s it for?

Scenarios are a very useful way of filling out an idea into something a bit more developed, while looking at it from the perspective of the end user. What would someone using this thing do with it? how would they use it? why?

For various reasons we ran out of time for this part, and so it was rushed. I was really impressed with what people came up with, but with insufficient time, the jump from a potential idea to a fully-formed scenario was probably too big. The rush and the desire for consolidation tended to prioritise the ideas that people had already thought through at least somewhat, so not the really novel things or the things that had their genesis with more than one person.

Conclusions

Going back to the product-space exploration, I think something that’s both slower and shorter may work better. In any given period of time maybe we only have to make the big jump once, and then we can explore the area around there, developing ideas into scenarios thoughtfully and carefully.

As I review this post, what leaps out at me is my assertion early on that talking to different people about their wants and needs can help us make this initial jump. This is something that has come out of our work on Radiodan postcards and similar work creating physical, three-dimensional representations of our ideas. When you ask people the right question, they can often give you a very interesting answer based on their own experiences, that you wouldn’t have thought of yourself (for a glimpse of this, see our wrong radio postcard collection). I didn’t apply this here and I’m not sure how to, but it’s worth thinking about.

Trying to cram in too much meant that we missed some obvious possible routes to interestingness. Prototypes (of which we have many) are more inspiring than presentations, and to include more demonstrations – of things we already have but that people hadn’t already seen- might have been a better way of getting people excited.

Personally I find these kinds of events quite … well disturbing’s too strong a word for it – but it often feels like there’s an assumption that squeezing ideas out of people is as easy as getting toothpaste out of a tube. It’s also manipulating people into being ‘creative’, and there’s something suspect about that. I’m not sure if there’s a way to getting similar or better results without these techniques, or whether I’m just over-thinking it.

Bitmap to SVG

Creating an SVG from a bitmap is pretty easy in Inkscape. Copy and paste your bitmap into a new Inkscape file, select it, do

path -> trace bitmap

import_png

trace

(I used the default options)

The new trace is exactly on top of the original – select and move it

double

path -> stroke to path

stroke2path

path -> simplify

Then go to node edit tool and delete the ones you don’t want by hand.

nodes

However for a plain black on white drawing, this gives you a double line, and in my case, it had no fill, so no way to recreate the line as it was in the original diagram. Or it defeated me anyway.

double1

So I used Gimp to export the png image as .ppm format,

ppm

and then you can do:

brew install potrace
potrace -s cat_black.ppm -o output.svg

Then open the output.svg in Inkscape and edit it as before – this time I got a filled double line.

outputsvg

And I was able to delete the inner line of the outline of the cat, but keep the fill for the whiskers and eyes (this was to export as a dxf for laser cutting).

final