Linked Modulators

[subv0x]

wondering how to handle Linked Modulators, in terms of hooking up with a single incoming and outgoing parameter value.
should i just consider them as one (and ? name accordingly?), and only address one of them with incoming values?
here's a little panel to illustrate. modulators are linked in Ctrlr properties, using 'modulatorValue' as common property.

this is Roland D-series btw
i built it this way because i couldn't think of another way to handle the list mismatch for synth waveform/PCM bank (see notes in panel below). the other linked pair are the two lists corresponding to the selection when PCM bank is selected (...with the other linked pair).

this functions ok in the UI, but needs to respond to incoming values, and produce a single value (per pair) in the parameter values.

Linked Modulators_1_0_start_2023-11-02_06-49.zip

[fbit-itc]

generally speaking:
mods have to be named differently. only one mod has to be an 'active receiver' (either by defining the midi-message in the mod itself or triggering it by lua).
Be careful though when linking mods "bidirectionally": in link mode, the sending mod sends the assigned (!) modulatorValues: example: uiButtonContent is defined as "pcm1=99 , pcm2=65, pcm3=45, ... ,pcm100=66" , so the mod sends 99, 65, 45,... - BUT the receiving mod interprets them as "core modvalue": receiving '99' triggers the content-entry at place "99" (in the example pcm100 : 99+ '0'-entry = 100), then this modulator itself resends the assigned value of pcm100 - '66' - back to the 1st modulator, 1st mod will resend the value of 'pcm67'... ad infinity - a classical endless-loop : ctrlr will freeze.
So linking 2 mods bidirectonally works if both modulator use simple (strictly ordered) 0...127. If not you can add a link only in one direction but must use lua for the inverse link

[subv0x]

thanks.
so far, in just the panel - haven't tried sending or receiving MIDI - the linked modulators have been doing as expected. in fact i've messed something up now, and have to check everything, because it's behaving weirdly. i think if i decide one of them is 'master', re: midi-sending/receiving - as per the manual parameter list anyway, and don't let the other send or receive anything, - act as an auxiliary - i might get away with it. in any case linked modulators are there for something; this is a pretty good case: where i need 2 UIs for the same parameter, dependent on another parameter's setting. if you look at the D-110 'structure', and the combinations, it will give an idea (D-50 is maybe the same). or else i think of another way of representing it. but i quite like what i have atm.

[fbit-itc]

right, should be 'master': if you set the midi property on both mods, the midi msg will be send twice (it's not a real fault, but it's unnecessary).
One task I use linked mods to increase "comfort" is: a panel has a dropdown list (uiCombo) of 360 pcm waves (Roland VA synth of JP80, Integra etc). Now searching pcms in a 360 entry dropdown is a pain in the aiaiai. One can place a +/- (increase/decrease) uiSlider right next to the Combo-mod and link both: the slider allows to scroll through the list via
mouse click or wheel - so one can quickly scroll through all the pcms (loading them to the synth) to find a wave one likes (without each time open the listbox, selecting a wave, closing, open the listbox, select the next pcm etc)

[fbit-itc]

thus said: the 'infinit loop' problem is independend from 'master-slave': you can try the above mentioned example (pcm1=99, pcm2=65) etc: if the "value" differs from the "position" of the entry, bidirectional linking does not work : a button or slider has at least two 'values': one is the 'component value' that corresponds to the position of the entity in the content box, the other is an eventually assigned 'modulator value' - "pcm1=99" in a uiCombo (or fixedSlider) placed at first position has the component value 0 (pcm2 in 2nd position has comp.value 1, pcm3 value 2 etc) and the modulator value 99 : a linked modulator sends the modulator value 99 but interprets a received value as component value : the receiving mod will capture 99 and switch to position 100 (=99+1 - because you start counting positions from 0) - which is pcm100 - so selecting pcm1 in slider A will select pcm100 in the linked slider B (and, if B is directly re-linked to A it will re-send the modulator value of pcm100 back to A - da capo al freeze )
Thus said - the impression is (maybe wrong) that you just have started programming ctrlr - so the 'link' issues will only appear once you dig deeper and do more complex things.

[subv0x]

i don't think i have any infinite loop problem at this stage ( lol though dnaldoog may beg to differ on that re:m this panel ! )
the linked modulators in my projet have a very 'mechanical' role of, in case 1, offering a substitute view depending on whether the waveform source is VA or PCM, the latter allowing access to case 2, where you select on of 2 PCM lists, which need to be synced so that you end up with the same number list item, whether you select list1 or list2.

in each case, both modulators refer to a single parameter on the device.
i think if i make the 'slave' modulator 'silent' re: midi message handling, it should be ok.

this is part of a more complex section of the UI, with 4 waveforms, arranged in 2 pairs, each going into a simple algorithm called 'Structure' (Roland D-series LA synthesis), with on/off buttons that make each Partial line visible or not. i'm about to post a demo panel of that section in the D-110 Again thread, trying to resolve a couple of remaining issues.

[subv0x]

ok i've posted a mini panel (that helped me resolve something else), and it has not manifested the problem i was having. now i've posted the current panel-in-progress, which DOES have the 'bug'. and i've identified what's happening by getting it to print to console. cannot, however identify yet why it is happening. ... very odd, i've check everything, and it's the same method running, same names. i'm considering removing all the links and doing them again, might be best.

link to file post is here, and go up a post or two for the mini-panel:
(D110 thread)
#564 (comment)

what is happening appears to be that if i change the first combo, no problem, it prints that combo name. but now if i go to combo 4 and move that, it prints combo 4 but also combo 1, which is changing in the UI, following last changed combo, which is all wrong, not supposed to be linked. and it's the same with combo 2 and 3: they always change combo 1 as well.

eg: there are 4 combos here, and in the other view there are another 4 combos, so it's linked like that, across 2 views/tabs.

[subv0x]

i'm having the same problem again with 'modulatorValue' not showing in the list of available properties to link to. can't figure out what it is, but i think if i try again and again, at some point, by fluke or some other cause, it will show again in the list, as it has done before. this is weird buggy Ctrlr behaviour i think. unless anyone can explain how to 'unlock' this, if i have a wrong setting somewhere (i don't think so, think it is as described, and randon behaviour by Ctrlr).

btw: i un-linked all of those modulators, in order to link them up again.

[dnaldoog]

You can avoid infinite loops when linking two uiCombos by accessing JUCE ComboBox . This way you don't have to mess with linking modulators from the panel. You simply update the setSelectedId in the 'other' combo and MIDI is not sent via Ctrlr and more importantly the sending combo is not retriggered creating an infinite loop.

Also I don't think uiCombo reacts to source which is otherwise a good way to block infinites loops with objects like uiSlider etc.
e.g. if source ~=4 then return end ‒ From Memory I don't think it works with uiCombo.

changePartner = function(--[[ CtrlrModulator --]] mod --[[ number --]], value --[[ number --]], source)
    local name = L(mod:getName())
    local t = {B1 = "A1", A1 = "B1"}
    --panel:getModulatorByName(t[name]):setModulatorValue(value,false,false,false) -- will create infinite
    -- loop and crash ctrlr when trying to sync two or more combos  so
    -- we will make the values match by accessing the JUCE object ComboBox
    --https://docs.juce.com/master/classComboBox.html
    local c = panel:getComboComponent(t[name])
    if c ~= nil then
        local otherCombo = c:getOwnedComboBox()
        otherCombo:setSelectedId(value + 1, 0)
    end
end

---

COMBO BOX JUCE.zip

[subv0x]

my panel doesn't show signs of an infinite loop (that i'm aware of).
i just have this weird bug - which i'll hopefully get to the root of - where combo1 is affected by combos 2,3,4.

the other issue, which i think is a Ctrlr bug, is not being able to access 'modulatorValue' as a link property, because sometimes it just doesn't appear on this list. - and can then inexplicably re-appear again.

[dnaldoog]

Try deleting those combos and recreating. I’ve had issues like that before. Also if you delete uiGroup, then uiSlider, uiCombo etc will still exist hidden in your panel so find them and delete them. If those hidden modulators have the same name as the ones creating the problem, that could very possibly be the source of the problem.

…

On Tue, Dec 5, 2023 at 2:48 subv0x ***@***.***> wrote: my panel doesn't show signs of an infinite loop (that i'm aware of). i just have this weird bug - which i'll hopefully get to the root of - where combo1 is affected by combos 2,3,4. the other issue, which i think is a Ctrlr bug, is not being able to access 'modulatorValue' as a link property, because sometimes it just doesn't appear on this list. - and can then inexplicably re-appear again. — Reply to this email directly, view it on GitHub <#574 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASKFXQ62EHUJ73OVFQDJBY3YHYEGRAVCNFSM6AAAAAA62ML7VWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONJVHE4TM> . You are receiving this because you commented.Message ID: ***@***.***>

[subv0x]

yup might well have to do that. now that i know how to autonumber all those VST index and custom index, it isn't an issue :-)
i can rebuild this bit and re-import it. also easier to focus on the other issue, changing colour properties for the 'level' sliders (i'll upload that later in the D110 thread - mainly to illustrate the bug, see if it can be identified -

it definitely isn't happening in the mini-panel i posted (so there's hope .. )

and yeah, deleted groups leaving children behind, - i have tight control of this Modulator List.

i'm wondering if - as these modulators are by now 'ancient' LOL and date back probably to the beginning of the project, they/one of them may have picked up an unwanted extra property or something. i've done that, doing property operations, and addressing the wrong modulator/component element, ending up with the extra entry ( we've talked about this ).

ok i'll rebuild this separately.