Posts by sumsar

Quote from ToH2002

I assume these are the "request string parameter" values (two-byte addresses) with the function code $43 - correct?

Yes. I've only looked into what is used in rig files. A rig file is just a single track standard midi file with modified header and track tags.

I haven't had a deep look at performance files (IIRC they are multi track SMF), perhaps there's messages there that could be useful.

Outside of that you would have to either brute force the extended messages or reverse engineer parts of the usb protocol used by rig manager (It uses a message encoding that is similar to the SysEx format. Someone else was trying to write a linux driver some time ago but I can't find the thread)

You might be able to tease out the extended addresses, by capturing a well chosen edit (something unique that can easily be searched for), with WireShark.

I've worked a fair bit with the SysEx format. My code is in a bit of flux as I've been exploring supporting Rust's no-std runtime, which is required for embedded devices. But it's sadly not ready for being published.

My findings on string parameter addresses is:

pub enum Tags {
    Unknown_0               = 0,
    RigName                 = 1,
    RigAuthor               = 2,
    RigDate                 = 3,
    RigComment              = 4,
    Unknown_5               = 5,
    Unknown_6               = 6,
    Unknown_14              = 14,
    AmpName                 = 16,
    AmpAuthor               = 17,
    AmpDate                 = 18,
    AmpTime                 = 19,
    AmpLocation             = 20,
    AmpManufacturer         = 21,
    AmpComment              = 22,
    AmpAuthor2              = 23,
    AmpModel                = 24,
    AmpChannel              = 25,
    AmpPickupType           = 26,
    AmpYearOfProduction     = 27,
    CabinetName             = 32,
    CabinetAuthor           = 33,
    CabinetDate             = 34,
    CabinetTime             = 35,
    CabinetLocation         = 36,
    CabinetManufacturer     = 37,
    MicModel                = 38,
    CabinetComment          = 39,
    MicPosition             = 40,
    SpeakerConfiguration    = 41,
    CabinetModel            = 42,
    Unknown_43              = 43,
    SpeakerManufacturer     = 44,
    SpeakerModel            = 45,
    // Unknown_49              = 49,
    Unknown_50              = 50,
    // Uknown_65               = 65,
}

The Unknown_* are parameters that I've encountered but haven't determined what they represent. IIRC most of them were just empty strings in my explorations.

Let me know if you find any errors or need something specific.

I've had a quick look at the USB communication with Wireshark. I see the Kemper responding with, what looks like, a different serialization of the SysEx format documented in the MIDI manual.

Here's the leftover data from a random URB_BULK input (I've seperated the bits that I think are serialization directives):

14 f00020
14 330000
14 02007c
14 4e0000
14 000000
14 000000
14 000000
14 000000
14 000000
14 000000
17 0002f7

Compare that with the layout of a SysEx message:

I'd have to figure out how to filter out all the chatter to get a better understanding. Plus I'm not super familiar with the USB protocol.

Quote from jojo3110

Hi,

I have the same problem. That Sysex Message doesn't work. I don't have the time to get into sysex messages, as millions guitarists in the world. Is there anything new about the topic? Like a CC for the Stack section? Why is that so difficult to implement?

Or can anyone just post the full Sysex and/or NRPN code to switch the stack on and off?

Cheers!

The SysEx messages you quoted are correct. Something else is failing you.

I would check that the MIDI Global Channel in System Settings includes the channel you're sending the SysEx to in your DAW.

Btw, if you enable UI to MIDI on the same settings page, the kemper will send out the MIDI messages that correspond to your tweaking of the knobs and buttons. Could be useful in the future, if you need to control more functions.

They do listen to user requests and offer them at no added charge.

I'm not sure what you're asking for either but your best bet is to try to phrase it a little clearer and post it as a feature request.

I see what you're getting at, even though to me, it sounded like you were phrasing it as a why can't the digital hardware solution be done in software.

The vast majority of amp modelling developers are doing approximate circuit simulation. Which is a rather well researched topic, in this industry.

Nonlinear system identification hasn't been explored much in the context of guitar amp modelling. There used to be a software which did some (limited) form of volterra modelling for analog audio efffects, but I've forgotten it's name. It never gained much traction.

Prior to the Kemper release I don't think there was any research directly applicable to guitar amplifiers.

Rather than framing it as a hardware or software problem. I do believe that it is more accurate to frame it as a wetware problem

In the Audio Setup page in the System Settings theres a parameter named Rig X-Fade Time which controls how long the fade in/out of a rig change takes. Maybe you need to lower it.

Quote from karlic

I hope that one day in the future we will find out exactly how the Kemper profiles. There are often plausible guesses, but I don't sense they are that close.

In the paper "Block-oriented modeling of distortion audio effects using iterative minimization" the authors reference the kemper patent summarizing it as:

Quote

In 2008 Kemper introduced a patent describing his model and

identification routine for identifying nonlinear guitar amplifiers.

He uses a block-oriented Wiener-Hammerstein model to emulate

the characteristics of an analog guitar amplifier by analyzing the

statistical distribution of pitches and volumes of the identification

signal. The filters and the nonlinearity are identified by an identification procedure of his own design, analyzing small and high

signal levels separately [11]

Display More

To the best of my knowledge that would mean that the core model is two linear blocks with a nonlinear block in between.

The nonlinear block is typically approximated as the sum of a series of polynomials (or curves in general). There's quite a lot of ways to represent the linear blocks, so I won't speculate on those.

If you're interested the method is part of a field of mathematics called nonlinear system identification. What Neural DSP is doing with the Quad Cortex capture is another instance of this line of research.

There are obviously a bunch of innovations on top of that model, which, I believe, is what sets the Kemper apart from the Quad Cortex.

For the parameters with a linear range you have to scale the the parameter range to the raw value range.

In your first example -5db would be 0 and +5db would be 16383.

Math.round((value - parameter_min) * 16383.0) / (parameter_max - parameter_min)

The Request String Parameter SYSEX function hasn't been updated since the reverb update (at the very least) and can't be used for every parameter.

Some of the reverb parameters, like the Decay Time, have non linear ramps in the range that can't be queried. I've opted to interpolate between fixed points for my own use but that is a bit tedious if you want to map every parameter.

I think a really clean (linear) amp like a Roland JC-120 would be a good candidate for side by side comparison of drive pedals.

Maybe I'm missing something but the kemper can already rearrange performances on the device.

Select the performance you want to move and press the Arrange button, above the display.

Nice find!

I've done a few quick tests and it does appear that extending the single parameter with two values sets up the morph range.

It sure would be nice to get an update on the profiler midi parameter documentation some time.

The only caveat I'm aware of in regards to morphing is that using the same slot selection cc's twice triggers the morph. Using a program change instead does not.

I've been ignoring morphing because the documented way wouldn't be feasible for my use. But if this way works smoothly, I could do a lot with it.

Thanks for sharing

Linear parameter values have to be scaled into a range of 0-16383.

The mix parameter has two 100% ranges, the first is dry and the second is wet.

Assuming you mean 90% dry, the scaling would be: 16383 * 90 / (100+100) = 7372

For non-linear parameter values you either have to interpolate between known values or create a lookup table.

The Request Parameter Value as Rendered String function can be used to build lookup tables for some parameters, but it doesnt return the right value for others.

In the MIDI protocol the top bit (the 8th bit) is reserved as a special marker. So the kemper uses an encoding for 14-bit NPRNs to ensure that the top bit of each byte is cleared.

Quote

F0 00 20 33 02 7F 01 00 3C 00 00 91 F7

Because 0x91 is bigger than 0x7F (the maximum 7-bit value). The overflowing bit has to be shifted into the preceding 7-bit byte.

So for 0x91 the byte values would have to be:

0x91 >> 7)= 0x01 bitwise shifting the value right by 7 bits leaves the upper 7 bits.

0x91 & 0x7F = 0x11 bitwise anding by the maximum 7-bit value leaves the lower 7 bits

Which gives:

F0 00 20 33 02 7F 01 00 3C 00 01 11 F7

With UI to MIDI enabled you can monitor which messages are generated for most of the editing you can do on the kemper.

I've done it for the new delays and reverbs a while ago, for a similarish use case.

DualChromatic       = 0x89,
DualHarmonicDelay   = 0x8A,
DualCrystal         = 0x8B,
DualLoopPitch       = 0x8C,
LegacyDelay         = 0x91,
SingleDelay         = 0x92,
DualDelay           = 0x93,
TwoTapDelay         = 0x94,
SerialTwoTapDelay   = 0x95,
CrystalDelay        = 0x96,
LoopPitchDelay      = 0x97,
FreqShifterDelay    = 0x98,
RhythmDelay         = 0xA1,
MelodyChromatic     = 0xA2,
MelodyHarmonic      = 0xA3,
QuadDelay           = 0xA4,
QuadChromatic       = 0xA5,
QuadHarmonic        = 0xA6,

LegacyReverb        = 0xB1,
NaturalReverb       = 0xB2,
EasyReverb          = 0xB3,
EchoReverb          = 0xB4,
CirrusReverb        = 0xB5,
SpringReverb        = 0xC1,

In my implementation I have not been able to dynamically setup reverbs without leaving an audible gap.

My approach was to first set the stomp type, toggle it on and finally set the needed effect parameters.

I think morphing would be better if the limitations fit your use case.

Rig Manager stores the rigs and tags in separate sqlite databases for each folder you create. Mirroring the folder structure of your local library.

I'm not sure why they've chosen this design but I can understand why they might have an aversion to implementing sub folder search on top of it.

I believe the parameter you're looking for is called SPDIF Clock on page 5 in the Output section of the Kemper.