Juno 106 Sysex string construction

[puffer3]

Ok I wanted to ask if I am on the right track for creating a sysex string that collects the values of several juno 106 buttons into one sysex message. The midi implementation states:

so parameters 16 and 17 are a combination of several button values into one 7 bit value. My (incomplete) code approach that I am imagining:

establish a variable for each value of the group of parameters

use an if then to walk through all the modulators and assign correct values to the variables

create a table that collects the modulators in the right order

then convert the binary string to a single hex value and insert it in the sysex string and send

then all the buttons in that group will execute the same method when pressed

`
function chorusWaveRangeSelector()

-- 1 for chrous 1, 0 for chorus 2
chorusNum = 0

-- 1 for Chorus on, 0 for chorus off
chorusOn = 0

-- 1 for on, 0 for off
sawOn = 1

-- 1 for on, 0 for off
pulseOn = 1

-- 100 = 4'
-- 010 = 8'
-- 001 = 16'

range = 100

--here is were I need to make an if then to walk thru the modulators and create the right combination of values for the string table
panel:getModulatorByName("chorusOne")
panel:getModulatorByName("chorusTw0")
panel:getModulatorByName("sixteenFeet")
panel:getModulatorByName("eightFeet")
panel:getModulatorByName("fourFeet")
panel:getModulatorByName("squareShape")
panel:getModulatorByName("sawShape")

--this will be used to create the 7 bit sysex string for the juno
chorusWaveRangeTable = {
chorusNum,
chorusOn,
sawOn,
pulseOn,
range,
}

--then the table has to be converted to a proper sysex string an sent for parameter 16
--F0 41 32 yy 16 xx f7

end
`

Is this the right approach? I am struggling with syntax as always.

I made some of these UI designs using the 3d in illustrator. It was easy and fun!
JUNO106_1_2_featurSet_2022-05-20_10-00.bpanelz.zip

[dnaldoog]

Hi @puffer3 ,

NOTE: 2022/06/04 The following explanation is correct generally for coding bit packing, but the Roland Juno 106 doesn't quite work this way. For example 16',8',4' are toggled on/off . Chorus1=64,Chorus2=0 share byte 6 and byte 5 is xor'ed ― (meaning on=0 and off =1 i.e. the bit is flipped) †

• † You don't have to do this. Just make a button that has a label saying on when in the off position and vice versa!

---

For Byte 16

local byte16=0
local t={
panel:getModulatorByName("chorusOne"):getValue()*64,
-- panel:getModulatorByName("chorusTw0"):getValue()*0, -- always 0
bit.bxor(panel:getModulatorByName("chorusOff"):getValue(),1)*32,
panel:getModulatorByName("sixteenFeet"):getValue()*1,
panel:getModulatorByName("eightFeet"):getValue()*2,
panel:getModulatorByName("fourFeet"):getValue()*4,
panel:getModulatorByName("squareShape"):getValue()*8,
panel:getModulatorByName("sawShape"):getValue()*16,
}

for _,v in ipairs (t) do
byte16=byte16+v
end
local channelOut=panel:getProperty("panelMidiOutputChannelDevice")-1
local syx=string.format("F0 41 32 %.2X 10 %.2X f7",channelOut,byte16)
 panel:sendMidiMessageNow(CtrlrMidiMessage(syx))

---

For byte17:

If every control is set to 1, you will get a total of 63. 0011 1111

local byte17=0
local t={
["HP filter"]=bit.lshift(panel:getModulatorByName("HP filter"):getValue(),3) -- bitwise left shift 3 bits
VCA=panel:getModulatorByName("VCA"):getValue()*4,
ENV=panel:getModulatorByName("ENV"):getValue()*2,
MOD=panel:getModulatorByName("MOD"):getValue()*1,
}

for _,v in pairs (t) do
byte17=byte17+v
end
local channelOut=panel:getProperty("panelMidiOutputChannelDevice")-1
local syx=string.format("F0 41 32 %.2X 11 %.2X f7",channelOut,byte17)
 panel:sendMidiMessageNow(CtrlrMidiMessage(syx))

😊

P.S when you write F0 41 32 yy 16 xx f7, don't you mean F0 41 32 yy 10 xx f7? Not sure.

[puffer3]

Wow i was way off lol. @dnaldoog I am pretty blown away at the simultaneous complexity and simplicity you managed to achieve here. I guess that's what good computer science is.

I think I still don't understand how the sysex is constructed then. I managed to get your code working (after I found my chorusTw0 type hehe) but I still think I need to learn more about binary to hex conversion or bitwise shifting. Is there like an article or a book that is good for that? I will do some googling

as for 10 instead of 16, I thought looking at the midi implementation that the bit packed parameters were 16 and 17. What am I missing here?

Is using radio groups ok for these buttons with this method? The sysex message seems to be the same unless I click the buttons on and off. Is it important to change the button values from True/False to 1/0?

Thanks for your patience. This is so helpful tho thanks John!

[dnaldoog]

LHi @puffer3

Maybe read this.

With regard to bit packing and hex.

Hex is a convenient way to represent binary numbers. Each bit to the left (of an eight bit unsigned byte) represents a doubling of the value, so 1111 1111 is 128 + 64 +32 + 16 + 8 + 4 + 2 +1 - that will give you 255, but in HEX a number goes from 0-F (F=15) (F=1111) so you break the number 255 into two groups of 4 binary representations 1111 0000 = 240 (15*16+0) and 0000 1111 = 15, 240 + 15 = 255,

as for 10 instead of 16, I thought looking at the midi implementation that the bit packed parameters were 16 and 17. What am I missing here?

That is why I said 16 in hex should be 10. 16 in binary is 0001 0000 = 10 (but it's not 10 decimal - it's 10 hex). 17 is 0001 0001 and looks like 11. It's still 16 or 17 but looks different in sysex, because sysex uses a binary string format "10" . The actual integer would be 0x10 . If you send 16 in a sysex string you are sending 22 decimal 0x16 = 0001 0110 x x x 16 _ x 4 2 x

It's more convenient to use HEX as it gets pretty confusing using decimal for big numbers. In hex 255 would be two groups of 15 which is FF (15*16 + 15)†. That is why you always see F0 at the beginning of a sysex message. It means 240 and is code for "I am a sysex message and will end when I say F7 (247) that's called EOX".

When it comes to data in MIDI the leftmost bit (MSB most significant bit) x000 0000 is never used and is set to 0, so one MIDI data byte has a limit of 127. 0111 1111 = 0x7F When you include the 0 as a value that's a total of 128 values 0-127.

† Here is something I wrote in another post:

ref One way to visualise or convert a hex number to decimal (maybe you know all this already) is to split the binary text representation of a hex number into two. Well I didn't know this for the longest time.

So visualise 0x40 "40" as 4 0. Multiply the (4 by 16) =64 and the the (0 by 1) =0 and you'll get the decimal 64. So 0x3F "3F" is 3 F (3 by 16) = 48 and (0F by 1) = 15 48 + 15 = 63 etc.

Midi data values have a limit of 127 as represented by one byte, so that is 0x7f (7 * 16=112) and (F*1=15) = 127. If you are adding a string '80' to a MIDI message something is wrong. The x000 0000 MSB byte tells MIDI what kind of data it is, for example a program change message starts with C0. so C in decimal = 13. 13 x 16=192 - that's over 127 so in MIDI that is a status byte (in this case telling the machine to implement a program change on channel 1).

---

• Extra more advanced stuff

Now the trick is that you can send data values over 127. In that case you split the value over two bytes. You might send the value 254 0xFE 1111 1110 for example as 0F 0E. This is called a nibble, or you can send is as a 14bit value 01 7E that is 128*1 + 126 = 254. You might come across this in future, but for now you can ignore this paragraph.

You can also go the other way shrinking and packing separate values into one byte as long as the total does not exceed 127. When you get a value say 1/0 from a switch and it belongs in say byte 6 of a set of packed bits including other modulators as in byte 16 in the Juno, you would have to shift it left 6 positions. It's the same as multiplying it by 64 as each shift left doubles the number. When reading back from the machine you may have to shift right to get the value back from 64 to 1.

Programmatically you could either do value*64 and add it to the other values as I did, or use lua's bit library bit.lshift(value,6).

---

So in summary, it's important to see that whether binary 0001 0000 or hex 0x10 or a binary string "10" or decimal 16 they are all identical values. 😊

[puffer3]

Thanks for hexucating me. I think I will be better after absorbing all this info

[puffer3]

What the Hex
ok what I learned here. I am still understanding the bit packing but I read about hex many different ways. thanks john!

HEX is base 16

its values are 0 1 2 3 4 5 6 7 8 9 A B C D E F

A=10, B=11, C=12, D=13, E=14, F=15

A MIDI hex value for sysex is usually two hex digits, lets say variable XY, the value of the two digits is calculated by X*16 + Y

So for F0 our usual first byte of a sysex message we have F=15 so to calculate we have (15*16)+0 = 240

The highest value possible is FF which converts to base 10 as (15*16)+15 = 255

For the value 16 (that I messed up) we calculate (1x16)+0 which equals 10. Now I understand somewhat. The actual Binary is taking me a second longer.

Also if you hit Command+3 on Mac the Calculator will switch to programmer view and it has a HEX base 16 setting

From the Sparkfun Article

If the first bit is high (values between 0x80 and 0xff), it denotes a status byte. Status bytes are the commands of the MIDI stream.

• Status bytes are further subdivided by nybble. The first nybble specifies the command type, and the second nybble specifies which the channel the command applies to.
• There are only eight bit combinations with the MSB set (0x8 to 0xf), therefore there are eight possible status commands.
• The 4 bits in the channel nybble are all usable, giving MIDI 16 possible channels.
  If the first bit is low (values between 0x00 and 0x7f), it is a data byte, indicating parameters that correspond to a previous status byte. Because the MSB must be zero (otherwise they'd become status bytes), the data is limited to 7-bits, or the range from 0 to 127 (0x0 to 0x7f).

It reminds me of a dumb joke:

“There are 10 kinds of people, those who can count binary and those who can’t”

[puffer3]

@dnaldoog Okay so the issue on the midi monitor with the buttons I think has to do with the fact that some of them (chorus and foot stop octave buttons) are in Radio Groups and so when one switches on and turns another off, the value for the bit is being calculated before the Radio Group action takes place. Is this a reasonable hypothesis?

I look at the MIDI monitor and click from 4' to 16' and the midi message sent is the same, but when i click 16' off and on itself, what I think to be the correct message is sent.

What is the way to remedy this? No Radio Groups? Timers? I am not sure...

[dnaldoog]

What the Hex ok what I learned here. I am still understanding the bit packing but I read about hex many different ways. thanks john!
...

That's excellent. By writing it down and explaining it like that (better than I did) you will gain that Ah~ha or Eureka moment. Apart from wanting to help people, it is one of the reasons I often write on the forum, because explaining things (and I am often only slightly ahead of the questioner) is the best way to really cement understanding. You can see from your paragraph the beauty of Sysex design.

Binary is an even closer visualisation to what a computer/processor is doing. For example I'm pretty sure that a computer's registry does multiplication by left shifting. Take a number like 7. That's 0000 0111 in binary - left shift by one and you get 0000 1110 and you get 14. that is 0x0E (remember 1111 is 0f ) and one less is (1110) - even numbers always have the first (rightmost bit at 0).

Hex makes calculating from binary easy. 1100 0011 1111 1011 I know to be C3FB but in decimal I have no idea! (actually it's 50,171) but by just looking at the binary I can quickly arrive at a hex representation. Remember 1=8 1=4 1=2 1=1 1111 = 8+4+2+1 = 15.

[dnaldoog]

@dnaldoog Okay so the issue on the midi monitor with the buttons I think has to do with the fact that some of them (chorus and foot stop octave buttons) are in Radio Groups and so when one switches on and turns another off, the value for the bit is being calculated before the Radio Group action takes place. Is this a reasonable hypothesis?

I look at the MIDI monitor and click from 4' to 16' and the midi message sent is the same, but when i click 16' off and on itself, what I think to be the correct message is sent.

What is the way to remedy this? No Radio Groups? Timers? I am not sure...

For radio buttons, you probably need lua. https://ctrlr.org/forums/search/radio+buttons/
https://ctrlr.org/forums/topic/radio-button-in-a-modulator-group-needs-a-default-setting/page/2/#post-119393

You can't download the example panel from that site, but here it is again.

Radio Button Example.zip

[puffer3]

@dnaldoog So the built in Radio Button parameter is not good?

[dnaldoog]

@dnaldoog So the built in Radio Button parameter is not good?

I think it might be the case? I've never used it, or once found it didn't work so gave up on it.

[dnaldoog]

Hi @puffer3

I wrote an editor today!

#471

[subv0x]

Hi @puffer3

I wrote an editor today!
howzit going? :-)
cool ! someone was asking about JU106 sysex the other day, and i looked at Atom's version but it's incomplete for parameters 16 and 17.

i dealt with this issue years ago, on the atari, parameters sharing the same parameter number, and you have to try to change higher bits without affecting lower ones and vice versa. it's clever how they've packed so many parameters onto one parameter number.
chorus looks like it should have off/1/2, and that that would be ? (decimal) 64, 96?, 128? - i have some memory of bytes being ignored if they are 0 (in binary addition?) - any, i figured it out way back then, without that clever stuff you showed higher up, which i shall have to study and try to understand(!) - just looking out for the decimal numbers where the bits didn't interfere.

[subv0x]

something happened and midiox stopped receiving messages, after i clicked 'snapshot', and can't get it working again. ??

[dnaldoog]

Hi @subv0x,

Can you confirm that all that bit packing code is working, because I don't have a JU106 and the OP never got back to me about that?

Hope you are well. 😀

[puffer3]

Yes I can confirm I have still been unable to get the chorus buttons to work correctly ! I am still trying to solve this issue

[dnaldoog]

Oh I see! Well, I will have a look at the coding again and see if I can fix it. 🤔😀

[subv0x]

that code in the button array looks ok (familiar!) but i can't see the panel because it is an exe. i had minimal buttons using Ctrlr graphic objects, and a 'led' above them that changes colour values when selected.

for the hex/bin/dec conversion, i have a nice table chart here, worth hanging onto. i tend to use it to look up quickly where bits are, or look up the hex for a decimal value.

oh can't seem to attach files :-/
here's another one (not as pretty):
https://cmtext.indiana.edu/MIDI/img/DecBiHex_Chart.pdf

[dnaldoog]

Hi HF -- you can attach any files to this forum, as long as you zip them (image files don't need to be zipped though)

So - do you have a Juno 106 in front of you and can you confirm the panel works?

@puffer3 (Henry) says the chorus buttons don't work.

You have downloaded the .bpanelz file, to be able to see the lua source code, right?

[subv0x]

i might need to post a bit more to get my attachment-posting rights back, been away for most of the year (ran out of computer juice during the summer heat, and got a couple of things to tinker with, was programming my novation remoteSL etc.)

yes, the bpanelz of course. i only saw the exe before. so you're using an external image resource with LED on/off. i just use a Ctrlr 'dot' and make it change colour - ** LOVE THAT COLOUR TABLE BTW !! :tu: ** much better than trying to remember hex.. although i got quite quick at bashing in FF00FF00 and the few other colours i've been using.

so the button itself is not a 2-state toggle: it's a momentary, and pops up again, sending its 'trigger' to shift to the next value - there are only 2 values, 0 and 1, off or on, so that becomes a toggling on off action. you can have the LED change state, latching, following the value, or just blink when pressed, and a value/state change can be displayed elsewhere.
eg: another way would be to have 2 LEDs, with each indicating a state. and in the same way you could have a stack of 3,..or 5 LEDS, and you just hit the button repeatedly to step through them (step increment action). i got quite into this, using Synthedit, and i'd have little mini-prefabs for momentary, latching, toggle, exclusive 'radio' button array etc. depending on what was needed. nb: in SE, an exclusive radio group is like a boolean daisychain, with the 'on' switching all the others off (i wasn't the originator, did a lot of cribbing in synthedit as well ;-) ) so no, i no longer have a JU-106, that was 20 yrs ago :-/ and inspired me to make this: (synth buttons work correctly.. as for the standard of the emu', i'll let you check it out, 32bit Win - no claim to authenticity, it uses regular SE modules, result of studying Junos and chorus circuits following the principles broadly, -my attempt at making a credible UI with Knobman and Skinman ! (which is why i'm lazy now and try to use Ctrlr onboard graphics. spent months making that plugin...) (soz, i digress..)
https://bedroomproducersblog.com/2011/04/24/free-juno-106-emulation-by-mztk/

[subv0x]

actually had a lot of fun in synthedit making things with LEDs and stepcounters, shift registers, binary/hex to decimal. it's a great environment for experimenting with stuff like this - it's how i figured out how 808 and 909 sequence LEDs work .. (XOR, which meant nothing to me previously lol)

[subv0x]

Chorus: i think blue is just Off. it is enabled when you select I or II.
the Juno60 is different: I and II can be on at the same time, i think?

so choice is Off, I, II - yeah blue does not have a LED, it is just Off.

this is what i based my UI on for sizing:
https://www.kvraudio.com/product/vst-au-juno-106-editor-by-rekon-audio
https://static.kvraudio.com/i/b/vst-au_juno-106_editor.jpg

i think the thing with these combined parameters is that is ignores 0s because: binary addition: on a bit, 1+0=1, 0+0=0, doesn't change.
so the thing is to find decimal values whose binary doesn't create conflicts. in a way, kind of leapfrogging over the lower bits, if you see what i mean; that's how i visualised it at the time. (total buzz for n00b computerist to figure out, especially when you then get the device responding)

there is, no doubt, an atari editor or cubase mixer map for this >>
https://www.cykong.com/CubaseSX/SXpanels.htm
https://www.cykong.com/CubaseSX/PanelsXML/Roland%20Juno-106%20SX%20Panel.jpg
https://www.cykong.com/CubaseSX/SXpanels.htm#Roland%20Juno-106

(mention of MKS7 panel there, for someone who was looking for one)

EDIT: forget those, not useful, just checked. was hoping to see a nice easy list of sysex messages ;D

[dnaldoog]

All right! I have uploaded a new version 1.2.0 which hopefully fixes the Chorus sysex (byte 16) – all new code:

Please check it out @puffer3 and @subv0x .

I looked at the implementation in Midi Quest 12 Demo and SoundDiver 3.0. Sound Diver is contrary to the manual and so is MidiQuest - MidiQuest seems to have the 6th byte reversed (switches between Chorus 1 and Chorus 2) but maybe the manual is wrong?

Note to self: Only write panels when you have the synth in front of you 👍

...
    local byte = 0
    local t = {
        panel:getModulatorByName("range-16"):getModulatorValue(), -- bit 0
        panel:getModulatorByName("range-8"):getModulatorValue(), -- bit 1
        panel:getModulatorByName("range-4"):getModulatorValue(), -- bit 2
        panel:getModulatorByName("pulse"):getModulatorValue(), -- bit 3
        panel:getModulatorByName("saw"):getModulatorValue(), -- bit 4
        bit.bxor(panel:getModulatorByName("chorusOff"):getModulatorValue(),1), -- bit 5
panel:getModulatorByName("chorus1"):getModulatorValue() + panel:getModulatorByName("chorus2"):getModulatorValue() * 0 
-- bit 5 ( off=1,on=0)
-- bit 6 ( if zero then chorus 2/ if 1 then chorus 1)
    }

    for i,v in pairs(t) do -- concatenate each bit
    byte=byte+bit.lshift(v,i-1)
    end
    --console(string.reverse(table.concat(t))) -- debug binary representation
    --console(string.format("byte=%d 0x%.2x",byte,byte)) -- debug final result


    local channelOut = panel:getProperty("panelMidiOutputChannelDevice") - 1
    local syx = string.format("F0 41 32 %.2X 10 %.2X f7", channelOut, byte)
    panel:sendMidiMessageNow(CtrlrMidiMessage(syx))

※ Note:

panel:getModulatorByName("chorus1"):getModulatorValue() + panel:getModulatorByName("chorus2"):getModulatorValue() * 0

could just as easily be

panel:getModulatorByName("chorus1"):getModulatorValue()

---

[subv0x]

@dnaldoog i only have the exe here.
(um blue button not visible at all :-) ) (but something there appears to work!)

in midiox, i'm getting messages, it all looks ok. i see you've gone for values 01h/21h/41h.
noting that Chorus on/off still toggles on/off. .. testing all the way through:

CH Off (with II selected otherwise) = 21h
ah: if i click CH On, now I is selected, and 41h was sent.
click II (CH On), it sends 01h.
and CH off again, sends 21h.
CH on, and it has jumped to I again.
something strange happening there: switch off II, switch back on, it's I ..

is it something simple like decimal 64/32/16? which is 40h/20h/10h
what happens to the other controls on address #16 if you send those values to a juno106? do the the other switches change to their 0 state? isn't it like the output of a shift register, where it's all separate physical data lines?

made some notes earlier:

xxxx 1000 is unused eg: dec 16
chorus Off could be 16 (10h )
1 = 64 (40h)
2= 32 (20h)

.. 10h,20h,40h

xxxx x111 is unused > 7 (07h)

what happens if you send 0111 1111 ? .. which is dec/hex 127/7Fh
does it set all the switches like this?
0 1 1 1 1 1 1 1
x 6 5 4 3 2 1 0
ch/ch/sw/pl/4/ 8/ 16

ch= i*/ii
ch= on
saw= > on
pulse=> on
4'= > only 1: 100/010/001 4/2/1
8'= > nb: xxxx x111 is unused > 7 (07h)
16'= >

(5 parameters to set, on one parameter address.)

the Octave parameter uses 4/2/1 (04h/02h/01h).
what happens if you send 3,5,6,7,9,0Ah...0Fh..? it can only have one bit high at a time (... or synthesizer breaks? j/k )

if you send F0 41 32 00 10 01 F7 which ChorusII does, it will set the octave/' to whichever length that corresponds to.
so maybe that was supposed to be 10h ?

(many years ago i messed around with this kind of thing with a quadraverb, trying to see which values were needed. fascinating. and then never used the cubase mixer map ever.)

[dnaldoog]

That’s exactly what the code above is doing, left shifting each 1 or 0 to its correct position in the byte.

    for i,v in pairs(t) do
 -- concatenate each bit
    byte=byte+bit.lshift(v,i-1)
    end

[dnaldoog]

what happens if you send 0111 1111 ? .. which is dec/hex 127/7Fh

You can't send 111 in the lower three bits, because they act as a three way switch between 16' 001 8' 010 and 4' 100

[subv0x]

just found this. does look as if it has to be a composite message. so any change on any of those switches means collecting the state of all of them, and a single value/byte. (so ignore my meanderings above)
essentially it's like collecting a table of bit states, which are concatenated to obtain binary, which is converted to a decimal value.
https://www.atarimagazines.com/st-log/issue33/64_1_THE_ST_AND_THE_ROLAND_JUNO_106_SYNTHESIZER.php

[dnaldoog]

It looks like his explanation agrees with my code above.

You probably need to run:

delete folder C:\Users\%USERNAME%\AppData\Roaming\C-Juno-106

to get the button showing. 😊

[subv0x]

yes got the button back.
i had hoped my 'bit-leapfrogging' might work .. but evidently i'm going to have to study the math you explained higher up.
this means you cannot fully remote a 106 from the average controller box. it needs a bit of code/maths.
i really want to know if these parameters can be addressed individually.
like the document there says, kinda weird decision to put all of these on combined parameters, when they had plenty of space to give each one its own separate parameter number.

the Kawai K1 also does some stuff like this - but i've got all of that responding to a Novation RemoteSL ..
tbh i never went into this when i had a 106 - i had an alphajuno1 with pg300 at the same time. did look briefly at the sysex, and saw how short the 106's messages were, but that's all (i was trying to combine all that with an Oberheim Cyclone arpeggiator, into an Atari, if you can imagine how long that took to crash reliably - lol stay away from Oberheim Cyclone, that's a fiendish device)

(do you have any insight about handshake messages? is there a generic sysex request for obtaining the sysex format of a device? i have some recollection of sending an ID request to an Alesis MidiverbIII, and it sending me its message format. from that i was able to guess parameter numbers, and get a full midi mapping for an effects box i didn't have the sysex data sheet for.)

[subv0x]

off top of my head, another way? > (trying to interpret your method. great panel setup, what is all that? and what does BootStrapState mean?)

ie: for 16 and 17 collect into table (for each group) all current values -as bit states, or as decimal values; each bit having a decimal On value, (1/2/4/8/16/32/64) and zero Off value.
-this table is then the binary 'word' and can be added up to obtain the decimal.
the method code is then triggered by all switch value changes in that group, changing the relevant bit, producing the decimal MIDI value, putting all the 0s and 1s in the right place.
(edit: aah: better to do binary in the tables, as easier to concatenate, and then convert to decimal.. )

that's my unsophisticated take on it :-) will now go and re-read your post on bitshifting..

[dnaldoog]

Yes that’s another good way to do it!

Each button in Ctrlr has an 'on' value of where the bit sits in the byte, so Chorus on/off would be 32/0, Chorus 1 0/64 but then you would call getValueMapped() and sum them all up. Same difference really. :)

[subv0x]

@dnaldoog and @puffer3
fantastic posts up there, and i'm going to read them again. ... and copy 'n' paste into notepad for future reference !!!

[subv0x]

also hadn't seen reference to Lua bitshift thing, which i must check out.
thanks for sorting out my understanding of how hex works, and splitting it into 4 bit groups etc etc

[dnaldoog]

Yes that is key. Once you get that you will easily be able to use Hex! Well I don’t know if it’s ever easy but it will really help you see it.

Also, a good way of visualising a table full of 1s and 0s is to print it like this:

console(string.reverse(table.concat(t)))

It will show you the binary representation by concatenating the table values and reversing the string

[dnaldoog]

I uploaded Version 1.3.0 which changes the GUI logic of switching the chorus - I think you @subv0x mentioned the previous version was a bit odd~ 😑

[subv0x]

just loaded it - it greys out the I & II buttons now?

I & II buttons are sending the message twice (02h for II, 42h for I) - a double trigger somewhere -
ah: Chorus OnOff is still a toggle: it produces a different Off value depending on whether it's I or II. 02h or 22h. 42h or 62h.
which i suppose is the recalculating of the bits - must check to see what's returned if i change other switches in that group.

i have a feeling the 'Off' button should just do Off. and Chorus is activated by pressing I or II. not certain of this, but seems logical.

edit: ok, yes, all the numbers are changing depending on which switches are activated. (what an annoying thing for Roland to have done !)

[dnaldoog]

… ah: Chorus OnOff is still a toggle: it produces a different Off value depending on whether it's I or II. 02h or 22h. 42h or 62h.

So byte 6 indicates whether chorus 1 or 2 is activated. If chorus 1 were selected and then chorus turned off (byte 5 becomes 1 or d32 ), I believe that byte 6 is transmitted as 1 = d64 (chorus 1) or 0 = 0 (chorus 2) depending which was last selected.

In other words making it zero would do nothing and be changing to chorus 2 which is meaningless when chorus = off, so if you happen to have chorus 1 switched on and then switch chorus off, you would get something like x110 0001 (with 16' engaged) and if you switched chorus off when you had been using chorus 2, you would get x010 0001.

chorus on would be

• chorus 1 on x100 0001
• chorus 2 on x000 0001

Confusing much?

[dnaldoog]

@subv0x Well I have changed the chorus buttons yet again.

See version 1.4.0 🥱

[subv0x]

downloading.. if it's any consolation, when i did the UI in synthedit i probably spent at least a couple of days figuring out buttons. didn't have to deal with bitwise hex though. there's an OR in there somewhere :-) >> boolean truth table.