Possible CC control?

Dug out the old trusty Kenton Control freak and it turns out controlling the boutiques is quite easy from an external controller. Only tried the JP-08 so far but all should be the same (with the caveat that there may be a different Model ID)

The important finding is that they are using 8-bit values sent over 2 bytes rather than the standard 7-bit (0-127) values for CC (this many explain why they chose not to send CC’s directly - this way they have higher resolution). Shame they did not go for 14bit that would still only take 2 bytes - but there you go.

Of course if you wanted to control the boutiques from standard CC values you would have to interpolate 7 bit to 8 bit or use NRPN’s which many DAWs do not support.

When it comes to controllers the BCR2000 did create 14 bit data output though from the rotary controls so you could go from 14bit to 8bit and loose no resolution. Maybe other controller apart from BCR2000 and Kenton can produce above 7 bit data???



Only mapped a couple of controls to the freak but proof of concept is working perfectly well.

Makes it easier when you have 100mm faders than <20 mm ones lol!

#02 = Cuttof
#04 = Rez

F0 - Start Sysex
41 - Roland identifier
10 - Divice ID
00 - Model ID
00 -
00
1C - Boutique ID (1C = JP, 1D = JU or 1E = JX)
12
03
00
02
04 - Control number (Each knob/button/switch has its own value
XX - 8 bit value sent, split over 2 bytes.The 4 hi bits of each byte are zero and the lo 4 bits
XX - contain the data – sent most significant byte first – as follows: 0000HHHH, 0000LLLL
XX - Standard Roland Checksum
F7 - End Syex

My Initial idea is to possibly create a hardware circuit that listened for the value being edited on the boutique then allowed fine control using a rotary encoder to 'tweak' the value that otherwise may be slightly inconvenient on the small sliders (and possibly the knobs as well).

I do have something in java that is used to combine multiple controllers to send midi data to my Daws (used it to emulate Push before I got one) but I have to dust the code off and add some new modules for the boutiques. So its very feasible to extend these devices past there original specification.

In the meantime if anyone is handy with bomes or similar translater it should be quite trivial to create a converter from daw/standard midi controllers to the boutiques. I have had success with Kontakt but it can be laggy. Purpose software would be more adventagous.

So far it turns out that JX uses the following

F0 41 10 00 00 00 1E 12 03 00 0D 04 05 08 5F F7

and Ju uses the following

F0 41 10 00 00 00 1D 12 03 00 08 02 07 03 69 F7

I.e the device id for JU-06 is 1D and the ID for JX-03 is 1E whilst JP-08 uses 1C

Full list of Sysex to follow for all controls but that should be enough to map all controls. Good to see there is a device ID so one daisy chain can be sent to all devices. Excellent!

tboneuk wrote:

So far it turns out that JX uses the following

F0 41 10 00 00 00 1E 12 03 00 0D 04 05 08 5F F7

and Ju uses the following

F0 41 10 00 00 00 1D 12 03 00 08 02 07 03 69 F7

I.e the device id for JU-06 is 1D and the ID for JX-03 is 1E whilst JP-08 uses 1C

Full list of Sysex to follow for all controls but that should be enough to map all controls. Good to see there is a device ID so one daisy chain can be sent to all devices. Excellent!

Very nice findings!!

Maybe it is worthy to try this on a A-Pro xxx or PCR-xxx Roland controllers that fully support SysEx... In case anyone has one of those...

PauloF wrote:

Maybe it is worthy to try this on a A-Pro xxx or PCR-xxx Roland controllers that fully support SysEx... In case anyone has one of those...

As long as the device can generate a checksum from the values then yes it should work fine.

Here is a complete list of the codes for all 3 units. I found that the controls actually have an address of 2 bytes and not the original one. so the actual format is as follows:

F0 - Start Sysex
41 - Roland identifier
10 - Divice ID
00 - Model ID
00 -
00
1C - Boutique ID (1C = JP, 1D = JU or 1E = JX)
12
03
00
XH - Control number H (Usually each section has its own value
XL - Control number L (Each knob/button/switch has its own value within the section
XX - 8 bit value sent, split over 2 bytes.The 4 hi bits of each byte are zero and the lo 4 bits
XX - contain the data – sent most significant byte first – as follows: 0000HHHH, 0000LLLL
XX - Standard Roland Checksum
F7 - End Sysex

I am only concerned with the mapping of sliders and knobs but the remaining switches and buttons are similar. When patches are chosen they appear to send a complete dump.

JU-06

XH XL
06 00	LFO		RATE
06 02	LFO		DELAYTIME
07 02	DCO		LFO
07 04	DCO		PWM
07 0C	DCO		SUB
07 0E	DCO		NOISE
08 00	HPF		FREQ
08 02	VCF		FREQ
08 04	VCF		RES
08 08	VCF		ENV
08 0A	VCF		LFO
08 0C	VCF		KYBD
09 02	VCA		LEVEL
0A 00	ENV		A
0A 02	ENV		D
0A 04	ENV		S
0A 06	ENV		R


JX-03

XH XL
0C 0C	DCO2		TUNE
0C 0E	DCO2		FINETUNE
0C 16	LFO
0C 18	ENV
0D 00	VCF		SOURCEMIX
0D 02	VCF		HPF
0D 08	VCF		ENVMOD
0D 04	VCF		CUTOFFFREQ
0D 06	VCF		RESONANCE
0D 0C	VCF		LFOMOD
0D 0E	VCF		PITCHFOLLOW
0E 02	VCA		LEVEL
0B 04	LFO		DELAYTIME
0B 02	LFO		RATE
0F 00	ENV		A
0F 02	ENV		D
0F 04	ENV		S
0F 06	ENV		R


JP-08 

XH XL
00 00	LFO		RATE
00 02	LFO		DELAY TIME
01 00	VCOMOD	LFO MOD
01 02	VCOMOD	ENV MOD
01 06	VCOMOD	PULSEWIDTHMOD
01 0A	VCOMOD	CROSSMOD
01 12	VCO2		RANGE
01 14	VCO2		TUNE
01 18	VCO1&2	SOURCEMIX	
02 00	HPF		CUTTOFF
02 02	VCF		CUTTOFF
02 04	VCF		REZ
02 0C	VCF		LFO MOD
02 08	VCF		ENV MOD
02 0E	VCF		KEYFOLLOW
03 00	VCA		LEVEL
04 00	ENV1		A
04 02	ENV1		D
04 04	ENV1		S
04 06	ENV1		R
05 00	ENV2		A
05 02	ENV2		D
05 04	ENV2		S
05 06	ENV2		R

Hi tbone, thanks for all of this exploration and the details. I'm not sure if or how I can put it to use (possibly with MIDI Designer Pro for my iPad), but I'm going to try. The Boutiques are so hands-on that it may be a wasted effort for me.

However -- and you might know the answer to this -- one thing I would find extremely valuable is to see if I could use Sysex to fetch and report the current settings of a patch. There are a few presets on the JX that kind of baffle me, and I wish it was easier to figure out what combination of settings is used to make them. Do you know if there is some way to query the device for its current settings?

I agree the boutiques are vey hands on and it is that fact that I do really like them. I explored the sysex so that 1) it could provide a translation from cc to sysex
2) rather than an existing unit to control all Parameters via sysex ( like a bcr2000 for exmaple) I thought a bi directional device that monitored incoming sysex allowed you to tweak the value with an encoder and sent the result back to the boutique. Thus, one encoder that would be used as a fine control for any of the sliders or kobs on the boutique. Hence, removing the slight limitation of small travel in the units control


Anyway. To get back to your question. I have noticed that the units send a complete dump of data when a patch is selected. this data is used to update the chained device so the settings are in sync. I haven't carried out a deep anylsis of the data but it looks like you could evaluate each value of the controls for that patch. The sysex it's sending is comparable to those I have listed albeit in some cases it appears to concatenate several controls together within a data block.

So if you setup a sysex monitor application with chain mode turned on and press one of the preset buttons I'm sure you could manually parse the information to get the values you require. Once you have that figured out then it's just a case of watching the values on a monitor app as you set each control. I guess if you have the knowledge in Java or c# then the logical progression is to translate the two data bytes representing the value of the slider to an 8 bit number. havn't used midi designer for a while, maybe that can translate two bytes to an 8 bit number? Either way, it will be easier to set a value if you have a correlation from 2 bytes to a single viewable number but manually it can be done.

It would be really nice to see the sysex data for the switches also, are you willing to do this tboneuk? The values for the positions on the switches are also needed of course.

I'm working on a sysex -> cc converter but I will receive my units in late November...

Sure, I will map them tonight or maybe tomorrow and publish a updated list on this forum.

I suspect they are similar to system-1 in that when selecting a OSC type sends two sets of values. Firstly one to determine the control then again with the value. I havnt paid much attention though with the boutiques so maybe it is simpler process.

What are you using to create the converter?

Also, let me know if you need the algorithm for the checksum. It's quite simple, just ensures that the checksum is a sum of the values that doesn't exceed 128.

Thanks man, appreciate it! :) I'm using an Atmega Atmel328 (Arduino), I have designed a small board for it to enable conversion in both directions. This device could be used for other conversions / filters also (by reprogramming the Atmel processor). I'm also working on a system tray Windows application that would do this conversion both ways.

I have the checksum algorithm under control, thanks for offering the help though!

Sounds good. Hasn't the 328 only got one hardware UART? Of course even if it has you can use software UART for the midi out. I'm interested to see how it pans out. Could save a bit of developing time for both of our projects if we can share notes ;)

I was thinking one of the larger Avr's (same kind of chip that are on the Mega 2560's) that has two dedicated UARTS would be a good start as I would require two midi ins as well as a midi out which I will either create a software midi output or SPI another UART (presuming I can find one lying about here). I have a fair idea how my implementation would work. I'm just seeing if the boutiques offer me the value I'm looking for while i have them on trial before diving in and starting the development.

Anyway, I will post the switch data soon as I can for you.

Cool! Yep, the Atmega has only one hardware Uart so I'm going to use the softserial library for the other. The atmega2560 has 4 hardware uarts but it's more expensive and an smd component so it's not as diy friendly. I won't use the midi library for this, will just read the bytes as the arrive at the ports.

Thinking of what you are planning to do I think you can manage with the 328. One thing you have to be aware of when combining midi signals is that messages don't overlap, so if a sysex message is coming in to the device you have to wait with sending the value of the encoder.

Inspecting the parameter values I noticed the first value (hh) goes from 00h to 0Fh and the second one (ll) from 00h to 18h but only even numbers it seems. So to quickly find what kind of control is sent through sysex I made a map (two dimensional array). Note that in this map only the knobs (C_SLIDER) for JX-03 are marked out.

The map is a mess in the code window below but it should be more clear if you copy it to a text-editor.

The C_SW_2 etc. are switches (2-6 position switches, I'm not sure how many steps the switches have at most on these synths)

#define C_NONE   0
#define C_SLIDER 1
#define C_SW_2   2
#define C_SW_3   3
#define C_SW_4   4
#define C_SW_5   5
#define C_SW_6   6

const byte controlType[16][13] = {
  // First parameter values ranges from 00h to 0Fh
  // Second parameter values ranges from 00h to 18h but only even values, so they can be divided by 2 for mapping purposes
  //     00,      02,      04,      06,      08,      0A,      0C,      0E,      10,      12,      14,      16,      18 (second parameter values)
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 00 (first parameter values)
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 01
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 02
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 03
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 04
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 05
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 06
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 07
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 08
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 09
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 0A
  {  C_NONE,C_SLIDER,C_SLIDER,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 0B
  {  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,C_SLIDER,C_SLIDER,  C_NONE,  C_NONE,  C_NONE,C_SLIDER,C_SLIDER}, // 0C
  {C_SLIDER,C_SLIDER,C_SLIDER,C_SLIDER,C_SLIDER,  C_NONE,C_SLIDER,C_SLIDER,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 0D
  {  C_NONE,C_SLIDER,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}, // 0E
  {C_SLIDER,C_SLIDER,C_SLIDER,C_SLIDER,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE,  C_NONE}  // 0F
};