Impulse responses... convolutions? eh?

[fret]

Since I was a wee lad I always wanted a box that behaved like a speaker + mic that I could put between the amp and a DI. I read about the Palmer PDI-03 and how it was "amazing" etc, but didn't feel the $600 odd price tag was justified. Now I have an axefx, and it's kinda IS that box... (and more).

Anyway it got me thinking about the whole Cab/IR/Mic technology and where it could go in the future. Clearly it's working well in the axefx, but what about traditional gear? What if there was a little DSP board that you could load an IR into that had a speaker load built into the input stage, captured the signal from a real tube amp, converted it to digital, ran the IR convolution over it, then outputted it to an XLR jack as analog and a RCA jack as digital. Keep the price reasonable and you'd have a winner! Lots of people doing low volume gigs and studio users would be interested.

By trade I do software, so given enough details about the algorithm I think I can DO that part. The hardware is more tricky... as far as a "load" for the speaker goes, lots of high wattage resistors seems to be the official way. And you can tap off the signal using large value resistors in a voltage division arrangement to get a raw line level signal to go into into the A/D stage. If I can find a suitable DSP I would have a crack at building one. (Can you tell I'm high on success after the whole MIDI foot controller project?). I think apart from choosing the DSP board, the hardware is not going to throw up insurmountable barriers.

Does anyone know exactly what sort of convolution algorithm is actually taking the input audio and the speaker IR and processing it? I'd like to prototype the system on a computer first... just to check it's feasible, and then look at putting it into hardware.

 

[Rex]

That's a clever and interesting idea. Let me play devil's advocate for a minute to make sure we've got the bases covered.

What if there was a little DSP board that you could load an IR into that had a speaker load built into the input stage, captured the signal from a real tube amp...

That's a limiting factor. The devices used as "speaker loads" are pure resistive loads. They don't exhibit the reactance that real speakers have. As a result, the amp's output is not the same as it would be with a real speaker connected to it. That will affect tone and feel.

...as far as a "load" for the speaker goes, lots of high wattage resistors seems to be the official way...

It is. But as noted above, it's not the same as a real speaker cab. The only way to put a speaker-like reactive load on an analog amp is to hook up a real speaker to it. Most people who have used resistive-load devices on a tube amp feel it's inferior to an actual cab. It could be a tough job to sell a digital FRFR solution to hardcore tube folks.

Does anyone know exactly what sort of convolution algorithm is actually taking the input audio and the speaker IR and processing it?

I don't know whether anyone's actually published their convolution algorithm, but it can be derived from the mathematical definitions of Fourier transforms and convolution. Here are a couple of links to get you started (the first one is the best I've seen to give you a gut-level understanding of convolution before you delve into the math):

Digital Convolution Tutorial

Convolution

 

[fret]

The devices used as "speaker loads" are pure resistive loads. They don't exhibit the reactance that real speakers have. As a result, the amp's output is not the same as it would be with a real speaker connected to it. That will affect tone and feel.

I'm aware of that. There are some designs floating around that have a variable inductance for different frequencies that are apparently more speaker like. Something to look into down the track.

Maybe something can be done about modeling that in the software at a later stage. I have this idea of having a known signal passed through the static load, and then through a live speaker and running some sort of mapping to convert the signal. Maybe a 2nd IR can do that?

I don't know whether anyone's actually published their convolution algorithm, but it can be derived from the mathematical definitions of Fourier transforms and convolution.

Thanks, I think I understand those. I was thinking of running a test: send a known signal into the axefx, with the custom sysex on, and then with it off... then take those 2 signals and write my own convolve using the custom sysex. See if I can get them to sound the same. To that end I've just bought all the 4x12 ownhammer IR's to play with. However I need to know the format of the sysex impulse response file so I can extract the base convolve data. I'd prefer not to have to reverse engineer it. Anyone got any pointers?

 

[AlbertA]

Ahem:

Torpedo VB-101 | Two Notes Audio Engineering

 

[fret]

Ahem:
Torpedo VB-101 | Two Notes Audio Engineering

Thats like 2200 euro. More than the Axefx! But nice to know that someone has had that idea already.

So AlbertA, about that sysex format, you of all people should know. Care to share? (I was tracking you down via forum posts anyway)

 

[Rex]

I was thinking of running a test: send a known signal into the axefx, with the custom sysex on, and then with it off... then take those 2 signals and write my own convolve using the custom sysex. See if I can get them to sound the same. To that end I've just bought all the 4x12 ownhammer IR's to play with. However I need to know the format of the sysex impulse response file so I can extract the base convolve data. I'd prefer not to have to reverse engineer it. Anyone got any pointers?

Can you help me understand what a "custom sysex" is? That will help me understand your question.

 

[fret]

Can you help me understand what a "custom sysex" is? That will help me understand your question.

Um, as opposed to a stock IR from fractal... a user IR slot.

 

[Rex]

Um, as opposed to a stock IR from fractal... a user IR slot.

Now I get it. You're referring to third-party IRs. Note that the term SysEx describes SYStem EXclusive MIDI messages that are specific to a particular product. The Axe-FX uses SysEx messages for a lot more than IRs.

Here's a link to the AXe-FX's SysEx specification, or at least as much of it as has been made public (I think). Ownhammer and others convert their IRs to SysEx to allow them to be used in the Axe-FX, so they, at least, know more than what's in this document.

Axe-Fx SysEx Documentation - Fractal Audio Systems Wiki

 

[Rex]

Here's a utility that converts IRs from the more common WAV format into Axe-FX SysEx. It may help you figure out the format.

Axe-Fx IR Converter

 

[fret]

Ownhammer and others convert their IRs to SysEx to allow them to be used in the Axe-FX, so they, at least, know more than what's in this document.
Axe-Fx SysEx Documentation - Fractal Audio Systems Wiki

Yup, I know all about that document, because I created an Axefx foot controller, which sends/receives most of those sysex's. I have even updated it with missing information. I think AlbertA wrote that converter so I'm hoping he'll come clean with some info about the format. Rather than my spend hours using it to reverse engineer the format. It's probably dead simple, like from offset A to offset B is just all the bytes from the wave file split into high and low nibbles. But there maybe a conversion step involved.

 

[LMO]

Ownhammer just uses AlbertA's utility to create the sysex files , so no special knowledge there. Possibly RedWirez does as well.

 

[AlbertA]

Yep it's dead simple,

Sysex start, Sysex manufacturer Id, IR message cmd, 1024 32 bit signed integers, nibbled for Sysex, XOR checksum byte, Sysex end.

Th IRs are normalized to unit energy.

 

[Xrocker]

My Mother told me to never normalize my unit's energy!

 

[fret]

Sysex start, Sysex manufacturer Id, IR message cmd, 1024 32 bit signed integers, nibbled for Sysex, XOR checksum byte, Sysex end.

That sounds about right... however in looking at the ownhammer sysex IR's I find there is 5 bytes between the last 8 byte sample and the sysex end byte. e.g. in OwnHammer_412_Mesa_V30-2_e906_4.syx after the last sample is

01 00 00 03 0a f7

I don't see how XOR checksum byte can equal 5 bytes. Maybe there is some padding at the start? I notice that after the IR command byte (0x0a) there is always at least 3 zeros. Is that just padding? Or part of the first sample? Because 5 bytes - 3 padding at the start = 2 bytes... de-nibbled = 1 byte... = xor checksum?

I'm working on the premise that this is somewhat correct:

struct Sample
{
uint8 Bytes[8];
};

struct Main
{
uint8 SysexStart = 0xf0;
uint8 ManId[3];
uint8 ProdId;
uint8 Cmd = 0xa;
Sample Samples[1024];
uint8 ChecksumNibbles[2];
uint8 SysexEnd;
};

 

[DonPetersen]

so you're basically talking about a IR based Red Box?
SM Pro Audio has a device that can run vst plugins (SIR being one of the best convolution reverbs), so that would be the design to beat. ~439 EUR

 

[fret]

1024 32 bit signed integers

Looks like they are big endian byte order too. So least significant byte first.

 

[AlbertA]

Looks almost correct, but the command I think is nibbled, so 0x0A 0x00
and after command was IR location nibbled (which is ignored now, used to be used in past firmwares) so another 2 bytes.

That sounds about right... however in looking at the ownhammer sysex IR's I find there is 5 bytes between the last 8 byte sample and the sysex end byte. e.g. in OwnHammer_412_Mesa_V30-2_e906_4.syx after the last sample is


I don't see how XOR checksum byte can equal 5 bytes. Maybe there is some padding at the start? I notice that after the IR command byte (0x0a) there is always at least 3 zeros. Is that just padding? Or part of the first sample? Because 5 bytes - 3 padding at the start = 2 bytes... de-nibbled = 1 byte... = xor checksum?

I'm working on the premise that this is somewhat correct: