combine two nibbles to a byte?

[ilmenator]

I am trying to remote control a synth that can send its current synthesis parameters as SysEx blocks of data. This is handy because in theory it allows initialization of the NG event settings to the actual values in the synth. The synthesis parameters themselves can be controlled via NRPNs.

 

However, the SysEx data sent by the synth is organized in nibbles. E.g., a parameter value of 63 is sent as 03 15 (0x03 0x0F), and 64 is sent as 04 00 (0x04 0x00). Is there a way to convert that into regular 7bit or 14bit values that can then be output by the NG? Something like

EVENT_ENC id=1109  hw_id=9  ports=0000100000000000  type=NRPN  nrpn=16  syxdump_pos=2:35

fails because it can only take into account the upper or the lower nibble of the value I'm after, as syxdump_pos points to a single byte in the ^dump only.

[EsotericLabs]

Hello Ilmenator,

 

I did something comparable (I guess)  in C for converting between u16s and u32s in mem and u8s or u7s for sysexes. Maybe the code snippet below is of some use to you. I'm not familiar with the NG, so maybe not...

 

//////////////////////////////////////////////////////////////////////////////////////////
// conversion functions between MIOS32 types u32 u16 and Midi MSB LSB // Address Hi Mid Lo
//////////////////////////////////////////////////////////////////////////////////////////
u8  MSB(u16 data){return ((data & 0x7f00) >> 8);}
u8  LSB(u16 data){return (data & 0x007f);}
u16 To16Bit(u8 MSB, u8 LSB){return (( (MSB&0x7f)<<8)|(LSB&0x7f));}
u8  AddressHi(u32 address){return ((address & 0x7f0000)>>16);}
u8  AddressMid(u32 address){return ((address &0x7f00)>>8);}
u8  AddressLo(u32 address){return (address&0x7f);}
u32 AddressFull(u8 Hi, u8 Mid, u8 Lo){return (((Hi&0x7f)<<16)|((Mid&0x7f)<<8)|(Lo&0x7f));}

[TK.]

When you search in the .NGC documentation for the keyword "nibble", you will find the appr. variables which allow to extract values on various ways: http://www.ucapps.de/midibox_ng_manual_ngc.html

 

The ^dump feature won't work here, instead you've to extract the values with individual EVENT_RECEIVERs (unfortunately).

This also means, that the max. value position which can be parsed on this way is limited, because the maximum stream length is 128 bytes, and each variable consumes 2 bytes.

 

However, here a usage example for the case that these limitations are acceptable:

EVENT_RECEIVER id=1 fwd_id=ENC:1 type=SysEx stream="0xf0 0x01 0x02 0x03 ^val_n2 ^val_n1"
EVENT_RECEIVER id=2 fwd_id=ENC:2 type=SysEx stream="0xf0 0x01 0x02 0x03 ^ignore ^ignore ^val_n2 ^val_n1"
EVENT_RECEIVER id=3 fwd_id=ENC:3 type=SysEx stream="0xf0 0x01 0x02 0x03 ^ignore ^ignore ^ignore ^ignore ^val_n2 ^val_n1"

 

Tested with:

f0 01 02 03 04 05 06 07 01 02 f7

 

The values 0x45, 0x67 and 0x12 will be correctly forwarded to ENC:1..ENC:3

 

BUT: you need a MBNG update, because previous versions didn't forward the value if the "stream" didn't end with 0xf7 (now the value is forwarded with 0xf7, or if the last byte in the stream matched)

 

-> http://www.ucapps.de/mios32/midibox_ng_v1_025_pre2.zip

 

Best Regards, Thorsten.

 

P.S.: @Martijn - the implementation is:

case MBNG_EVENT_SYSEX_VAR_VAL:        match = 1; pool_item->value = (pool_item->value & 0xff80) | (midi_in & 0x7f); break;
case MBNG_EVENT_SYSEX_VAR_VAL_H:      match = 1; pool_item->value = (pool_item->value & 0xf07f) | (((u16)midi_in & 0x7f) << 7); break;
case MBNG_EVENT_SYSEX_VAR_VAL_N1:     match = 1; pool_item->value = (pool_item->value & 0xfff0) | (((u16)midi_in <<  0) & 0x000f); break;
case MBNG_EVENT_SYSEX_VAR_VAL_N2:     match = 1; pool_item->value = (pool_item->value & 0xff0f) | (((u16)midi_in <<  4) & 0x00f0); break;
case MBNG_EVENT_SYSEX_VAR_VAL_N3:     match = 1; pool_item->value = (pool_item->value & 0xf0ff) | (((u16)midi_in <<  8) & 0x0f00); break;
case MBNG_EVENT_SYSEX_VAR_VAL_N4:     match = 1; pool_item->value = (pool_item->value & 0x0fff) | (((u16)midi_in << 12) & 0xf000); break;

[ilmenator]

Oh, I see. I was thinking of creating an editor for Mutable Instruments' Ambika synth, but the patch dump is larger than that, leaving about half of the parameters unaccessible. However, Ambika also provides direct access to its parameter RAM (kind of like the old basic PEEK). I'll see if I can make use of that instead.

[TK.]

We would have the same problem with a MBSID V2 editor... ;)

 

Best Regards, Thorsten.