If it ain't Baroque, ya probably can't fix it.
satanbane
read my profile
sign my guestbook

Visit satanbane's Xanga Site!

Name: Benjamin
Location:
Birthday: 4/15/1966
Gender: Male


Message: message me
Website: visit my website


Member Since: 7/14/2006

SubscriptionsSites I Read

Posting Calendar

|<< oldest | newest >>|
view all weblog archives

Get Involved!

Suggest a link

Recommend to friend

Create a site


Sunday, April 07, 2013

building the music of the future

So as you may have seen over in Facebook land,
I have a new drill press. Very exciting. I had
contemplated all sorts of less-plausible ways to
accomplish accurate hole-drilling, but finally I
just bit the bullet. 119$ at Home Depot, relatively
small-caliber bullet. All of my designs depend on
accurate holes; I have basically shifted all the
requirements for accuracy onto the drilling process,
as opposed to the sawing process (affects looks
but not alignment) or the planing process (none:
design depends on dimensions of lumber as-purchased).

First project will be the new pedalboard for my
digital pipe organ. This will be somewhat less
precision-intensive than the stringed instruments
to come later; but still, I depend on the accurate
vertical holes for my keylever guides, which are
a.k.a. finishing nails sticking through a board.
I hope to use this style of guide in the keyboard
instruments as well; the pedalboard will be the first
test of practicality.


Saturday, March 30, 2013

drive-by shop-talk

Here is the program I've been working on lately.

This is the C code, gzipped:
solder2midi.c

This is the executable:
solder2midi

Looks pretty small when you put it like that, amazing how many different
and even *useful* things a machine can do, given different patterns of
those bits...




So yes, I've been working on the VPO (virtual pipe organ) quite a bit,
alongside the (wooden) instrument design stuff.

I've encountered an extremely cool little embedded system board called
the Raspberry Pi. Check it out if you have interest in such
things. Runs Linux, has Ethernet and USB, has HDMI video output,
has flash-card slot, and has audio output. And other stuff of course; but to
me, it looks like a two-channel pipe organ voice board. Oh yeah, the key feature
is, they cost about 50$ each; a four-channel VPO (two stereo pairs of
speakers) would just be two of these in a box.

Those who find this interesting might also be interested in the
Beagle Board. Those are like 150$ each, and they have more
processing 'nads; in particular, you get access to a TI C64 DSP.
The R-Pi has some kind of DSP, but it's dedicated to the HDMI video
and not user-programmable, AFAICT (but VPO doesn't need DSP, just
reliable audio playback). Both of these, Beagle and R-Pi, use ARM
as the core which runs Linux, and then add other stuff on the same chip.
They also both use these tiny BGA chips, with pads on top for another
BGA to piggy-back (the SRAM). Crazy stuff, man! Totally not
user-maintainable in any way.


Monday, January 21, 2013

Bifurcated Moonlight

The Moonlight Sonata for harpsichord and electric guitar.

Hmmm, maybe because I use such old settings
for my editor and such on Xanga, I seem to be
unable to manage the "audio manager" properly.
I'm not sure whether I have successfully uploaded
anything, nor whether that will be accessible to
the public if indeed I have. I can't seem to link
to it from here, anyway. But you *might* want to
try wandering around in my "audio blog" or whatever,
and see if you can get any sound from any of my
several upload attempts, of bifurcated moonlight.
(Let me know how it goes.)

This is not me playing, it is my old friend the computer,
i.e., MIDI-ized music. The point was to test the basic
concept of breaking the familiar piano piece, Moonlight Sonata,
into two parts. I use faux-harpsichord on the electronic keyboard,
with damper pedal activated (impossible in most real harpsichords,
but a great sound which proves its worth in a piece like this),
for the right hand of the piano part, and faux-cello for the
left. I picked cello because, well, it actually sounds good in
itself, but what I'm really picturing is electric guitar playing that
part, but with the right distorted sound and volume pedal to
shape the attacks, into something very similar to a cello sound.
And with octave-divider, most of the piano notes can be hit
as-written.

This is only the slow first movement. I have ideas for the
other two, but different instruments and/or tonalities for
each movement, not played the same as the first.

Thus, another experiment, in this overall musical direction of mine,
involving a mixing of baroque and electronic sounds, re-interpreting
old music and writing new music for the old instruments, used
in new ways, etc..

Beethoven sounds pretty good on harpsichord, with all the
dynamics factored out and only the architecture of the notes
still in place. Kind of like how a black-and-white photo can capture
some kinds of artistic essence better than colour.


Wednesday, December 12, 2012

clavicytherium design progress...

harp_ferrous_49


action


Saturday, October 27, 2012

DPO

So, the latest...
I've now expanded my parallel-port interface to
two keyboard inputs (128 keyswitches), and I'm
working on the MIDI input; with all that complete,
I'll be able to connect two manual keyboards and
one pedalboard: which, I believe, is all I will want.

I have become more or less convinced that more
than two keyboards is not necessary. It sure would
help if I knew how to play the organ! But that little
detail, I save until the end. Instead, I study organists
doing their thing, on youtube. Maybe there are
some pieces that really require all those stacks of
keyboards, but for the most part, I seldom see more
than two keyboards getting extensive back-and-forth
use. My theory is that the multiplicity of keyboards
has arisen due to the inflexibility of the traditional
organ mechanism: a given rank of pipes can only
be played from its associated keyboard, except when
keyboards are physically coupled together. With
electric actions, this limitation can be bypassed, but
the tradition seems to have been firmly established
already; typically only some of the ranks will be
"floating" even with electric-action organs, the rest
still being tied to their home keyboards. I guess
organists must like the convention of different keyboards
having different, fixed functionality (the "great" keyboard,
the "swell" keyboard, etc.); and I suppose the usual
disincentives to this kind of complexity-bloom, i.e.,
cost and space, do not obtain in the organ universe.
But they sure do obtain in *my* universe!

Two hands means two keyboards, fewer would be
a drastic limitation. But given the ability to flexibly
assign any rank of pipes to any keyboard, and to
switch between presets while playing, more than
two keyboards appears to be a needless extravagance.
To me. But what do I know? (Not much, but more
every day...)

So now that I have multiple keyboard inputs, I need
to expand my software to make use of them; initially,
with the old software, all keyboards play the same
single stop (i.e., same MIDI channel). I was planning
to use not-written-by-me software to accomplish the
control of stops: "GENPO". But GENPO adds blatantly
noticeable latency. Do actual musicians ever actually
try to play actual music in actual real-time with these
open-source programs? Actually, it would appear not.
So, now I'm adding all the stops and presets logic to
my own C program, solder2midi. My code begins to
resemble the hardware: a hydra-like conglomeration
of bits and pieces, added as the need is encountered.

And there's still another piece to the puzzle which I
have yet to tackle: creating my own soundfont files.
The soundfont (.sf2) format is proprietary, it seems,
and the holders of the rights (E-mu) make available a
graphical, Windows-only (not even Mac???) program
for editing the files. Probably needless to say, I'll
never be able to live with that limitation. I either need
tools to convert between .sf2 and some textual format
like XML that can be edited in flexible ways by tools
of my choice, or I need to ditch the .sf2 format and
start exploring other ways to store audio samples and
looping points. (Latter approach would also entail
ditching fluidsynth, which I kind of hate to do, as it
handles so many details that I don't wish to re-invent,
such as knitting together the attack segments, loop
segments, and decay segments, such that glitches
and out-of-band transients are minimized.)

Somebody, some day, had better be pretty damn thankful
that I'm doing all this! I'm fairly sure nobody else would
ever get it done.



Next 5 >>