Some questions about shruthi::Patch to NRPN mapping

I’m working on a bit of software which converts a patch received via sysex, back to nrpn’s. I have things working now but I’m not sure about the last bit of data after the modulation matrix.

The manual listing the nrpn mappings ends with:

Sequencer mode 0-6 100
Tempo 35-248 101
Groove template 0-5 102
Groove amount 0-127 103
Arpeggiator direction 0-3 104
Arpeggiator range 1-4 105
Arpeggiator pattern 0-15 106
Time warp 0-18 107

And the last bit of the Patch structure is:

uint8_t portamento_data;

// Offset: 76-84
ParameterAssignment assigned_parameters[4];

// Offset: 84-92
uint8_t filter_cutoff_2;
uint8_t filter_resonance_2;
uint8_t filter_topology_;
uint8_t op_data_\\[4];
uint8_t exclamation_mark_;;

// 8 bytes of decompressed patch data.
uint8_t filter_1_mode_;
uint8_t filter_2_mode_;
Operation ops_\\[2];

My questions are:

  1. Where do I find these last few NRPN parameters in the patch data? Or are they part of the sequencer settings instead?
  2. What about things like the Polivoks overdrive and fm settings? Are they in there (op_data_?) and are they currently mapped to any NPRN index?
  3. What exactly is the portamento save hack? Is it just the stored value of midi cc #5?

These last few parameters are defined in the SequencerSettings struct.

Have a look at the declaration of the enum PatchParameter. You will see in which setting each filter board parameter is stored. For example:


=> The “FM feedback” parameter of the polivoks filter board is stored in the “Filter resonance 2”, so it is accessible with NRPN 85.

The portamento save hack is a specific version of the Shruthi-1 firmware that uses 7 characters for patch name (instead of 8) and uses the reclaimed byte to store portamento information with the patch. Just ignore it, there might be only one or two guys running it.

Brilliant, thanks for the quick reply Olivier!

Those NRPNs are not listed in the manual btw.

Assuming that all parameters in the PatchParameter enum are mapped to NRPN, I’m left with 4 that I don’t understand yet:

PRM_OP_OP1 = 94,
PRM_OP_OP2 = 95,
PRM_OP_ROW = 97,

Since its 4 parameters my first guess is:
uint8_t op_data_\\[4];

But how is this data related to the two modulation operators? There are 2 of them with each 3 parameters. Are those parameters somehow combined into these 4 bytes?

There is some code at line 90 which looks like it computes the ops_ from the 4 op_data_ bytes, but I can’t quite work out what’s going on.

op_data_ is compressed data and is never directly modified. What is modified is the ops_ structure, at offset 94, 95, 96, 97, 98, 99.

94, 95, 96: operand1, operand2 and operator of the first op.
97, 98, 99: operand1, operand2 and operator of the second op.

All 108 parameters… check! :smiley:

While getting into NRPN I noticed that every source I found on the subject claims that the only optional CC is the data LSB. So every NRPN message consists of either 3 or 4 CC messages. The Shruthi only sends out LSB, both for the NRPN parameter index and for its data value. So officially these message should be 4 CC’s instead of 2.

For example:

I understand that it makes sense to leave out all MSB if possible to save bandwidth. Is it safe to assume that in my Shruthi editor I never have to use any of the MSB cc’s?

data LSB is used for values in the 0 … 127 range (most of them). Data MSB is used when a value exceeds 127.

Ah yes just found it in the manual too.

“Since most parameters have their range in a subset of 0—127, only a data entry LSB message has to be sent. When the maximum value of the parameter exceeds 127, or when it accepts negative values, a data entry MSB will have to be sent. Negative values are represented using 2’s complement. For example, the MIDI messages to send to set the Oscillator 1 range to -12:”

I noticed that if you set the midi out to “full” all midi cc/nrpn input is echoed to the output twice. Is this expected behavior? Both my 0.95 and 0.96 units have this.

The unit sends a message whenever a parameter changes, whether this change is initiated by an external message or internal move. I’ll see if we can trace the origin of the parameter change to avoid sending the NRPNs when the change is MIDI initiated (and for which there will be a corresponding message in the in>out soft thru).

Ok cool it’s not a problem just thought it might be bug.

I’m creating the enum for my oscillator shapes and according to the manual the parameter range is 0-33, but I can’t figure out what 34 shapes it maps to. From the manual I figured these 24:

none, saw, square, triang, zsaw, zreso, ztri, zpulse, zsync, pad, fm, waves, tampur, digitl, metall, bowed, slap, organ, male, user, 8bits, crush, pwm, noise, vowel

I had a look at the code but couldn’t find it in there yet. What’s is the full list?

O shit I can read if from the display! Heheh my brain seems to be a bit fried from Squarepusher last night :smiley:

… so the remaining mystery shapes are:
belish, polatd, cello, clpswp, female, fmtvoc, frmnt2, res3hp, electp, vibes

Is there any reference to what they contain? Some I can guess but others are pretty cryptic :slight_smile:

They are all wavetables, built by finding the optimal rearrangement of the “official” wavetables (waves … male) that make the result sound similar to some of the early Waldorf wavetables.

Thanks for explaining.

I’m arriving at the very last part of my editor/setup integration, and ran into one more thing. My editor is talking to the Shruthi via NRPNs but my hardware sequencer (also driving the Shruthi simultaneously) is using plain CC for its parameter automation.

I noticed that when I set the Midi out to “ctrl” the incoming CC is not passed to the output, but NRPN is. This is strange no? Only when I set it to “full” the CC is passed, but then also extra NRPN is generated from the incoming CC. So in full mode when you send in CC, you receive back the same parameter in 2 formats (CC + NRPN).

For me it would be ideal if, in “ctrl” mode, the incoming CC is echoed as NRPN. Or if it is preferable at least echoed as CC… or maybe both? What do you think?

What is very cool about this setup I think, is that my editor can configure the Shruthi while the hardware sequencer is playing, and if the sequencer automates parameters in the Shruthi, the editor displays its parameter changes in realtime. :sunglasses:

It works now in “full” mode, but it’s a bit overkill and also sysex is echoed which is not really feasible, especially since my hardware sequencer is soft-thru-ing back and forth between usb and physical midi ports everything.

The CTRL mode is designed to allow the MIDI in/out of the Shruthi to be connected to the same device (data sent on the output looped back to the input). As such, any incoming CC data is not forwarded to prevent a feedback loop.

But that’s exactly what I’m doing right now. It doesn’t have to result in a feedback loop. The NRPN messages pass from computer > usb midi > hw sequencer > din midi > shruthi > din midi > hw sequencer > usb midi > computer, without creating a feedback loop. The sequencer has both usb midi and regular midi ports. The Shruthi is connected directly to an in and out port on the sequencer. In full midi mode this works, but like I said its wasting quite a bit of bandwidth this way.

If that is the reason for not passing CC wouldn’t that apply to NRPN also?

Will have to look into this. Thanks for the report.

Ok thanks looking into it!