Since the JSynthLib based MBFM Editor, which I created many years ago, even doesn’t run on my own computer anymore, I started a new one which is based on Ctrlr
The early beta version after I learned how Ctrlr handles the dataflows:
A complete implementation with access to all parameters is feasible, especially since Ctrlr supports LUA as a scripting language.
Example: following code handles the OPx flags, which are located in a single parameter at different bit positions:
OP1Flags = function(modulator, newValue)
op = "OP1"
flagSustain = panel:getModulatorByName(op .. "SustainFlag")
flagVibrato = panel:getModulatorByName(op .. "VibratoFlag")
flagTremolo = panel:getModulatorByName(op .. "TremoloFlag")
if flagSustain ~= nil and flagTremolo ~= nil and flagVibrato ~= nil then
value = 0
value = value + 2 * flagSustain:getModulatorValue()
value = value + 4 * flagVibrato:getModulatorValue()
value = value + 8 * flagTremolo:getModulatorValue()
sat = panel:getModulatorByName(op .. "FlagsSatellite")
if sat ~= nil then
notify_vst_host = false
notify_midi_device = true
notify_component = true
sat:setModulatorValue(value, notify_vst_host, notify_midi_device, notify_component)
end
end
end
At the end scripting the combined parameters is much less effort than writing the whole application by myself!
Especially since we will inherit all these nice Ctrlr features such as Windows/Mac/Linux compatibility, support for VST, AU and Standalone mode, etc.
The GUI design is very simple, because I’m not good at graphics.
Is anybody interested on helping with the graphics? See following page for inspirations: http://www.ctrlr.org/page.php?p=ddb
w00! Start to something awesome TK! Ctrlr is a pretty good framework from what I understand. There is a panel for the Virus B that might work with my Virus Classic I have been meaning to try. There was definitely a need for updated MBFM software though. I was getting surprisingly good with sammichFM interface though
At least with the MBSID it’s more functional and compatible. I haven’t had too many issues with it once you get used to the quirks. Of course, it doesn’t work in tandem with a DAW which is annoying (in fact, I have to close out my DAW to use it as they both try to gain exclusive access to the MIDI port).
Java itself works just fine on OS X. Minecraft is a Java application, after all. The problem is that some libraries were removed from Snow Leopard that implement MIDI support. You have to now install these separately from Mandolane. They do point out it is no longer required for Lion so perhaps these added MIDI support back in? I haven’t tried Java on MIDI in Lion yet actually.
With Ctrlr, I got as far as scripting the switches in LUA and then had to focus on exams etc. I will certainly try it out this weekend when I’m in the studio and report back with any findings
Rotaries: circular mousemovment doesn’t make fun, please change it to vertical. A simple up and down movement feels more native for use with a mouse.
ok, changed this.
I’m normally using the mouse wheel which is much more ergonomic, therefore it doesn’t make a difference for my own workflow.
Rotaries with values between -64 and 63 sometimes won’t go lower than zero
This is fixed in Ctrlr version r965, but unfortunately this one has another issue with Lua scripting.
As Roman wrote in the Ctrlr forum, he will fix this soon.
Waveselect and Algo.select: Change it also to vertical mouse responsiveness. It feels simply better.
Changed
I was just saying on another forum the other day someone should do a CTRLR-based editor for the MIDIbox/SammichFM. And here it is!
It was on my agenda since many months… I was just unsure if I should program it in Juce directly, or take the Ctrlr project instead.
I think that Ctrlr is the right route here, because it allows interested people to improve or customize a panel without programming knowledge.
Now where I know how fast a panel can be created, the next step will be a fully featured editor for MBSID V2 including all tricks, such as multi-oscillator modifications, automatic switching of the panel layer depending on SID engine, etc.
I will also create an editor for MBCV V2 - the firmware is running pretty stable, has great features (most recent one: a patch change mechanism which can be synchronized to the MIDI clock with selectable resolution!) but currently only a Lemur editor is available, which makes the project useless for most people.
Now where I know how fast a panel can be created, the next step will be a fully featured editor for MBSID V2 including all tricks, such as multi-oscillator modifications, automatic switching of the panel layer depending on SID engine, etc.
TK, firstly I want to say thanks a lot for the Ctrlr editor for MBFM, I’ve been using it a lot over the last week and it really does help to integrate the synth into my DAW
But unfortunately I seem to have a problem editing the drums. I’m using Ctrlr 965 on Mac OS X (10.6.8) and I tried both as a VSTi inside of Cubase Artist 6 and standalone. I click the drum page button on the left of the Ctrlr Editor and the drum controls show up. But nothing makes any difference to the synth (the normal Inst1 page is working fine to edit a normal instrument though).
I checked the MIDI which is being sent out and I noticed that the <type> byte is different between the InsX pages and the drums page.
This is what I see in the Ctrlr MIDI monitor when I move a control on the inst page:
f0 00 00 7e 49 01 06 08 00 14 01 f7
This is what is sent from moving a control on the drum page:
f0 00 00 7e 49 01 06 18 00 10 04 f7
Is the 18 at the 8th position correct?
Does anyone else have the drum page working?
Also, I noticed that when I use Ctrlr as a VST, the Ins1 to 4 and drum buttons open up the correct pages. But in the standalone those buttons don’t make a change! Maybe it is a Ctrlr bug, but I thought I’d mention it here as well…
