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...