Moog Sub37 panel

[Carl Licroy]

Thanks for your help. Maybe I found the begining of the solution. This is the projet of my knowledge database for the slim phatty :

-- CONTENT OF MOOG SLIM PHATTY SYSEX FILE

-- All datas are stored as "bits sequence" and "packed" in sysex message. So the 
-- device begin to convert every values from decimal to binary, and then store every
--  bits in bytes. These bytes coutain 8 bits. Reading right to left, The last bit 
-- (the 8th bit) is always empty (=0). Finaly, every bytes are converted in Hex 
-- to create a complete sysex file.

-- For example, if you have "A" to "G" parameters, which only need 8 bits, they are
-- stored in bytes like this :
--	                 Binary		       Hex
-- byte 1 : 	0 A6 A5 A4 A3 A2 A1 A0 	--> 	00
-- byte 2 :	0 B5 B4 B3 B2 B1 B0 A7	-->	01
-- byte 3 : 	0 C4 C3 C2 C1 C0 B7 B6	-->	..
-- byte 4 : 	0 D3 D2 D1 D0 C7 C6 C5	-->	..
-- byte 5 : 	0 E2 E1 E0 D7 D6 D5 D4	-->	..
-- byte 6 :	0 F1 F0 E7 E6 E5 E4 E3	-->	..
-- byte 7 : 	0 G0 F7 F6 F5 F4 F3 F2	-->	..
-- byte 8 : 	0 G7 G6 G5 G4 G3 G2 G1	-->	..
-- 
-- Now, the device only use the minimum bits required. So if a parameter can only
-- have 4 values, only two bits are needed because the first value is always "0" :
--
-- 0 = |0|0|		1 = |0|1|	2 = |1|0|	3 = |1|1|
--
-- The number of bits depends on the number of possible value, and does not refer to
-- the real value of the parameter! For example, oscillators ranges only have 4
-- possible values : 16, 32, 48, 64. So they only use two bits like this :
--
-- 16 -> 0 = 0 = |0|0|	32 -> 1 = |0|1|	48 -> 2 = |1|0|	64 -> 3 = |1|1|

-- To know how much bits are required for a parameter, you have to convert the
-- number of values in binary. You can use ctrl buildin midi calculator. For
-- example, the number values of oscillators waveforms is 16383. So 14 bits are
-- needed.
--
-- Finaly, you have to find the position of the sequence :
-- byte244:	|X|X|X|X|Osc1range1|Osc1range2|X|X|
-- byte245:	|X|X|X|X|X|X|Osc2range1|Osc2range2|

I have to test it. I’ve found a function to transform a number in bits sequence, and you can choose the number of bits :

function numToBits(num,bits)
	 -- returns a table of bits, most significant first.
    bits = bits or select(2,math.frexp(num))
    local t={} -- will contain the bits        
    for b=bits,1,-1 do
        t=math.fmod(num,2)
        num=(num-t)/2
    end
    return t
end

Now I have to find a function to transform bits sequence in numbers… and find the places of all bits sequences in sysex file…

[goodweather]

Lovely simple…
It is clear that this has been build from a write perspective and not a read one.
They are taking each parameter at a time, convert them then add the result at the end of a string.
The issue with this way of working is that you’d better not add extra values to an existing parameter…
Anyhow, I would suggest you to first identify the positions and to start with the obvious 0-127 or 0-16383 as EG Attack and co.
You can do that with the procedure I explained above (initial value – save sysex – final value – save sysex – analyse the delta).
Then I would suggest that you work in Excel for easier visualization and understanding then for conversion purposes.
You should foreseen a few cell for input (one by byte) for example 3 cells. Then you can have cells showing the bit content per 2 bits maybe (use AND and shift operations).
Foresee 2 sets of those so that you can directly compare for example initial and final value of a parameter.
If you think it is a good approach and need help with such Excel file, just tell me then we can exchange via personal messages…
The key in this analysis is visualization.

[goodweather]

Was quicker done than explained. Here is the Excel file…
I just used internal functions. Was not needed to perform bit operations (of course, once you have done the analysis you will have to do the bit operations in Lua inside the panel for read and write).
And something else not to disappoint you (I figured out that myself hence my switch to Pro2 panel) is the fact that knowing the structure of the file is one thing. The other thing is to know sysex commands to exchange files, to calculate the checksum…
Finaly, reading a patch file will be good to analyze and understand patches but maybe not to fully manage your synth from a PC.

Attachments:

You must be logged in to view attached files.

[human fly]

piping up 😉 !
i’ve got this panel to the stage whr i want Lua skills (that
i don’t have)

Roland D-110 panel

i was thinking about being able to retrieve presets and banks
via dump request, but yes, how is a bulk dump structured? and
how do you get values to go to the correct addrss?

from what i read elsewhere, if you have too many bytes in the value
position, they will cascade to the next consecutive address – is that
how patch dumps work? so you would input one header, and the 1st
address in a series of parameters, and it fills in the value ‘slot’,
going down the list? this is what occured to me, anyway. no doubt not
that simple, even if it is the way, because you get dummy addresses
etc.
(if you can assist in any way on my project, most appreciated !)

[goodweather]

Hi human fly, I’m busy building a panel for the DSI Pro2 but could help you with your D110. I had one long time ago…
For the Pro2 I will make a librarian.
I learned Lua with Ctrlr…
Anyway, I’m putting the priority on the Pro2 but could guide you for the D110 as a lot is repetitive.
The philosophy I’m following is:

• I have a uiGroup containing different uiLabels. This represents the screen of the synth
• To each uiButton I attach an OnClick event (in fact in Ctrlr it is OnMouseDown) to adapt the screen with manual extracts and to see the actual value of the param and OnChange event to dfisplay the current value
• when this is done, you can try reading an exported sysex provided you have its structure (I add to decode everything for the Sub37 but DSI is documenting everything for the Pro2). Don’t remember for the D110 but usually Roland is also well documenting
• Then you can build a write sysex
• Then you can build the Send and Receive requests messages to the synth (by patch or full bank)

So, let’s touch base and progress together…

[niels@dettenbach.de]

Just btw: Moog publishes their own plog out VST/AU/AAX next days (which works really nice). I’m in the beta program and the progress seems really far plus the publishing was announced these days officially.

The editor/librarian is developed hardly together with the new sub37 firmware – so it may make sense to get/use the current beta firmware when fiddling with a remote MIDI implementation.

just my two cents…

((d^b))
dettenbach
music fab

[goodweather]

Yep, I know. Thx for also pointing this out.
I’m sure that they announced the editor and beta program when I published the picture of my editor on the Moog forum… (p6 in topic Sub 37 editor/librarian and VST plugin).
I abandoned the work due to total lack of documentation and very unstructured midi implementation (I reversed engineered it and documented it).
So I’m also waiting for the official release of the Moog editor but this is now almost 3 months ago…
I will clean my editor (remove wave display – temporary, remove tabs to only have the editor – tried to implement the sequencer but too time consuming to find the sysex structure) and publish it here.
Visually I prefer my editor over the Moog one and it gives me also the Manual explanations (not sure the Moog editor is doing that – I don’t have the beta).
I can read the Sub37 sysex files and this was my primary goal (visualization) as I prefer to manipulate the actual synth.

Now I enjoy working on the DSI Pro2 panel. So clean Midi implementation and much better implemented (bi-directional handling with Ctrlr worked directly perfect while it doesn’t with the Sub37). I achieved a lot in just a few days work in comparisons to the weeks and months for the Sub37. Much more rewarding Ctrlr spoken!
DSI support guys are also reacting and answering directly on my tech support questions while I never got any reply for my Moog support inquiries.

As you are in the beta program, do you know if the editor will be free or not and do you know if it is possible to read the transmitted/received sysex / NRPN messages between the Moog editor and the Sub37 (for example with MidiOX)? Thx!

Attachments:

You must be logged in to view attached files.

[Carl Licroy]

It’s the same with the slim phatty : I bought the official editor and I don’t like it. Even the soundtower editor don’t fit my needs.

Commercial softwares always reproduce the interface of hardware devices. But with software you don’t have hardware constraint in placing your knobs and sliders… So you can acheive a much more “logical” and intuitive placing.

Manufacturers makes editors that look nice but are not practical. And for me the most important is easy and fast access to presets on my computer disk because I can organise them and store them whithout to deal with storage capacities of my synths.

So CTRLR was the best piece of software I found so far because everyone can personalize panels to fit their needs, even if you’re not a programer (I’m not and learn all with infos found on the web).

For me, when you buy a synth it’s a right of the owner to have access to the midi and sysex specifications to control it the way you want. Because who knows if the official editor will still works in 5 years? But with the manual of my roland JX8P I achieve to control it even more than 20 years after construction…

Hopefully I’m just about to finish decoding every bits of the sysex file of slim phatty… But it was so time consuming… I was interested by the sub37… but now I will think twice before to buy it…

[Carl Licroy]

By the way, your panel looks so cool Goodweather! Keep your work on it, because I’m sure it will be better than the official one…

[goodweather]

Carl Licroy wrote:

By the way, your panel looks so cool Goodweather! Keep your work on it, because I’m sure it will be better than the official one…

Thx for your kind words Carl!
Wait for the Pro2 panel I’m working on (with great inspiration, Midi dialog “stolen with pride” from your Power08 code).
Btw, I think exactly like you. I don’t understand at all why Moog can’t produce such nice doc as DSI.

Something else, I can give you the code for envelope graphs (adapted from old panel made by dasfaker but that I made fully flexible in size) OR I could code it for you directly in your Power08 panel.
The only thing you should do is to foresee an area (uiGroups) where I could put them. Either one graph with a pulldown to select which EG to display OR all graphs at once (this is better).
So, just adapt the layout of your panel, put the uiGroups and I fix the graphs.
Just let me know!

[Carl Licroy]

Thanks!

Graphs are a good idea and your help is welcome. But I’ve tried to have a very compact interface. I have to find more space. I’m thinking to work on my POWER08 panel after finishing the slim phatty. I want to add these new functions : copying and reseting layers / full bidirectional knobs. Maybe I will add graphs, I’ll let you know 😉

[goodweather]

OK!
If you succeed to do fully bidirectional NRPN buttons, I’m interested for my Sub37! I tried and it doesn’t work especialy when setting NRPN out (which is a must if you want to handle all parameters (with CC, you miss half of the panel).
Once again, doing exactly the same on the Pro2 and there it works perfectly bidirectional in NRPN…
(FYI, I must also find the Pro2 sysex structure by myself, it is not public but DSI support stated it was very close to the NRPN order – I’ll see)

[Carl Licroy]

Hi goodweather!

Working on next version of POWER08 editor I found the way to create a fully bidirectionnal panel with nrpn parameters.

The P8 send 4 nrpn messages each time a value change when you move a knob :
RAW:[b0 63 00]
RAW:[b0 62 03]
RAW:[b0 06 00]
RAW:[b0 26 4b]

First byte (b0) is for control change. Second byte is for NRPN message type (you can find it in the DSI manual) :
63 : parameter number msb
62 : parameter number lsb
06 : parameter value msb
26 : parameter value lsb

The third byte is for the values.

So I introduce this code in my MidiMessageReceive function and it works (s refers to the size of the midi message) :

if s == 3 then
	
-- Check NRPN message type
NRPN = data:getByte(1)
NRPN = string.format("%.2x", NRPN)
--console ("NRPN: "..NRPN)
	
if NRPN == "63" then
	-- store parameter number MSB
	parameterMSB = data:getByte(2)
	parameterMSB = string.format("%.2x", parameterMSB)
end

if NRPN == "62" then
	-- store parameter number LSB
	parameterLSB = data:getByte(2)
	parameterLSB = string.format("%.2x", parameterLSB)
end

if NRPN == "06" then
	-- store parameter value MSB
	valueMSB = data:getByte(2)
	valueMSB = string.format("%.2x", valueMSB)
end

if NRPN == "26" then
	-- store parameter value LSB
	valueLSB = data:getByte(2)
	valueLSB = string.format("%.2x", valueLSB)

        if parameterMSB ~= nil and parameterLSB ~= nil and valueMSB ~= nil then

		-- retreive NRPN parameter number
		if parameterMSB == "00" then
			parameterNumber = tonumber(parameterLSB,16)
			--console("parameterNumber: "..parameterNumber)
		end
		if parameterMSB == "01" then
			parameterNumber = tonumber(parameterLSB,16) + 128
			--console("parameterNumber: "..parameterNumber)
		end

		-- retreive NRPN value
		if valueMSB == "00" then
			parameterValue = tonumber(valueLSB,16)
			--console("parameterValue: "..parameterValue)
		end
		if valueMSB == "01" then
			parameterValue = tonumber(valueLSB,16) + 128
			--console("parameterValue: "..parameterValue)
		end

		-- update modulator value
		if parameterNumber == 0 then
					  panel:getModulatorByName("LAYERA_OSC1_Freq"):setModulatorValue(parameterValue, false, false, false)
				end
				
			else
				return
			end

This example has only one modulator. I’m currently adding the others, but it takes time (about 400 parameters on the P8…). I will upload the new version as soon as I have finished this part.

[goodweather]

Hi Carl, FYI, I have full bidirectional communication and handling with the Pro2 and NRPN without doing any coding (except to show OnChange values on a Ctrlr “LCD” or to move EG or wave graphs of course).
So, I’m a bit curious to know why you don’t get this with the Prophet08…
FOr the Sub37, I suspect a bad or non standard Midi implementation.
On the Pro2 (and probably Prophet12 – checked the manual for that one) it is very clean.

What I have done:

• I’m not using MidiMessageReceived
• I’m using the MIDI part of the component with the standard messages you get from the second icon

Just giving a screenshot as example.
Did you try that simple method?

Attachments:

You must be logged in to view attached files.

[Carl Licroy]

Thanks that’s interesting! I’m using sysex messages that’s why I have to create this code… Don’t you experience midi overload with NRPN if you have a method which sends a lot of parameters to the synth?

[goodweather]

At this stage, no but I’m only manipulating the panel param by param.
I’ll use sysex for program/bank send/receive.
Btw, I took your panel, change Osc1 Fine Tune to NRPN, removed MidiMessageReceived.
It works but not bidirectional.
I’ll investigate further when I’ll have some time.

[Carl Licroy]

Finally I’ve finished and uploaded my panel for the Slim Phatty. Was pretty hard to code… These are some informations who can help those who want to create panels for moog’s devices (but can be different according to each device) :

1) Every rotary knob value is inverted so you have to convert the binary to replace all 1 by 0 and all 0 by 1. They are coded on 14 bits which means values from 0 to 16383. But Moog’s range is 0 – 4095. So we have to convert values with this formula : (14bitsvalue – 3) / 4

2) These are the 73 characters recognized by the slim phatty (without []) :
[ ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyz!#$%&()*?@]
Slim Phatty don’t use ascii number, characters have a number starting from 0 (for space) to 72 (for @).

Hope this helps.

[goodweather]

Thx Carl.
For the Sub37 it is NRPN direct.
Some question though, do you have a checksum at the end of the SP dumps?
If yes, did you succeeded to know how it is calculated?
This is one of my blocking point for the Sub37 panel.

[Author]

Posts