Encoder.rtf

(11 KB) Pobierz

Encoder parameters

These are the settings that are for all the rotary controls of this preset

$encoder <arg> is the start

<arg>  possible values 1-32 for the BCF and 1-56 for the BCR

  1-8 = top row, Group 1

9-16 = top row, Group 2

17-24 = top row, Group 3

25-32 = top row, Group 4

33-40 = third row (BCR)

41-48 = second row (BCR)

49-56 = bottom row (BCR)

Parameters just for the encoder

  .resolution <arg1> <arg2> <arg3> <arg4>

The number of steps in a revolution. The 4 arguments are used for different speeds of rotation. <arg1 for the slowest and <arg4> for the quickest

    <arg>  possible values 24, 48, 96, 192 (may be more???)

 

  .mode <arg>

The dot display. Only the top row support all modes. The others can have  off, 1dot, 1dot/off

Note that the .mode in the $button is completely different.

    <arg>  possible values off, 1dot, 1dot/off, 12dot, 12dot/off, bar, bar/off, spread, pan, qual, cut, damp (see General section for list)

 

Common parameters to encoders, buttons and faders.

  .minmax <arg1> <arg2>

The range of the encoder. <arg1> is normally the smaller value, but if you make it bigger than <arg2> then the encoder works in reverse – not usable with .easypar

For buttons <arg1> is the off value and <arg2> the on value

<arg1> and <arg2>  possible values 0 to 16383

 

  .showvalue <arg>

Displays the value of the encoder in the LED display

<arg>   possible value on or off

 

  .default <arg>

<arg>   possible value anything in the value range ie between the max and min value

 

  .easypar <args>

This is a simplest way of setting up the control but a bit limited. If you can’t set up the controller by this method there is usually a way with the .tx method.

(see buttons section)

 

  .tx <arg>

This can have any midi message, even a number of them together. It could be controller, sysex, notes Anything less than or equal to 123 bytes. So you can even send bank change and patch change  or controller messages on more that one channel. You can use numbers in either Hex or decimal eg $7F in hex or without the $ the decimal value 127

 

   <arg>   any midi message, val, val0, val1.7, val0.6, val7.13, val0.3, val4.7, val8.11, val12.13, chk-1,chk-2, chk-3, reloffs <arg., relsign <arg>, rel2s, ifp <args>, ifn <args>

 

any midi message eg $B2 10 val is Controller  10  on channel 2 with the value from the button, encoder or fader

 

val is the low 7bits (ie between 0 and 127) from the controller.

Midi data can never be sent with the high bit of the byte set. Eg if you wanted to send the data value $F7 Midi would think that this was end of the sysex message.

To send data that has a greater value than 0 to 127 you break the bytes up. You break up the value into 2 or more bytes each less that $80, send them and reassemble the data at the other end.

THE BCR and BCF can have a 14 bit number and this is broken up into the 2 seven bit numbers.

For example if you wanted to send an 8 bit number you could send the lowest bit and then the top 7 bits val0 (bit 0 ) and val1.7 for the top 7 bits

 

Another way is to use 14 bit numbers (0 to 16384) and send bits 0 to 6 as one byte then bits 7 to 13 as another byte

val0.6is the same as val . The 0.6 part is bit 0 to bit 6 ie lowest 7 bits

val7.13is like val0.6 bit it is bit 7 to bit 13 of a 14 bit number

 

Sometimes the number is broken into 4bit nibbles. So a 2 byte number (0 to 64k) would be broken up into 4bit nibbles and each nibble sent as a byte. Eg the number &F7 can’t be sent as MIDI data so 2 bytes $0F then $07 is sent and reassembled at the other end.

So a two byte number $48F2  would be sent as $04 $08 $0F $02. You need twice as many midi data bytes as there is data but it is easy to reassemble at the other end.

 

Val0.3 is the lowest nibble

Val4.7 is the highest nibble in an 8bit value

Val8.11 is the lowest nibble of the second byte

Val12.13 is the lowest nibble (only 2 bits so it is still just a 14 bit number)

 

Checksums

To make sure that the data hasn’t been damaged during transport down the MIDI wire we use one of a number of simple tests and compare it to another byte we send called the check sum.

cks-1 <arg> is calculated, according to the Germans by subtracting the numbers and where the <arg> is which byte the checksum calculation starts.

eg  cks-1 5 starts from the 5th byte from the start of the sysex message.

$F0 $00 $21 $00 $10 $01 $02 $03 $04 $05 $06 val cks-1 $05 $F7

Start at byte 5

$10 – 1 – 2 – 3 – 4 – 5 – 6 – value = x

When x is added to cks-1 and the result is 0 then the message is good.

You can get the same result by different methods. This works for Roland gear and they describe the calculation as …

Add all the bytes and divide by 128. Keep the remainder (this is the same as adding up all the numbers and only using the lowest 7 bits)

128 – remainder of the previous division = checksum

 

When you add the checksum to the sum of the preceding bytes you get 128 or $80 or 0 in the lower 7 bits whit he 8th bit set.

 

cks-2 is the same as cks-1 but adding the numbers

cks-3 is lie the other 2 but you exclusive OR each of the bytes (the bit is set if either bits are 1 but not if  both are 1 or both are 0)

 

The easiest way to sort it out is to experiment with the different checksums to see what works with your equipment.

 

 

http://sequencer.de/synth/index.php/B-Control-Tokenreferenz

Zgłoś jeśli naruszono regulamin