Circuitbenders Forum
Circuitbenders Forum => Drum machines => Circuitbending discussion => Alesis => Topic started by: Gordonjcp on March 18, 2008, 11:22:06 PM
-
I've figured out how to replace the samples and sample names in the Alesis HR16 and HR16B drum machines.
Have a look:
http://www.nekosynth.co.uk/wiki/AlesisHR16
There's an example mp3:
http://www.gjcp.net/~gordonjcp/hr16.mp3
It's not terribly easy to use or well-documented yet. I will be spending more time on it ;-)
-
Is this the same as one the Burnkit site:
http://burnkit2600.com/gear/hr-16-diy-sound-roms/
or is that actually you?
-
No, that was someone else. Have a read of the burnkit HR16 forum - as well as creating new sample data I've disassembled the firmware ROM and been able to replace the sample names and sample start points (the end points are marked in the data).
-
Great job ! :) i'm very interested ! i gues it would be possible to piggyback as many roms as fit under the hood,
wouldn't it ?
-
Correct. I'm about to do a dual ROM mod, but I need both clear bench space and some time ;-)
I'm in the IRC channel (#circuitbending on freenode) if you want to discuss it in a slightly more "real-time" way...
-
Hello.
I'm also hoping to edit the sample names and lengths on my hr16b.
Nekosynth seems to be down, but I've found a copy of Gordonjcp's utilities here: http://git.fuzzle.org/cgit/nekosynth/tree/utilities/hr16utils/ (http://git.fuzzle.org/cgit/nekosynth/tree/utilities/hr16utils/) and I've also found the the hr16b OS here: http://lonestar.madtracker.net/OSpack.rar (http://lonestar.madtracker.net/OSpack.rar)
I do run Linux, but have never compiled anything without a makefile before, so I'm a bit stuck on what to do next.
Thanks in advance for any help.
-
Use "scons" to build those. I'll try to get some stuff back up on them soon.
-
Cheers pal.
Okay, I've installed scons and dependencies...
...and successfully flipped the binary and had a look at it in hexedit. Yes, it's decoded! I need to spend some time getting to grips with how to use the utilities (eg, is it sample by sample or batch?). I reckon I'll have it figured out by the time my chips and programmer arrive from Hong Kong though. Any (re)upload of usage tips would be appreciated too.
Thanks again.
-
It's been about two years since I played with it ;-)
IIRC you assemble up a batch of samples and a text file to describe them, then let the sample mangler cook them into a ROM image. It will then put the start points and names into the firmware ROM.
It was all very much a work-in-progress. Currently my EPROM programmer is broken so I can't do a lot with it.
-
What, really?! That's way more than I was expecting.
So as well as converting the names to hex and calculating all the sample addresses for the firmware ROM, it compiles a single raw audio file with negative peaks between the samples? If so, you've automated my xmas break plans.
EDIT (afterthought): I'm assuming that the sample data occupies the same address range on all the firmwares for both the HR16 and HR16b? I only ask because I noticed a windows tool somewhere that was advertised as working only with one specific version.
-
You need the HR16B firmware because the HR16 firmware is wildly different. I believe there may be a suitable ROM image in there; if not I'll be able to turn one up for you.
In short (and this may be scribbled in the comments in the code somewhere) the sample names are some number of bytes long (can't remember, ten maybe?) and are plain ASCII. The samples themselves are not addressable by the CPU in any way. However, the sample playback ASIC is expecting a 16-bit value that represents the sample start pointer *shifted right by a nybble* - so basically you read the sample value from ROM, tack on a zero as the Least Significant Nybble, and that's you got your pointer. Simple.
Now the 0xff "ticks". You'll notice that the stock ROMs have samples that look like Christmas trees (strangely appropriate for the time of year). The valid sample data is -127 to 127, signed 8-bit. "But it says 16-bit on the lid, Gordon!" Yes, it does. It has 16 bits of dynamic range per sample but not 16 bits of resolution. So, when the sample is loud, it is described by 8 bits with a large jump in between, and when the sample is quiet it is described by 8 bits with a small jump in between. Great. Now we have -128, or 255, or 0xff left over, right? So use that as a marker.
Okay, here's the clever bit. Take your 8 bits of sample data and latch the D0-D7 from the ROM onto D8-D15 on your DAC - *through a kind of shift register thing*. Every time you see a single 0xff in the data, then it tells the shift register to "change gear" and shift the data, so after the first one D0-D7 from the ROM now maps to D7-D14 on the DAC - but the sample has been multiplied by 2 so it still fits the full range of values! Neat, eh?
Finally, more than one 0xff signals the end of the sample. You'll see all the samples finish with at least two 0xff if you open a ROM image with a sample editor.
-
I'm almost with you. Indeed, it seems a lot more elegant to divide the samples/dynamics with 0xff signals on the code side rather than attempting to fart around in Audacity.
I haven't tried it yet (I've been making music all weekend - heaven forbid!), but am I right in planning to gather together 47* 8-bit samples, totaling 8MB, listing them in samplelist.txt, then running the utility? ...and the utility will inject the list into my hr16b.bin firmware ROM image and cook up two 4MB sample ROM images (one for each sample chip)?
*I read that three of the 49 sounds (hi-hats) use the same sample.
Thanks, and more thanks.
-
Yes, I started working on a way to "christmas tree" the samples automatically but didn't get far - not even to the point of checking in any code, it seems.
I can't remember if it spits out two separate 4Mbit ROM images or just one big one you need to split.
-
would be great if you could address the sr16 in this way. it is a much better machine,
with (shitty) sounds. had all of them - and have great love for the grey hr16- but the
sr16 is great wedge: one of the only drum machines that will let you drop into
record without stopping.
one of the great alesis drum features is sticking patterns together, shifting timing on
indiv drums, stacking pads and stuff like that. you can easily work in a a stepthru mode,
or realtime.
-
I have just finished an application for generating custom EPROM's for the Alesis HR-16 and HR-16B drum machines. It will allow you to add your own samples and sample names.
A sample package can be downloaded at the link below, which includes the manual, screenshots, and a set of EPROM files created using the application, that will replace the samples in the HR-16/HR-16B with samples from the TR-707, TR-727, TR-808, and TR-909 drum machines.
Sample Package: http://www.mediafire.com/download.php?a99nfarisea908f (http://www.mediafire.com/download.php?a99nfarisea908f)
Just the Manual: http://www.mediafire.com/view/?x3h3ad1raqdnsbz (http://www.mediafire.com/view/?x3h3ad1raqdnsbz)
Entire Application: http://store.payloadz.com/details/1338640 (http://store.payloadz.com/details/1338640)
Feedback is appreciated. Thanks!
-
Give that man some karma! ;D
I'll be having a go at that as soon as i get a spare moment.
Many thanks for posting. I've just stuck up a link to this on our facebook page.
-
Looks interesting, is the source available anywhere? I don't have WIndows so I can't try it out.
-
Thanks for the plug on Facebook Paul. If you send me an e-mail address, I'll send you a download link for the app.
I'm not ready to give out the source just yet Gordon. I've got a bit of work into this, and I may still take a stab at custom sample lengths if I can find the time.
-
Ah, you don't do custom sample lengths? So you *haven't* ripped off my code? ;-)
-
Lol, no... I didn't rip off your code... :). I didn't know you had any out there. I did a lot of Googling when I first sat down to write the app, and I did find some source code written by other people. In all honesty, it wasn't that good... That's why I decided to write my own app. There's a couple other apps floating around already, but I wasn't crazy about the interfaces, and editing the files manually is too tedious.
Originally, I thought I'd knock this application out, down and dirty, in a weekend or two for personal use. As I got into it, I realized it wasn't going to be that easy, and it kind of just evolved into a full app. I may look into custom sample lengths somewhere down the line. I write software professionally, and am always busy, and this app became a bit of an obsession and definitely cut into my work day more than a few times. Unless anyone finds bugs, it'll probably be a little while before I start making any revisions to the code. I've got some other projects that need to get done first.
-
Well, I'm not handing over my GPLed code so you can stick it in a paid-for app - but here's how it's done:
The ROM as you have no doubt discovered has the lower eight bits of the address flipped end-for-end because of the way the PCB is routed (it makes sense from a manufacturing point of view). So sort that out and you'll see the text of the sample names.
Have you sussed out that all the sample starts are on exact 16-byte boundaries? The start address of a sample always has the lowest nybble as zero, and are always padded with zeroes to an exact multiple of 16 bytes. The upshot of this is that the 20-bit sample address fits neatly into a 16-bit value in ROM, so if you calculate the offset of some sample starts and find those values in ROM, you've got the table of start addresses.
I never did find out where the "default" values are stored, when you do a factory reset. They're probably stored as a list of bytes somewhere.
Now get to work ;-)
-
It's cool... I don't expect you to hand over your source code... ;). I don't know if and when I'll get to custom sample lengths. I've been using the app quite a bit, and so far it's suiting my purposes as-is. If I stick to drum samples, I don't run into any issues with the sample locations being too small. They're often actually much larger than my new samples.
Yeah, I did a lot of Googling, and read about the firmware being "flipped". Replacing the sample names actually was the easier part. I also found online where someone had posted the start location of the sample names within the data. From that point it was basically just a matter of find and replace. Editing the sample names was an after thought. Originally I had just planned on working with the sample data.
I took a different approach to determining the sample start and end locations. Before I decided to write the app, I had started to get setup to edit the BIN files manually. I bought an EPROM programmer, read in the data, and followed the burnkit method of editing the files in Sound Forge. I got both sample data files marked with regions, and muted the sample data. That took a long time, and going back through and putting in 47 samples didn't sound like fun at that point.
It dawned on me that with the audio muted, it would be very easy to open the files via C# and look at the byte stream, and determine the start and end points. Looking at the file that way, I had big blocks of 0's with little blocks of 128's in between. So I wrote some code to run through the files and pull out all of the start and end points, and then I converted 47 wavs to the proper format in Sound Forge, hard coded their paths into the code, and started making EPROM's. Doing it this way was about a 75% success start/end point wise on the first run.
I made A LOT of test EPROM's, and listened to every sample, took notes on what worked and what didn't, and went back and revised my code. Being able to listen to the results was actually a great way to debug. Based on what worked and what didn't, I knew exactly where to start looking for the problem. I found a few things that I didn't expect, like two samples that reference the data from one sample location. "Cabasa" plays all of the data, "Fast Cabasa" plays only part of it. Little things of that nature. I also found that normalizing the new sample data was very important. Otherwise some samples played very loud, some very quiet, and some ended pre-maturely.
It was a bit of work. Having some method of calculating would probably have been easier, but I don't regret it... ;). I'd be lying if I said I didn't enjoy it. I did manage to ruin one HR-16 in the process... and that was of course the night I decided to test with my circuit bent machine, rather than one of 3 clunkers I have on the shelf. It was like 3AM, I was tired, frustrated, and admittedly a bit intoxicated, and I fired up the machine with ICU15 inserted incorrectly. The last two pins were hanging out of the back of the socket, and all others were one position back. After that, regardless of the EPROM's I put in, no samples on ICU15 will play, except for one or two, which are very distorted. My next personal project will be bending another HR-16... ;)
-
The big blocks of zeros tell the oscillator to stop. A single zero tells it to "change gear" and shift down one set of bits. All the 128s are "zero" because it's unsigned 8-bit linear as you've no doubt seen. Dig around on the 'net and you'll find where I've described the "Christmas Tree" encoding of the samples.
Use 1Mbit flash chips instead of EPROMs, it's much quicker to burn and wipe.
Your fault sounds a bit odd; as far as I know all bar the chip select lines are paralleled up so if you zap one address line it's dead for both chips. Maybe the chip select line for U15 is damaged but still "kind of" working - can you get an oscilloscope on it and compare with the other sample IC?
Have you tried more than one chip in U15?
-
Thanks for tip on the flash chips. At this point, I think I'm just going to let the damaged HR-16 rest. I've tried several different EPROM's in it, and it's a no-go. As soon as you turn on the machine, you can hear a faint feedback, and the samples just won't play.
I started working on bending another one yesterday. Another few weekends and I'll be back in business.
-
Just finished up my new bent HR-16...
(http://imageshack.us/a/img267/7592/benthr16.jpg)
Was just messing around with it a bit, and I noticed that some of my custom samples are a bit hissy. It seems to be the samples on the lower end of things... bass drums, toms, etc... I thought maybe this was a side effect of something I'm doing in my app, but if I convert the same samples to 8bit with Sound Forge, they're still hissy.
I guess this just a side effect of downgrading the sample. You guys know of any way to clean up the audio? If I use the HR-16 tune to shift the pitch up a little bit, it reduces the hiss. Also, once you start bending the sounds, it's not really an issue. Ideally though, I'd like all the samples to sound good in their original format as well.
-
The hiss on conversion to eight-bit is because most of the time you use dithering. This adds a little bit of noise to the signal so that it doesn't switch "cleanly" from one 8-bit level to another. If you don't, then you get weird effects - on one 808 kick sample I converted you got the Booooooom of the 808 with strange "zeeeeoooww" noises as it decayed.
The answer is, of course, to use 16-bit samples by doing the "Christmas Tree" conversion that I posted about on my website ages ago.
-
The app can now be downloaded for free here:
http://www.mediafire.com/?tdddsm1qd67a4sd (http://www.mediafire.com/?tdddsm1qd67a4sd)
-
Hi! I'm trying to work out if I want to try burning some HR-16B ROMs myself, but the nekosynth.co.uk domain seems to be down - is the software available anywhere else, please?
Thanks!
-
Dragging up old posts I know. But ADEVILPUTASIDE I have the CEG editor for making custom roms. I don't think that is the software of either of the software coders talking on this thread many years ago. I am only just getting round to doing this part on my hr16, so not actuall written the eproms yet. it doesn't allow you to change custom sample lengths and it seems like you kind of have to manually match up sample lengths, otherwise new samples will be cut short. be amazing if the software from DUSTINDUSTRIAL resurfaced!
if you want the ceg stuff. write a reply or private message me.
cheers.