Ctrlr based Editor for MBFM

TK. · March 25, 2012

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:

/Update: The panel can be downloaded from this location: http://ctrlr.org/midibox-fm-v1/

Ctrlr can be downloaded from http://ctrlr.org/nightly/

I tested this with Ctrlr_262f2710.dmg (version from 14. April 2014) under MacOS

For Windows take Ctrlr_ac6a3185.exe

/Update2: Drum edit panel:

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

Best Regards, Thorsten.

m00dawg · March 25, 2012

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 :)

Flemming · March 26, 2012

Very, very nice :) The jsynthlib version was a bit 'weird' to work with here, so i look forward to play with this Ctrlr-based editor!!

Now, i really hope that someone would do the same for MBSID. I would give it a try, but i'm positive that i wouldn't get very far :) not smrt enough!

m00dawg · March 26, 2012

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).

Davo · March 26, 2012

Why doesn't Java doesn't work on MacOS anymore?

TK. · March 26, 2012

Creating a MBSID panel will be a bit more effort, but it's doable! :)

At the top of this thread you will see the current state: all instrument parameters are editable! :)

Next step is to learn how to create a separate view for drums and wavetables.

Best Regards, Thorsten.

m00dawg · March 27, 2012

Why doesn't Java doesn't work on MacOS anymore?

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.

monokinetic · March 27, 2012

Wow TK that's brilliant!

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 :)

TK. · March 27, 2012

A beta release is now available for download: http://www.ctrlr.org/page.php?p=ddb

Currently I only tested it under MacOS

All parameters except for Drums and Wavetables can be edited.

Best Regards, Thorsten.

TK. · March 28, 2012

Update: Drums can now be edited as well:

The URL to the release package is identical:

-> http://www.ucapps.de/midibox_fm/midibox_fm_ctrlr_panel.zip

Best Regards, Thorsten.

Thomasch · March 28, 2012

...and it grows up...

Thanx Thorsten!

Thomasch · March 29, 2012

Just a short feedback, tested within Ableton Live with the AU and VST plugin:

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.
Rotaries with values between -64 and 63 sometimes won't go lower than zero
Waveselect and Algo.select: Change it also to vertical mouse responsiveness. It feels simply better.

As i told in the other thread, i can't test the plugin with the MBFM hardware, because it isn't finished yet.

Regards

Bunc

Edited March 29, 2012 by Thomasch

toneburst · March 29, 2012

Great work Thorsten!

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!

a|x

TK. · March 29, 2012

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.

Back to topic: here a link to V1.0 of the panel: http://www.ctrlr.org/page.php?p=ddb

I will ask Roman to add this to the Ctrl device database, so that it can be directly downloaded from the Ctrlr app

done

Best Regards, Thorsten.

arnoid · March 30, 2012

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. :)
Best Regards, Thorsten.

Can't wait :)

Flemming · March 30, 2012

Can't wait :)

+1

TK. · April 2, 2012

Please note that due to a bug the current "nightly build" release of Ctrlr doesn't execute Lua scripts anymore.

Since it can take some days until a new version is available, I provide a copy of a known good one:

Mac: http://www.ucapps.de/tmp/Ctrlr_r946.dmg

Has anybody downloaded the WIndows binary r945 last week?

Best Regards, Thorsten.

igi · April 5, 2012

Hi!

Great, but I have some problem again.

When I receive patch from MBFM then operator waveforms and patch name is not displayed on editor.

I also cant't change patch name from editor.

Everything else works fine.

I'm using winXP, and Windows stable version Revision: 934.

Best regards, IGI

TK. · April 5, 2012

Thanks for the hint!

I uploaded v1.2 to the DDB: OP waveform and patch name are updated.

Currently a changed patch name won't be sent back to MBFM due to this issue

Best Regards, Thorsten.

monokinetic · May 17, 2012

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....

David

Edited May 17, 2012 by monokinetic

TK. · May 18, 2012

The SysEx command is correct, see also the documentation: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_fm_v1%2Fdoc%2Fmidibox_fm_sysex_implementation.txt



Type definitions

~~~~~~~~~~~~~~~~


   00: Voice #1, EEPROM access (exception: command #06 always accesses RAM)

   01: Voice #2, EEPROM access (exception: command #06 always accesses RAM)

   02: Voice #3, EEPROM access (exception: command #06 always accesses RAM)

   03: Voice #4, EEPROM access (exception: command #06 always accesses RAM)

   08: Voice #1, direct RAM access

   09: Voice #2, direct RAM access

   0A: Voice #3, direct RAM access

   0B: Voice #4, direct RAM access


   10: Drums, EEPROM access

   18: Drums, direct RAM access


   70: Ensemble, EEPROM access

   78: Ensemble, direct RAM access

[/code]


 I'm using Ctrlr 965 on Mac OS X (10.6.8) 


This is the actual issue - please use r946, you will find the link in the first posting!


Best Regards, Thorsten.

Thomasch · May 19, 2012

I tried to understand how ctrlr works.

For that reason i tried to swap 2 of the Encoder.

Tried with OP1 Attack and OP2 Attack. Adress is 20h and 21h.

In the rightside Edit Pane i swapped the hex values. (OP1 Attack = 21h, OP2 Attack = 20h)

this works well while sending to the MBFM.

But it doesn't works the other way, when i press the recieve button.

Where do i have to change something for recieving purpose?

P.S.:

A send all button would be cool

Edited May 19, 2012 by Thomasch

TK. · May 19, 2012

Open the Lua source code viewer, select the "receiveMIDI" tab.

It shows you a program that I wrote to map incoming SysEx data to the controllers.

This part is relevant for the Attack controllers:



        	assignModulator(mem_block:getByte(0x20), "OP1Attack")

        	assignModulator(mem_block:getByte(0x21), "OP2Attack")

[/code]


as you can see (when you read & (!) understand the code a little bit more), the controller name is relevant.


So: your experiment will work if you change the controller names in these function calls as well.


Best Regards, Thorsten.

Thomasch · May 19, 2012

Open the Lua source code viewer, select the "receiveMIDI" tab.
It shows you a program that I wrote to map incoming SysEx data to the controllers.

This part is relevant for the Attack controllers:
        	assignModulator(mem_block:getByte(0x20), "OP1Attack")

        	assignModulator(mem_block:getByte(0x21), "OP2Attack")
as you can see (when you read & (!) understand the code a little bit more), the controller name is relevant.

So: your experiment will work if you change the controller names in these function calls as well.

Best Regards, Thorsten.

Really?

In my understanding i have to change the (0x20) to (0x21), the (0x21) to (0x22) and so on if i want to shift all CC after CC32.

TK. · May 19, 2012

Junge, wir verstehen uns einfach nicht... ;-)

Best Regards, Thorsten.

Sign In

Ctrlr based Editor for MBFM

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation