Multitimbral synth panel

[inteyes]

Hey guys!

Can you share the experience about building multitimbral instrument panels?

I plan to make panels for my Waldorf Q and Novation Supernova II. They are both quite complex synths with a bunch of controls. So my main questions are:

1. What about Ctrlr's MIDI performance for such big panels? Multitimbrality means that a large amount of data will be transmitted and received for each instrument, sometimes simultaneously. What to expect here? That's actually the main question that bothers.
2. What is the best way to organize controls on the workspace for each instrument? Just copy-paste them on separate layers and edit their properties in the place, or is there more elegant solution? A good example of such a panel (if any) much appreciated.

Thanks!

[damiensellier]

Hi,
I don't see any potential issue related to hi midi data flow.
You can take a look at what's available on https://ctrlr.org/panels_by_name/ There's many multitimbral synths like virus TI https://ctrlr.org/tag/virus/ or even the Novation supernova I and supernova 2. https://ctrlr.org/novation-supernova-panel/ https://ctrlr.org/novation-supernova-2-rack/
Some panels have all the layers in the same window which can be cluttered, some use uiTabs to display the different layers and switch between them.
I would prefer having a clean and simple view with 1 layer at a time and select layers between tabs if there's more than 4 layers.
To go faster if all layers have the same parameters you create a group containing sliders then duplicate the group and drag/drop them in the different tabs of a uiTabs (right click > groups > uiTabs) with x tabs for x layers. This way you'll just need to focus on one layout of the first layer and will just need to update the midi messages and names for modulators later.

You can also take a look at panels for yamaha TX (fm synths) that works with operators like layers, they often have all the parameters in one window but it's like having only 4 layers https://ctrlr.org/yamaha-dx11-editor/ https://ctrlr.org/yamaha-tx81z/

Do you have all the midi documentation already?

Damien

[inteyes]

Thanks Damien! Finally I found some time to get into it.

Looks like none of these panels are utilizing "multitimbrality" in the same way as I expected :) Supernova panels are fully monotimbral.
Virus panels are using same controls for different instruments or something like that, because I was not able to automate even controls for 2 different instruments at once.

Well, I guess the best way to figure that out is to create some basic panel with some controls and give it a try :) Just wanted to get some personal experience with big panels and their performance here.

As for the documentation - I "sort of" have it. I have unofficial sysex chart for Q and SN1 chart for SN2. As far as I know, there were no publicly available sysex chart maps for any of these synths.

[dnaldoog]

Hi @inteyes !

One thing to consider is VST indices.

I designed a panel for the TX81Z and used the same ctrlr slider on only one layer for any one of four operators keeping a record of each value in a table i.e:

t={
attack_rate={31,4,0,28}
}

so when the user changed tabs the value for a single control was updated from the table.

It was all well and good until I realised the (small?) fundamental design flaw.

There can only be one vst index for each control ( although maybe the vst index could be updated dynamically? Maybe not ― but anyway I never went there).

So I eventually added a hidden layer with each control - say attack_rate1,attack_rate2,attack_rate3,attack_rate4 etc each with a separate vst index, which the visible slider updates and it is the hidden control that sends out MIDI. It actually works quite well, but if I did it again I would have a separate layer (or tab) for each operator (i.e four layers or tabs in the case of the TX81Z) as Damien recommends.

[inteyes]

Yeah, I made a similar approach in the panel for MS2000, and faced similar problem :) I managed to get it to work in realtime, but there was no way to automate controls on different layers simultaneously. Well, because there were only two layers, and because I was not intended to automate any controls separately anyway, I just leave it there as it was.

And yes, I'm thinking of going the route of creating a set of controls for each individual instrument, it seems more transparent to me. At least for now :)

Thanks for sharing your experience, @dnaldoog!

[dobo365]

I think it is easier to use different tabs rather than layers.
You can also try to put different parts on the same tab so the user can directly see/adjust each part while seeing what is done for the same parameter in the other parts.
I did that for the Prologue and its two layers. Both layers are on one tab and this is highly appreciated by users.

[inteyes]

Agree, I will look into using tabs rather than layers.

The main problem with these synths I mentioned is that they have a lot of controls for each timbre. Supernova, for example, have all the oscillators, lfo's, envelopes, effects sections and so on for every single timbre, so amount of controls for any instrument will be huge :)

But you never know what you can do till you try, right? So I will try :)

Thank you!

[synthmutt]

By multitimbral, do you mean multiple MIDI channels at once from the same panel? Ctrlr's MIDI output menu offers assignment to one MIDI channel for a panel - can anyone say if there's a way to override that in order to output more than one channel?

(I'm new to Ctrlr, working on my first panel.)

For use in a DAW, wouldn't the panel control one preset on one single MIDI channel, so running an instance of the panel for each channel used? Would it make sense to do that also in Ctrlr standalone mode?

[subv0x]

i'm working on a multitimbral panel at the moment - rebuilding something that was only on one channel, and which used the default sysex message box. i don't know if there a (marker?) to use for the midi channel bytes - the way there is for a checksum for instance - but you could construct your sysex message with a function, dependent on which part you're sending from. something to do a little test panel for: just make it for one parameter initially, and see if you can send it to all of them according to which channel you have selected. this is what i plan to do, but haven't attempted it yet (long way to go restructuring the rest of the tabs etc.)

looks like this:
panel:sendMidiMessageNow(CtrlrMidiMessage({0xf0, 0x41, 0x10, 0x16, 0x12, 0x04, 0x00, 0x0c, 0x00, 0x70, 0xf7}))

so you'd replace 0x10 with a table index eg: midch={0x00, 0x01,0x02, etc., 0x0F} so midich[9] will be midi channel 10. and similarly for other bytes if you want to build your message like that.

panel:sendMidiMessageNow(CtrlrMidiMessage({0xf0, 0x41, (midich[9]), 0x16, 0x12, 0x04, 0x00, 0x0c, 0x00, 0x70, 0xf7}))

(hope this is correct, have not test it yet)

[subv0x]

re: original question, uiTabs are best as 'containers' generally, i think. better than uiGroup, since you can flip tabs easily.

i thought about the size of the panel file, having loads of multiples of everything, - and loading time -
and actually attempted, for one panel, to have a single re-usable set of modulators, where it's continously writing to tables, and retrieving from them as you change part - and got it working quite well. i never thought of the VST Index issue though. ultimately, i'm concluding it's probably best to have individual modulators for each parameter. but i'm going to batch-declare/batch create the variables on panel load

for example, this is for a row of octave selectors in a sequencer row:

for i =1,16 do _G["octv"..i] = panel:getModulatorByName("octv"..i)

that gives you octv1, octv2, octv4,...octv16 as global variables for those 16 modulators.

(with thanks to dnaldoog)

[subv0x]

something i'm about to address is: should one make separate methods for each part/channel, if it's going to bloat the file? repeating the same code multiple times, with just the panel modulator name/variable changing each time?
i would say not, but it requires an extra degree of complexity in writing the initial method, so that it finds the modulator/variable each time, eg: if you have 16 channels, and 16 instances of the same parameter.

for context: i made a panel that only addressed the first part, for editing the preset. now i want to be able to edit the preset on any of the (eight, in this case) channels/parts. so if i only want one method, to adapt to any channel, i have to modify all of my methods, so that they detect which part, and which modulators, are being addressed. feeling a bit sketchy about attacking this, but it should be ok. i had some problems with a commonly used mod:getProperty("name") and dnaldoog suggested changing it to L(comp:getOwner():getName()) - which worked, so i may use that. i was not able to use the former twice in a panel - for some unfathomable reason ! - although it might have been the nature of the operation eg: addressing the 'component' rather than the modulator itself. (mm yeh i think that makes sense actually, although i couldn't see any reason why i had to do that, in that particular case; have to have another look at it).

i think this is the way to go - i have many modulators in this old panel, and it's pretty daunting rebuilding the entire thing. so i want to nail it before copying out all the modulators to the new multiple parts. what are your thoughts on this?

btw: beware copying tabs with everything in them, when you have sub-groups or uiTabs, because the contents of those do not copy.
moreover, i forgot about stuff in those (uiGroups and uiTabs) retaining their ownership/parenthood, so they can end up disappearing, and needing to be revived via the modulator list, and getting them to show on canvas again, which is a right PITA. managed to avoid it this time, by careful checking and removal where needed; and that all needs to be done before saving and re-opening the panel.

[dnaldoog]

Keep a global variable somewhere of which tone/part you are on. You can use panel:setGlobalVariable(0,part) when you change layers or tabs (part could be the tab number), so using the same function on all duplicates of a modulator you can know which one you are writing to or getting the value from:

local getPart=panel:getGlobalVariable(0)
panel:getModulatorByName("lfo "..getPart):getModulatorValue()
...

[subv0x]

is this what you did with JD990? it's a similar structure: 4 partials to a Tone, and 8 Parts/channels. there's an annoying thing called 'timbre', that 'contains' the Tone, that i'll have to deal with as well, and that's a separate set of memories - these are what are assigned to the Parts, with a Tone assigned within each one. (the lovely D110 notorious setup) - so: 32 partials, anyway.

all of this is going to be on uiTabs - i think they are more versatile than Layers, easier to handle. uiGroups are just problematic, with their parenthood - because you end up having to look at that as well as the parenthood with uiTabs ie: if you move stuff, or make copies (been revisiting that this morning ! stuff disappearing, not copying etc.)

i was thinking of declaring my global variables with _G( ) at startup.
at this point i'm just getting the trickier things i built before copied over into a fresh panel, and getting that working as before, maybe with some re-design before copying it out to other parts. a mini-panel to be uploaded shortly.

[dnaldoog]

The JD-990 has four tones to a patch, which could be similar to the D110 except the patch itself is called a tone and the four parts are called partials? Not sure.

I think layers are much easier to use than tabs, but opinions may differ. There's no visual editor for layers so switching and setup has to be done in lua.

t={"A","B","C","D"}

switchLayers = function(layer)
    panel:getCanvas():getLayerByName("A"):setVisible(false)
    panel:getCanvas():getLayerByName("B"):setVisible(false)
    panel:getCanvas():getLayerByName("C"):setVisible(false)
    panel:getCanvas():getLayerByName("D"):setVisible(false)
    panel:getCanvas():getLayerByName(tl[layer]):setVisible(true)
end

--[[ change the layer with something like ]]

changeLayer(mod,value,source)
local n=L(mod:getName())
local thisLayer=n:sub(-1) -- name for buttons: button1 button2 button3 button4
switchLayers(thisLayer)
end

Global variables declared at startup do not need _G. You probably never need to use _G unless you are concatenating a variable name in a loop and even then it is usually not necessary.

[subv0x]

with D110 the 'Patch' is the multiimbral 8-part setup, the Tone is the preset, with 4 'Partial' lanes.

but it also has this thing called 'Timbres', and these are what are assigned to Part channels, with the Tone assigned inside the Timbre.
this is what makes it so cumbersome to edit from the panel.
there are 2 banks of 64 Timbre memories, and one bank of 64 user Tones -with 3 ROM tone banks, a,b and r. there is also bank 'c' if you have a M256 RAM card inserted, which, i think, substitutes itself for the 'i' bank when inserted.

the hierarchy is:
Patch>Timbre> Tone> 4x Partials

they dumped the Timbre concept when they made JV. the D-110 is a bit like the ancestor of JV/JD multitimbral, structurally.
the D-20 doesn't have Timbre iirc, but has a Performance mode, with Upper and Lower, like D-50. or it can operate in multitimbral like the D-110 with 8 parts and rhythm part.

[subv0x]

hi dnaldoog, ok i've managed to adapt most of my methods for this panel to be 'generic' and work for all partials and parts - instead of having 32 separate methods for each section, it's now just one. finally getting this thing sorted out. i've used a 2-part suffix eg: p1pt1 is partial1, part1, and i can get that with string.sub: tonumber(string.sub(NAME,-4,-4)) and tonumber(string.sub(NAME,-1))
it can fail if it's just a string, needs to be a number.

new hurdle is the 'env mode' parameter, which switches off the sustain stage on ALL envelopes in a Tone (what JV/JD call a? patch?) and that doesn't need to specify the partial, so i'm getting nil there, because the p variable isn't matched, only pt (for 'part', in a multitimbral setup) is needed. it's the 'repaint' function that fails; it needs to have a kind of 'any partial', 'any p' argument. hopefully will figure something out for that tomorrow. basically it affects all 12 envelopes in a 4-partial Tone, (pitch, TVF, TVA) x4.

[subv0x]

nice! tbh i've always copied something i saw in a panel for the repaint :-)
interesting, what you do with 'pt'. so it can be L(mod:getName()) , and then it can be pt=pt:sub(-1) afterwards? redefined? (without naming a new variable)

btw: different question: what do you think: if the Sustain stage is disabled with 'Env Mode' = 1, is it just the sustain level that disappears, or should T3 go too? i edited the Pitch Envelope is the last example, but the TVF and YVA envelopes are as before. - getting in a muddle over this, looking at my graph draw coordinates; want to nail this and not have to look at it again ! :-P in fact, wouldn't mind adopting an easier way to display and handle these coordinates. this was also a crib (possibly dasFaker?) i know you've done some very nice graphs in your panels. (in fact i should check whether the D-110 has any exponential etc. curves etc. in its envelopes; but i'll ignore that for the time being in order to move along with this.)

[subv0x]

why (mod,value,source) ? it only needs mod doesn't it?

can you believe it's taken this long for it to sink in that i'm creating local variables in those brackets doh ... (if indeed that it what it is)

[subv0x]

your method also works for the individual repaints, as:
:-)

repaintTVF = function(mod,value,source)
	local pt = L(mod:getName())
	local p=pt:sub(-4,-4)
	pt=pt:sub(-1)

	panel:getComponent("uiTVFEnv_p"..p.."pt"..pt):repaint()
end

[dnaldoog]

... wouldn't mind adopting an easier way to display and handle these coordinates. ...

I found juce lineTo on Path easier to work with than g:drawLine() but it took me a long time to grasp how it works.

[subv0x]

ah, i mean the bit with the coordinates. this was nicked from something, and i fiddled with it, with half an understanding.
works but i find it tiring to look at and go through.
i'm sort of ready to look at it differently, maybe x,y in pairs, something like that, that can then live in nice tidy regular brackets, and vertical listings. starting probably with getting all those values in one operation

paintTVA = function(comp, g) --
    -- if panel:getRestoreState() or panel:getProgramState() then return end

    --	local NAME=L(comp:getOwner():getName())
    --	local p  = tonumber(string.sub(NAME,-4, -4))
    --	local pt = tonumber(string.sub(NAME,-1))

    --[[ new ]]-- 
    local pt = L(comp:getOwner():getName())
    local p = pt:sub(-4, -4)
    pt = pt:sub(-1)

    --name modulators
    local envMode = panel:getModulatorByName("envMode_pt" .. pt):getModulatorValue()
    local T1 = panel:getModulatorByName("tvaT1_p" .. p .. "pt" .. pt)
    local T2 = panel:getModulatorByName("tvaT2_p" .. p .. "pt" .. pt)
    local T3 = panel:getModulatorByName("tvaT3_p" .. p .. "pt" .. pt)
    local T4 = panel:getModulatorByName("tvaT4_p" .. p .. "pt" .. pt)
    local T5 = panel:getModulatorByName("tvaT5_p" .. p .. "pt" .. pt)
    local L1 = panel:getModulatorByName("tvaL1_p" .. p .. "pt" .. pt)
    local L2 = panel:getModulatorByName("tvaL2_p" .. p .. "pt" .. pt)
    local L3 = panel:getModulatorByName("tvaL3_p" .. p .. "pt" .. pt)
    local susL4 = panel:getModulatorByName("tvaSusL4_p" .. p .. "pt" .. pt)

    if envMode == 0 then
        --att/t1/A
        t1_x0 = 6
        t1_y0 = 40 -- start (x,y) coordinates
        --
        t1_x1 = 6 + T1:getModulatorValue() / 3 -- !changed/shorter
        t1_y1 = 40 - L1:getModulatorValue() / 2.7 --[[ line1 ]]
         --
        --dec1/t2/A
        t2_x0 = t1_x1
        t2_y0 = t1_y1
        --
        t2_x1 = t1_x1 + T2:getModulatorValue() / 3
        t2_y1 = 40 - L2:getModulatorValue() / 2.7 --[[ line2 ]]
         --
        --dec2/t3/A
        t3_x0 = t2_x1
        t3_y0 = t2_y1
        --
        t3_x1 = t2_x1 + T3:getModulatorValue() / 3
        t3_y1 = 40 - L3:getModulatorValue() / 2.7 --[[ line3 ]]
         --
        --t4/A
        t4_x0 = t3_x1
        t4_y0 = t3_y1
        --
        t4_x1 = t3_x1 + T4:getModulatorValue() / 3
        t4_y1 = 40 - susL4:getModulatorValue() / 2.7 --[[ line4 ]]
         --
        --susL/A
        sus_x0 = t4_x1
        sus_y0 = 40 - susL4:getModulatorValue() / 2.7
        --
        sus_x1 = t4_x1 + 25
        sus_y1 = 40 - susL4:getModulatorValue() / 2.7 --[[ line5/susL ]]
         --
        --rel/A
        t5_x0 = sus_x1
        t5_y0 = 40 - susL4:getModulatorValue() / 2.7
        --
        t5_x1 = sus_x1 + T5:getModulatorValue() / 3
        t5_y1 = 40 --[[ line6/T5 ]]
         --
         --

        --[[ fill envelope A/option ]] --g:setColour (Colour(0xFF264FB1))
        --for n = 2, 100, 1 do
        --	g:drawLine	(t1_x0, t1_y0 + n,  t1_x1, t1_y1 + n,2);
        --	g:drawLine	(t2_x0, t2_y0 + n,  t2_x1, t2_y1 + n,2);
        --	g:drawLine	(t3_x0, t3_y0 + n,  t3_x1, t3_y1 + n,2);
        --	g:drawLine	(t4_x0, t4_y0 + n,  t4_x1, t4_y1 + n,2);
        --	g:drawLine	(sus_x0,sus_y0 + n, sus_x1,sus_y1 + n,2);
        --	g:drawLine	(t5_x0, t5_y0 + n,  t5_x1, t5_y1 + n,2);
        --	end 	-- is there one line too many?see below also

        -- draw envelope/A
        g:setColour(Colour(0xFF00A2F9))
        g:drawLine(t1_x0, t1_y0, t1_x1, t1_y1, 1.5)
        g:drawLine(t2_x0, t2_y0, t2_x1, t2_y1, 1.5)
        g:drawLine(t3_x0, t3_y0, t3_x1, t3_y1, 1.5)
        g:drawLine(t4_x0, t4_y0, t4_x1, t4_y1, 1.5)
        g:drawLine(sus_x0, sus_y0, sus_x1, sus_y1, 1.5)
        g:drawLine(t5_x0, t5_y0, t5_x1, t5_y1, 1.5)

        susL4 = panel:getComponent("tvaSusL4_p" .. p .. "pt" .. pt):setProperty("componentVisibility", 1, false)
    elseif envMode == 1 then
        -- att/t1/B
        t1_x0 = 6
        t1_y0 = 40 -- start (x,y) coordinates
        --
        t1_x1 = 6 + T1:getModulatorValue() / 3
        t1_y1 = 40 - L1:getModulatorValue() / 2.7 --[[ line1 ]]
         --
        -- dec1/t2/B
        t2_x0 = t1_x1
        t2_y0 = t1_y1
        --
        t2_x1 = t1_x1 + T2:getModulatorValue() / 3
        t2_y1 = 40 - L2:getModulatorValue() / 2.7 --[[ line2 ]]
         --
        -- dec2/t3/B
        t3_x0 = t2_x1
        t3_y0 = t2_y1
        --
        t3_x1 = t2_x1 + T3:getModulatorValue() / 3
        t3_y1 = 40 - L3:getModulatorValue() / 2.7 --[[ line3 ]]
         --
        -- t4/B
        t4_x0 = t3_x1
        t4_y0 = t3_y1
        --
        t4_x1 = t3_x1 + T4:getModulatorValue() / 3
        t4_y1 = 40 - susL4:getModulatorValue() / 2.7 --[[ line4 ]]
         --
        -- susL/B
        sus_x0 = t4_x1
        sus_y0 = 40 - susL4:getModulatorValue() / 2.7
        --
        sus_x1 = t4_x1 -- !!changed + 50
        sus_y1 = 40 - susL4:getModulatorValue() / 2.7 --[[ line5/susL ]]
         --
        -- rel/B
        t5_x0 = sus_x1
        t5_y0 = 40 - susL4:getModulatorValue() / 2.7
        --
        t5_x1 = sus_x1 + T5:getModulatorValue() / 3
        t5_y1 = 40 --[[ line6/T5 ]]
         --

        -- fill envelope/B
        g:setColour(Colour(0xFF264FB1))
        for n = 2, 100, 1 do
            g:drawLine(t1_x0, t1_y0 + n, t1_x1, t1_y1 + n, 2)
            g:drawLine(t2_x0, t2_y0 + n, t2_x1, t2_y1 + n, 2)
            g:drawLine(t3_x0, t3_y0 + n, t3_x1, t3_y1 + n, 2)
            g:drawLine(t4_x0, t4_y0 + n, t4_x1, t4_y1 + n, 2)
            -- g:drawLine	(sus_x0,sus_y0 + n, sus_x1,sus_y1 + n,2);
            g:drawLine(t5_x0, t5_y0 + n, t5_x1, t5_y1 + n, 2)
        end -- is there one line too many?see below also

        -- draw envelope/B
        g:setColour(Colour(0xE107FF00))
        g:drawLine(t1_x0, t1_y0, t1_x1, t1_y1, 1.5)
        g:drawLine(t2_x0, t2_y0, t2_x1, t2_y1, 1.5)
        g:drawLine(t3_x0, t3_y0, t3_x1, t3_y1, 1.5)
        g:drawLine(t4_x0, t4_y0, t4_x1, t4_y1, 1.5)
        -- g:drawLine	(sus_x0,sus_y0,sus_x1,sus_y1,1);
        g:drawLine(t5_x0, t5_y0, t5_x1, t5_y1, 1.5)

        susL4 = panel:getComponent("tvaSusL4_p" .. p .. "pt" .. pt):setProperty("componentVisibility", 0, false)
    end
end

the D-110 has this 'env mode' parameter, which switches off the sustain stage - so it goes straight to release after the decay stage - except the D-series envelopes have 2 decay stages; T2/L2 and T3/L3. T4 is ... sustain stage - so i call that 'susL4', and T5 is the release stage

• i guess CustomIndex, where every parameter has a number/index to invoke it with ... pretty regular way to approach it, IF you could keep the same numbers as in the sysex parameter list, ideally.
  my sole use of that so far was just to arbitrarily attribute index number for envelopes, choosing the most convenient ones available.

ok so then, once you've created global variables for all your parameters with panel Initialise, and each one is mapped to the correct hex value, and hex byte, you can SET customIndex number automatically with a deft iteration, setProperty, etc. and save doing it all manually, for over 2000 parameters...

[dnaldoog]

why (mod,value,source) ? it only needs mod doesn't it?

can you believe it's taken this long for it to sink in that i'm creating local variables in those brackets doh ... (if indeed that it what it is)

Those brackets contain parameters that are passed to the function, so yes once used in the function I guess they are local to the function; but mod can be modified by the function e.g mod:setProperty() etc so I guess it's something more like a reference passed to a C++ method. value is actually part of mod userdata so mod:getModulatorValue() is equivalent to value.

[dnaldoog]

btw: different question: what do you think: if the Sustain stage is disabled with 'Env Mode' = 1, is it just the sustain level that disappears, or should T3 go too? i edited the Pitch Envelope is the last example, but the TVF and YVA envelopes are as before. ...

I don't know about that. I think in the JD-990 there is no such functionality of disabling Sustain