Other things on this site...
Learn about
The Molecules of HIV
The Molecules of HIV
We had an interesting conversation here yesterday about designing new musical instruments. We're interested in new instruments and interfaces, and there's quite a vogue for "user-centred design", "experience design" and the like. But Andrew McPherson pointed out this paper by Johan Redstrom with an interesting critique of this move, essentially describing it as "over-specifying" the user. If we focus too much on design for a particular modelled user experience, we run the risk of creating tools that are tailored for one use but aren't repurposable or don't lend themselves to whole "new" forms of musical expression.
The twentieth century alone is littered wth examples of how it's only by repurposing existing technologies that new music technology practices come about. Here's a quick list:
The only successful twentieth-century musical instrument I can think of, that was successful through being used as the designer intended, is the Theremin! (Any others? Don't bother with recent things like the ReacTable or the Tenori-On, they're not widespread and might well be forgotten in a few years.)
So, given this rich history of unexpected repurposing (kinda reminiscent of the fact that you can't predict the impact of science) - if we are designing some new music interface/instrument, what can we do? Do we go back to designing intuitively and for ourselves, since all this user-centred stuff is likely to miss the point? Do we just try building and selling things, and seeing what takes off?
==
One important factor is hackability. There's quite a telling contrast (mentioned in the Redstrom paper) between the "consumer" record player and the "consumer" CD player - in the latter, the mechanisms are quite deliberately hidden away and all you have is a few buttons. The nature and size of vinyl makes that a bit difficult, so most record players have the mechanism exposed, and it's this exposed mechanism that got repurposed by scratch DJs.
(There are people doing weird things with CD players, and hacked CD players are relevant to the glitch aesthetic in digital music. But maybe if the mechanism was more exposed, more people would have come up with more and crazier things to do with them? Who can say.)
But it's not neccessarily a good thing to expose all the mechanism. In digital technology this could end up leading to too-many-sliders and just poor usability.
(Another relevant paper on this topic: Thor Magnusson's "Affordances and constraints" paper, considering how users approach music technologies and their constraints.)
In a paper I wrote with Alex McLean (extended version coming soon, as a book chapter), we argue that the rich composability of grammatical interfaces (such as programming languages) is one way to enable this kind of unbounded hackability without killing usability. Programming languages might not seem like the best example of an approachable musical environment that musicians can fiddle around with, but the basic principle is there, and recent work is making engaging interfaces out of things that we might secretly call programming (e.g. Scratch or the ReacTable).
==
Another factor which is perhaps more subtle is ownership - people need to take ownership of a technology before they invest creative effort in taking it to new places. There was some interesting discussion around this but I personally haven't quite pinned this idea down, though it's obvious that it's important.
For inventors of instruments/interfaces this is quite a tricky factor. Often new interfaces are associated with their inventor, and the inventor generally likes this... Also it's rare that the instrument gets turned into a form (e.g. a simple commercial product) that people can easily take home, live with, take to gigs, etc etc, all without reference to the original inventor or the process of refining original designs etc.
I don't even think I've really pinpointed the ownership issue in this little description... but I think there is something to it.
Fish and chorizo is a lovely combination and this stew with pasta shells was simple but rich. Serves 2-3, takes about 40 minutes.
Chop the spring onions up. Keep the whiter bits separate from the green leafy bits. Also chop the chorizo into little bite-sized pieces.
In a deep pan that has a well-fitting lid, warm up some marge/oil and start the white bits of the spring onion frying gently. Once the chorizo is chopped up add that too.
Once the chorizo and spring onion have softened a bit nicely, add the fish pie mix to the pot and stir it around. Add the green bits from the spring onions, and the lemon zest, then enough boiling water to only just cover. Bring to the boil, put the lid on, turn the heat right down and let it simmer very gently for 25-35 minutes.
Halfway through the stew's bubbling time, get the pasta going. Half-cook it (parboil it) for 5 minutes in boiling water, then drain it and add it into the stew.
Just near the end, wash and chop up the parsley, add it into the pot, and stir everything around. Give it another minute or two for the parsley to get involved, then serve.
I'm following the "7 languages in 7 weeks" book. This week, PROLOG! However, I'm failing on this task: solve the eight queens puzzle in prolog. Why does this fail:
queens(List) :-
List = [Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8],
valid(List).
valid([]).
valid([Head|Tail]) :-
validone(Head,Tail),
valid(Tail).
validone(One,[Head|[]]) :-
pairok(One, Head).
validone(One,[Head|Tail]) :-
pairok(One, Head),
validone(One, Tail).
pairok((X1, Y1), (X2, Y2)) :-
Range = [1,2,3,4,5,6,7,8],
member(X1, Range),
member(Y1, Range),
member(X2, Range),
member(Y2, Range),
(X1 =\= X2),
(Y1 =\= Y2),
(X1+Y1 =\= X2+Y2),
(X1-Y1 =\= X2-Y2).
I load it in gprolog using
['8queens'].
then I ask it to find me the eight unknowns (A through to H) by executing this:
queens([(1,A),(2,B),(3,C),(4,D),(5,E),(6,F),(7,G),(8,H)]).
What it should do (I think) is suggest a set of values that the unknowns can take. What it does instead is say:
no
(which means it thinks there are no possible solutions.) Anyone spot my error?
One of the nicest things about the SuperCollider language is the Patterns library, which is a very elegant way of doing generative music and other stuff where you need to generate event-patterns.
Dan Jones made a kind of copy of the Patterns library but for Python, called "isobar", and I've been meaning to try it out. So here are some initial notes from me trying it for the first time - there may be more blog articles to come, this is just first impressions.
OK so here's one difference straight away: in SuperCollider a Pattern is not a thing that generates values, it's a thing that generates Streams, which then generate values. In isobar, it's not like that: you create a pattern such as a PSeq (e.g. one to yield a sequence of values 6, 8, 7, 9, ...) and immediately you can call .next on it to return the values. Fine, cutting out the middle-man, but I'm not sure what we're meant to do if we want to generate multiple similar streams of data all coming from the same "cookie cutter".
For example in SuperCollider:
p = Pseq([4, 5, 6, 7]);
q = p.asStream;
r = p.asStream;
r.next; // outputs 4
r.next; // outputs 5
q.next; // outputs 4
q.next; // outputs 5
and in isobar it looks like we'd have to do:
q = PSeq([4, 5, 6, 7])
r = PSeq([4, 5, 6, 7])
r.next() # outputs 4
r.next() # outputs 5
q.next() # outputs 4
q.next() # outputs 5
Note how I have to instantiate two "parent" patterns. (I could have cached the list in a variable, of course.) It looks pointless with such a simple example, who cares which of the two we do. But I wonder if this will inhibit the pattern-composition fun in isobar, that you can do in SuperCollider by putting patterns in patterns in patterns... who can say. Will dabble.
The other thing that was missing is Pbind, the bit of magic that constructs SuperCollider's "Event"s (similar to Python "dict"s).
As a quick test of whether I understood Dan's code I added a PDict class. It seems to work:
from isobar import *
p = PDict({'parp': PSeq([4,5,6,7]), 'prep': PSeq(['a','b'])})
p.next() # outputs {'prep': 'a', 'parp': 4}
p.next() # outputs {'prep': 'b', 'parp': 5}
p.next() # outputs {'prep': 'a', 'parp': 6}
p.next() # outputs {'prep': 'b', 'parp': 7}
p.next() # outputs {'prep': 'a', 'parp': 4}
This should make things go further - as in SuperCollider, you should be able to use this to construct sequences with various parameters (pitch, filter cutoff, duration) all changing together, according to whatever patterns you give them.
There's loads of stuff not done; for example in SuperCollider there's Pkey() which lets you cross the beams - you can use the current value of 'prep' to decide the value of 'parp' by looking up its current value in the dict, whereas here I'm not sure if that's even going to be possible.
Anyway my fork of Dan's code, specifically the branch with PDict added, is at:
The Four Alls Inn, the pub in Higham where I grew up, has just re-opened with a bit more of a focus on food than before. So I thought it worth giving the food a bit of a write-up.
The photo above doesn't show it since the refurbishment but it does show the original sign that illustrates what the "Four Alls" actually means (see closeup here). The original sign is preserved of course for historic interest.
Inside, they've got some tasteful new upholstery and carpet, but of course it's still a fairly small place with about 7 tables in the main area (apparently it's sometimes been difficult to get a table booking - everyone's been trying it since the relaunch). They've still got decent local ale on tap (Moorhouse's Pride of Pendle, recommended) and an open fire.
Of course I had to try the black pudding starter. A single slice of black pudding but perfectly done and served with a poached egg and some delicious mustard mash. The mustard mash was excellent, and the poached egg was cooked just right (though it had cooled a bit by the time it got to me).
(My dad thought one slice of black pud wasn't enough, but in combination with the mustard mash and the egg I think it's the right balance. If there's one thing that a food place can do to disappoint me, it's cock up the black pudding starter! So I'm glad to report they've done a good job with it...)
For main course, I was definitely tempted by the butternut and ricotta ravioli but one of my sisters ordered that, so instead I had the steak and ale pie, and snaffled a taste of the ravioli. The pie was great, really tender meat; and the ravioli was also lovely - the pasta perhaps a little thick, and perhaps swimming in a bit much sauce, but the filling was very nicely flavoured, and overall my sis said it was lovely. My other sister had the cheese and onion pie and grandma had the chicken, both of which were apparently good.
For afters, the sticky toffee pudding was fine, as it should be; and the cheesecake was "alright" apparently (not very strongly flavoured - not always a bad thing IMHO, but then I didn't actually sample the cheesecake).
Everyone in this area knows that the Fence Gate just down the road has claimed a massive slice of the gastropub territory round here. (And justifiably so, it has some really good food.) So it's nice to report that the Four Alls has good food worth the mention. There's no reason that all pubs should be gastropubs, of course, but the Four Alls was having trouble staying open as it was, so it'd be good to see it develop in this slightly different direction. Since there's a whole new set of commuter-village houses being built next door to it, it seems like a canny move. Oh and just so you know, they've still got the pool table in the little room.
