10.28.07
Posted in mental microphony at 10:07 pm by daz
no, I’m not a terrorist, or else this blog would be called ‘The Blog of Daz - Terrorist’. Rather, the following images are of 2 microphones I made for a drummer and studio owning friend. He in turn has a friend, who thinks the mics look like pipe bombs, although how he would know what a pipe bomb is meant to look like, is something I’ve yet to discover.
Anyway, as with all my mics so far, these are electret condensers, but this time with 9v active circuitry. The bodies are made from 2 pieces of different guage reclaimed copper pipe, with the inner pipe housing the electronics and output socket. The screws through the outer tube are used to hold the inner tube in place, and by moving the position of the inner tube relative to the outer tube, a degree of directiality can be introduced. This can (and probably will) be enhanced by adding acoustic foam to the outer tube.
The intention (rather than blowing people to pieces) is that they’ll primarily be used as drum overheads [recordings coming soon].
Permalink
10.24.07
Posted in really? how exciting at 1:00 pm by daz
I’ve just been given an old powermac g4 : 450mhz, 384mb ram, 32mb agp, 20 gig sytem, 40 gig storage, dvd reader, zip drive (!). It apparently runs osx 10.3.9. The keyboard is pretty good, but brilliant - it hasn’t got one of those damned-awful McMouse examples of design winning over function. Haven’t yet decided what to do with it, although I’m thinking it might make a reasonable fx plugin host for the studio, or a server perhaps. It weighs a ton so its not going to be very mobile. Oh yeh, it came with a Lacie cd burner - about the size of a breezeblock - probably about as fast when it comes to burning cds too …
Permalink
10.14.07
Posted in mental microphony at 11:17 pm by daz
I’ve found a few pictures of a couple of things I made :
8 way line attenuator [passive gain control] allowing centralised control of 8 remote powered speakers’ volume levels in a multichannel playback room. ofc coax throughout, oak box by colin
’surf mics’ - electronics and capsule in lid, battery in foam lined herb/spice jar sealed with ptfe tape - good for catching the sound of water moving i.e. shoreline waves, playing in the bath, splashing in a fountain, flushing down the loo - you get the picture. plugs straight into line input on dat/minidisc/whatever.
Stone microphone case - without electronics - an attempt at changing the response of a generic electret capsule to be not so omni-directional - used to transfer material from loudspeaker to greetings card sampler hardware, idea being to get rid of a few ‘noises-off’ during what had to be an ambient transfer. oiled slate and trivetine.
Permalink
10.11.07
Posted in pythonic noodlings at 8:27 pm by daz
since having discovered swf is pretty slow at getting mouse coordinates, I’m using python to do it instead - a double headed project using a swf front end to a python midi server that also handles speech and other back-end stuff. I discovered PyHook as a way to pump operating system events into python, which tends to make things jitter a bit - mouse tracking slows down as the cursor jumps in steps from one place to the next. So, after a bit of head-scratching I remembered AutoItX automation com/dll which isn’t as powerful as PyHook, but certainly smoother. Now I get mouse events when I request them - instead of having to handle a big stream of o/s events I simply call AutoItX.MouseGetPosX() and .MouseGetPosY() when I want the information. Huraah. Dooble huraah I can use AutoItX to generate keypresses too - the mouse mode is now displayed by turning capslock/scrolllock leds on and off - nifty
I’ve also had a bit of a battle getting midi and speech to co-exist nicely - whenever the midi input is polled in a loop, speech (PyTTS) stutters and generally breaks up. Simple solution is to stop polling whilst talking which freezes midi input - not a problem as long as the buffer isn’t filled before polling can restart !
Permalink
10.10.07
Posted in random bits of .AS at 7:23 pm by daz
I’ve discovered something rather peculiar about _height _width _xmouse and _ymouse - their speed seems to depend on the size of the object calling the property - it is really slow for large movieclips and smooth for small ones. for example I’m using :
this.range=127
this.onenterframe=function(){
var x=int((this._xmouse/this._height)*this.range);
doSomethingWith(x);
}
to put the mouse coordinates for the x axis in (this) movieclip into a range of 0-127 to be compatible with MIDI data values, resulting in mouse control over volume/modulation/pitchbend/etc. The only trouble is that the performance is somewhat odd. When the movieclip size is 100×100, it performs well, but when the same movie (a simple filled box) is redrawn to 1024×768 it slows up so much it is unusable. When the movieclip is draw at 100×100 and then scale-up it performs badly too.
so I’m using python to determine the mouse position and swf to trigger python’s listening to the mouse instead.
most odd
Permalink