Jump to content

MIDIbox FM V2.0 on LPC17


Sauraen
 Share

Recommended Posts

AFAIK there is no sequencer in FM 1.4.  Never found it, the manual doesn't mention it.

Then what is the demo sample from http://ucapps.de/midibox_fm.html labeled "The 16 MIDIbox FM drumset presets"? I guess "drumset preset" isn't the same thing as "drum sequence preset", maybe they're done with an external sequencer. Well anyway, MIDIbox SID contains a small internal sequencer, so why not!

Link to comment
Share on other sites

  • 2 weeks later...
YES! The only thing I can add is, please make the stereo mixing midi controlled.

If when you say stereo mixing, you mean the assigning of each pair of operators to output channels 1,2,3,4, then yes, I plan to have that parameter, like every other OPL3 parameter, MIDI-controllable via CCs.

 

I'm thinking something like this: CC 10, Pan position, will switch channels 1 and 2 to emulate a panpot (i.e. 0-31 only channel 1, 32-95 channels 1 and 2, 96-127 only channel 2), and then some other CC (27 or something) will have its most significant three bits DISABLE channel 4, channel 3, and whatever-CC-10-says-channels-1-and-2-are-doing (so the default value of 0 has everything enabled). This way you can just twiddle the pan knob in your DAW to move channels around that are standard, outputting only to channels 1 and 2; and you can send that other CC to set up the channel in detail if you want something different.

 

I would love to see that with the AOUT modification.

I also kind of want AOUT support, so I can build a digitally controlled filter; but that'll be a later feature. I'm thinking 8 global modulation destinations corresponding to the 8 AOUT channels; a menu option to put them temporarily on the display as the 8 softkeys; and then you assign modulators to them like you would OPL3 parameters.

 

YES! This will make Adlib tracker 2 obsolete to me.

Does Adlib Tracker 2 support two OPL3s? :P

Link to comment
Share on other sites

  • 2 weeks later...

Here's some pictures of my OPL3 modules:

 

med_gallery_10357_214_610623.jpg

 

med_gallery_10357_214_598684.jpg

 

med_gallery_10357_214_1067909.jpg

 

If you're only building one OPL3 module, no modifications are necessary. If you want to build two, and you want them to be stacked like this, this is what I did:

  • The CS/WR pin on each OPL3 has to be independent (not connected between the boards, you can see it very well sticking out on the first picture). This is so that the core can send different data to each chip (obviously)! All the other digital data and power supply pins are connected together for the two boards.
  • If you want the outputs to mix (channel 1 of each mixes, channel 2, etc.), change R17/R19/R21/R23 to 10k and R16/R18/R20/R22 to 100k, and connect the outputs together (1 to 1, 2 to 2, etc., like all the digital pins). Then make a circuit on veroboard with an op-amp for each channel (you can use one more TL074 to cover all four), in inverting amplifier configuration with a 10k feedback resistor (for unity gain mixing). After that put a final AC coupling capacitor (10 uF electrolytic or non-polar), bias resistor to ground (10k), and series current limiting resistor (220 ohms) to the output jack.
Edited by Sauraen
Link to comment
Share on other sites

*begins chanting for a demosong* :smile:

Really though that looks rather fantastic!

Thanks! Demosong is not going to happen for a while, though. Finished OPL3 boards does not mean finished anything else (in this case, only also finished core board and power supply)! I'm waiting on some encoders from ebay to arrive from Asia, and I have a friend with a CNC machine who's willing to mill me a front panel and the circuit board for it. Hopefully when they come, the front panel will be all together in only a couple weeks!

 

I don't know if anyone else here is on the east coast of the US, but I'm going to MAGfest and hope to have a version of this build to bring with me that's sufficiently working for me to jam with it. So that's sort of a deadline for this project.

Edited by Sauraen
Link to comment
Share on other sites

  • 3 weeks later...
wow...nice switchcaps...is it silicone? Where did you got them or how do you make them????

 

The buttons and LED pipes are custom 3D printed (whole order including shipping cost $20, the maker was avdwege2003_ebay@yahoo.com). I made the designs in Blender and exported them for printing as stl. They are pushing on standard 5mm tact switches. I had to dremel out a depression in the bottom of each button that had an LED, so the LED wouldn't hold the button cap against the front panel and keep it from being pressed.

 

P.S.: very nice project!!!

Thanks! :D

Link to comment
Share on other sites

Finally squished a couple of bugs (one in the vanilla MIDIbox NG, one in my modifications) and got the LED matrix working. You can see what the FM Widget is supposed to look like now (the colors are more obvious in person, red is modulator, green is carrier, blue is signal path, red on top is feedback). The voice "nodes" turn off when muted (though not when the volume is set to 0).

 

gallery_10357_214_829971.jpg

Link to comment
Share on other sites

Here's your demosong, m00dawg!

 

 

One take, 32 voices allocated. I could have done it in half the number of voices if I had been willing to let the release trails of notes get cut off for other notes to replace them, but since I have two OPL3s, why not!

 

The following features of MIDIbox FM V2.0 are being used in this video:

  • Support for two OPL3 modules and up to 36 2-op voices or 12 4-op voices and 12 2-op voices
  • Front panel button matrix, LED matrix, encoder array, and LED display digits
  • Mode control, MIDI channel -> voice allocation, and basic voice editing
  • DUPL voices (polyphonic copies that maintain similarity when parameters are changed)
  • LINK voices (voices that are sounded together)
  • Delay line (when combined with LINK, allows for delay/reverb effect)

The following features are also working but were not used here:

  • Portamento and Retrigger option
  • Transpose and tuning control
  • Drum channel MIDI mapping

The following features are not done/working yet:

  • Parameter modulation
  • Saving/loading patches
  • CC parameter controls
  • OPL3 percussion mode (including editing)
  • Wavetable editing
  • The entire sequencer
Edited by Sauraen
Link to comment
Share on other sites

Just finished some more modifications to the MBNG framework, this time to allow for display of negative values properly with a negative sign, as well as blanking leading zeroes. Both are optional and triggered from your config file:

# LED display digits
# Using digit_signed=1 automatically enables digit_blankzero
EVENT_LED_MATRIX id=8 led_matrix_pattern=Digit1 type=MBFM mbfm=DispValue digit_signed=1
EVENT_LED_MATRIX id=7 led_matrix_pattern=Digit2 type=MBFM mbfm=DispValue digit_signed=1
EVENT_LED_MATRIX id=6 led_matrix_pattern=Digit3 type=MBFM mbfm=DispValue digit_signed=1
EVENT_LED_MATRIX id=5 led_matrix_pattern=Digit4 type=MBFM mbfm=DispValue digit_signed=1

EVENT_LED_MATRIX id=4 led_matrix_pattern=Digit1 type=MBFM mbfm=DispVoice digit_blankzero=0
EVENT_LED_MATRIX id=3 led_matrix_pattern=Digit2 type=MBFM mbfm=DispVoice digit_blankzero=0

 
gallery_10357_214_493552.gif

Link to comment
Share on other sites

So I have some more actual questions for anyone who might be interested in building one of these.

 

How terrible would it be if Pitchbend, Sustain, and Mod Wheel controls were hard-coded instead of being routed in your .NGC file?

Pitchbend is not a modulator, it just enters into the pitch calculations for a voice and adjusts it accordingly. There may be a global menu option for how far to bend, but this won't be modulatable. There are, however, tuning and transpose parameters that are modulatable.

Sustain is also not a modulator, it affects what happens to voices when they get Note Offs--basically marks them for being released when the pedal is released. This would just permanently assign that to CC 64.

Mod Wheel is a modulator (assignable time-varying data source), this decision would just make it permanently assigned to CC 01.

There is also a modulator, VARI (variation), which I will keep as assignable to input from wherever in your .NGC, like so:

EVENT_RECEIVER id=1 fwd_id=SENDER:1 type=CC chn=1 cc=2
EVENT_SENDER   id=1                 type=MBFM mbfm=ControlVari:0
EVENT_RECEIVER id=2 fwd_id=SENDER:2 type=CC chn=2 cc=2
EVENT_SENDER   id=2                 type=MBFM mbfm=ControlVari:1
# and so on for the other channels, or whatever you want to have control it

 

How terrible would it be if all the CC-based controls for editing voice parameters--as if you were twiddling the knobs on the front panel--were hard-coded?

I had to take memory away from the .NGC event pool to make room for the MBFM stuff, so my current config file, which has all the front panel stuff but no CCs for editing voice parameters, is about 70% full. I'm not sure if there's going to be room for a whole additional set of EVENT_RECEIVERS that perform similar actions--and if there is, there'll be almost no room left over for banking and other things you want your hardware to do. Leaving aside "special" CCs like 0 and 32 (bank), 100 and 101 (NRPN) (which will have to be hard-coded anyway), if I assign the rest of them permanently to other CCs, will this make trouble with anyone's DAW? Does anyone's DAW insist on sending the LSB version of parameters after the MSB version (e.g. CC 16 always is followed by CC 48)? I would not hard-code the assignments into the actual code, I would make them with preprocessor commands in your mios32_config.h file (which you're going to have to edit anyway to set up the hardware mapping of your OPL3 modules), so each user would still be able to edit them if necessary, just it would require a recompile. Also it would be significantly faster to process control changes if they were hard-coded, which matters if you're doing "smooth curves" with them in your DAW and sending hundreds of them per second on multiple channels.

 

How do you want modulators to change the values of parameters?

So you set a parameter, let's say you set Op Volume to 50. Now you assign an LFO to that parameter with depth 10. The LFO itself always outputs values (right now, this is the part I'm asking about!) in the range -127 to 127, so the synth engine scales this to -10 to 10 and adds the current modulator result value to the original value of 50 to get a range of 40 - 60. If you assign an EG, however, it outputs in the range 0-127, so instead of the 50 being the middle value, it's the low value, and it ranges 50 - 60. This came about because I think of EGs as being above the x-axis but LFOs as being symmetrical about it, but it's inconsistent and may be confusing to other people.

Possible solutions:

  • Make all modulators output 0-127, so the original value is always a minimum (this will make Velocity, Mod Wheel, and Vari go in with their original values)
  • Make all modulators output -127 - 127, so the original value is always the middle (requiring those three passive modulators to be scaled by twice)
  • Some combination that makes sense to people
  • Switch to u8 and make all modulators output 0-255 (probably not a good solution)
  • Make all modulators output -63 - 63 (preserve VEL/MOD/VARI values, probably not a good solution)

By the way, when you have two modulation sources connected to the same destination, these delta values simply add.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...