Roland MC303 Mark1 Panel PoC

[unityconstruct]

Roland MC303 Mark1 Panel

• This was my second synth behind the Alesis QS6, shagged one for cheap out of nostalgia.
• Started hacking out a panel for it since I couldn't find one.
• Skinning will be LAST, so mods/layout is total ClusterF

General Support

• Most System Sysex Params Supported (ie: FX Params)
• Most 'Synth' Sysex Params Supported
  • Controller Sysex Params work, but disabled as they work off 'Variable Part Selection' and just assume add dedicated screens, so param updates are legit
• No Drum sysex support yet
• Patch/Tone Selection supported
• CC/NRPN controllers page - they operate on the currently selected Part
• Dump Request Proof of Concept for System Params 1
  • No inbound dump response support yet
• GetParam Support
  • Pulls params from Device for each Part so mods match device before tweaking.
• Using Lua OO Concepts, but need to aggregate instantiation under DeviceManager (aka DM) to theoretically prevent unnecessary recourse usage as well as make design intuitive via dot syntax intellisense lookups
• Other stuff I can't remember

VSTi woes

• Export to EXE worked like a champ
• Just tried exporting > VST HOST > CtrlrX > export > DLL.
• Not clear if VSTi export is as trivial as the EXE, or if there are nuances to it, but was unable to find much around that process.
• Soliciting assistance on this if anyone know WTF on the topic

MC303_1_0_mark1_2024-08-07_00-20.zip

[damiensellier]

The exporting instance process is the same for the exe or the VST.
It just duplicates Ctrlr as an app, and embed the resources and panel xml in the header of the new exe. To specify it's a single instance containing a panel and resource, there's a property at the top level valueTree that is changed too. Nothing more.

Your panel is really nice, it seems you put everything you could to control each and every parameters available. Good job!
I remember borrowing a MC303 to a friend in the early 2000s and it was so much more than a tb303 you can program songs with it. Not sure about the sounds if they are still relevant in 2024 but if you want to get this 90s trance/electronic revival vibe, this is a good tool.

[unityconstruct]

The exporting instance process is the same for the exe or the VST.

@damiensellier THANKS for info on that!

• I'm starting to suspect Lua OO might be the culprit, so will do some mock projects & see.
• On the bright side, there's no witchcraft with exporting the VST, so that's some silver lining.

Thanks again for the info brother!
~uc

TDLTR;

• My approach with my EMU C-Station & this MC303 departs from the normal design patterns of:

somethingcool = function(mod, value)
end

• and instead uses

function SomethingCool(mod,value)
end

• I left all methods Ctrlr calls as the former pattern, but then immediately have those functions call into my framework.
  • the idea behind this is reusable components, which allowed me to port 50%+ of my EMU classes to this project, leaving only the device-specific 'application-logic' to tackle.
• I'm also using extensive use of 'annotations' ---@type, ---@param, ---@returns as this allows VSCode's Lua Language Server to help with typing, 'compile' errors, etc.
• I suspect the Ctrlr Native environment differs from that of the VSTi export environment, with the EXE export benefiting from all the Native C++ stuff ( itself being nearly identical to Ctrlr.exe build ).
  • Would be curious if anyone can load Ctrlr VSTi and load/export this panel to a viable DLL.
  • It MIGHT be my host, but I have a gorillion ancient, ghetto, crap-tastic VST's ranging from the Radium '96 dayz to present day, so would anticipate if my host can consume these bastardized things, it should be able to consume anything legit.
  • I'm leaning on circular refs somewhere that Ctrlr.exe handles, that the DLL does, but its only a guess.
  • If not that, my second guess is making use of a monolithic GET = {} table that stores most everything from param lookups to ENUMs to state vars and it might be choking things somewhere.
    • GET = {} is 1.2K lines
    • PARAMS = {} is 2K lines
  • My EMU has 2K+ params, if not double, & is HUGE, so was assuming that was the root cause, but this project is microscopic compared to that & while my VST host isn't munching literally 16GB RAM in 15s when scanning the DLL, it errors out after about 10s without resource spikes.
  • Both the EXE export & the Ctrlr.dll VSTi run uber-nice.
  • Will update with findings

Ctrlr => OO Design Pattern

--
-- Called when a panel receives a midi message (does not need to match any modulator mask)
-- @midi   CtrlrMidiMessage object
--
ListenerMidiRx = function(--[[ CtrlrMidiMessage --]] midi)
    local midiHexString = midi:getData():toHexString(1)
    if (midiHexString == nil) then return end
    p(string.format("MIDI RX:[%s]",tostring(midiHexString)))
    -- immediately call into framework once I get what I need from the Ctrlr environment
    -- this allows me to test 90% of back-end code without Ctrlr even running
    CtrlrHandler.MidiIn(midiHexString)
end

Example Lua OO with LuaDoc annotations

[unityconstruct]

FYI: Successfully exported test panel with one Lua OO Class & 2 Ctrlr Native function calls that invoke it.

• So looks like self-inflicted harm.
• Will refactor this MC303 panel as I have some intuition as to what might be going on.

--
-- Called when a modulator value changes
-- @mod   http://ctrlr.org/api/class_ctrlr_modulator.html
-- @value    new numeric value of the modulator
--
sliderOnValueChange = function(--[[ CtrlrModulator --]] mod, --[[ number --]] value, --[[ number --]] source)
    console(string.format("VALUE: [%s]",tostring(value)))
    CommonFunc("sliderOnValueChange",tostring(value))
end

-- Called when a modulator value changes
-- @mod   http://ctrlr.org/api/class_ctrlr_modulator.html
-- @value    new numeric value of the modulator
--
buttonOnValueChange = function(--[[ CtrlrModulator --]] mod, --[[ number --]] value, --[[ number --]] source)
    console(string.format("VALUE: [%s]",tostring(value)))
    CommonFunc("buttonOnValueChange",tostring(value))
end


---@class CommonFunc
CommonFunc={}

---@param modname string
-- -@param mod CtrlrModulator
---@param value number
function CommonFunc(modname, value)
	if((modname==nil) or (value==nil)) then return end
    
    console(string.format("CommonFunc: [%s][%s]",tostring(modname),tostring(value)))
end

lua-oo-test.zip