TK.

Ctrlr based Editor for MBFM

42 posts in this topic

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:

mbfm_ctrlr_panel_proto2.png

/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:
mbfm_ctrlr_panel_proto3.png


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! smile.gif
Especially since we will inherit all these nice Ctrlr features such as Windows/Mac/Linux compatibility, support for VST, AU and Standalone mode, etc. smile.gif

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  1. 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.
  2. Rotaries with values between -64 and 63 sometimes won't go lower than zero
  3. 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 by Thomasch

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

    Share this post


    Link to post
    Share on other sites

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

    Share this post


    Link to post
    Share on other sites

    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.

    Share this post


    Link to post
    Share on other sites

    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

    Share this post


    Link to post
    Share on other sites

    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.

    Share this post


    Link to post
    Share on other sites

    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 by monokinetic

    Share this post


    Link to post
    Share on other sites

    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.

    Share this post


    Link to post
    Share on other sites

    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 by Thomasch

    Share this post


    Link to post
    Share on other sites

    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.

    Share this post


    Link to post
    Share on other sites

    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.

    Share this post


    Link to post
    Share on other sites

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

    Best Regards, Thorsten.

    Share this post


    Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!


    Register a new account

    Sign in

    Already have an account? Sign in here.


    Sign In Now