MIDIbox FM V2.0 on LPC17

[Sauraen]

[image: MIDIbox FM V2.0 Prototype, testing temperament system with Goldberg Variations]

 

 

Since I've now developed and partly tested a driver for the OPL3 module for the LPC17 core (see ), I've been thinking about what the full next-gen MIDIbox FM will look like. [Edit: Well, uhh, there's a picture above...] I have some parts for a new build, and I've been thinking of taking a hiatus from the above project to develop a prototype MBFM 2.0, with a complete module driver, and hopefully, with an application layer that can be modified easily into an official release. Here's what I'm currently planning; please post suggestions or feature requests!

 

Up to two OPL3 modules controlled by parallel interface.

Each OPL3 module provides all of the following: 12 2-op voices, each pair of which can be combined into one 4-op voice, for up to six 4-op voices; plus 3 2-op voices which can't be combined; plus 3 2-op voices which can be turned as a whole into 5 percussion voices. This means that, from each module, you can have up to 18-voice polyphony of 2-op voices, up to 6-voice polyphony of 4-op voices plus up to 6-voice polyphony of 2-op voices, or either of the above minus three 2-op voices plus drums. You may use one or two OPL3 modules and set up any of the voices arbitrarily (within the hardware limits of the chip).

 

The parallel interface will have D7:D0 of the OPL3 module connected to J10 of the LPC17 module, /RS of the OPL3 module connected to J19:RC1 or RC2 (whichever is not otherwise in use), and the other OPL3 pins (A0, A1, /CS for OPL3 A, and /CS for OPL3 B) connected to J28. I expect one full register write operation to take around 15 us.

 

 

Front panel using MBNG framework.

If you don't like what buttons/knobs I'm putting on the front panel of mine, make your own! All synth engine parameters (both OPL3 parameters and things like modulator connections) will be MBNG commands that you can write into your configuration file. The default config file will also have all the parameters hooked up to incoming CCs, and you can modify this as well of course.

 

 

In addition to just modifying all the parameters of the OPL3, sophisticated core-based modulation like in MBFM 1.4 (but slightly more powerful).

Each 2-op voice gets:

• one 6-step (ADBSSR) EG
• two LFOs, with frequency, delay, and waveshape controls; option for whether the frequency is a function of the tempo, or of the system time
• 32-step "wavetable" parameter sequencer
• Velocity modulator
• Mod Wheel modulator
• CC2/Variation modulator

For a 4-op voice, you get doubles of the first three of these (2 EGs, 4 LFOs, and 2 Wavetables). Doubling the last three wouldn't make any sense!

 

Each of these modulators has an Assign button. Hold down that button and tweak any knob on the front panel to make that modulator affect the value of that knob. The value that the parameter was set to before being assigned (or whatever you change it to while not holding the Assign button) is the "middle" value of the parameter, what it will use when the modulator is halfway through its range. The amount by which you adjust the knob, in either direction, while holding down Assign is the depth of the modulation, the range around that middle value.

 

You can assign any modulator to any number of targets, including parameters of the same modulator, with independent depths. Edit: However, each voice supports a maximum of 16 of these modulation connections due to RAM consumption. Currently not sure whether my synth engine is going to be able to handle 32 connections for a 4-op voice, or if it'll be 16 connections there too. Still don't think you're ever going to run out, consider other synths give you 4 per voice or 8 for the whole machine.

 

Equal temperament or custom temperament system editable straight from front panel.

 

 

Arbitrary, semi-dynamic voice allocation based on MIDI channels.

Select a MIDI channel and assign any number of voices to it. Load a patch and it will fill out those voices in polyphony as well as possible.

 

One voice that is a polyphonic "copy" of another will be linked to it with a DUPL button (automatically done on loading the patch). Also available is a LINK button that will cause the two voices to be sounded simultaneously, with any parameters that you modify of the LINKed voice remaining independent from the first, but changes to all others on the first affecting both. A patch may consist of any configuration of LINKed voices, not just two. CC 0 / CC 32 bank change messages and Program change messages will be supported properly (not mapped to any other parameters).

 

Save a patch or a complete state of the synth to SD card (no BankSticks).

 

 

Small fractal drum sequencer (later feature).

12(10) tracks, 16(17) steps per measure, 8(4) measures, 18 patterns in RAM. Let me explain...

 

When I write a drum pattern for a song, most of the time measures 1, 3, 5, and 7 are identical; measures 2 and 6 are identical and slighty more "interesting" than measure 1; measure 4 is more "interesting" (a fill) than measure 2, and measure 8 has the most fill. So I decided to make a sequencer that plays just those measures in that order: 1-2-1-4-1-2-1-8. When you record a part for the first time, it automatically fills up measures with higher indices than itself but not lower ones, so you can start the beat the way it is for all the measures and then just record the changes when they come along.

 

But there's one problem with this: the crash cymbal that very often occurs on the downbeat of measure 1 (but not measures 3, 5, and 7!). Since the front panel already has 18, not 16, buttons in a row for selecting voices and potentially for selecting steps of a measure, I had an idea. Make each measure 17 steps long and have it overlap with the next measure by 1 step. Thus, the first step played when you start the sequence is both step 1 of measure 1 and step 17 of measure 8. Record that crash cymbal in 8.17, and it will only play at the beginning of the whole pattern, not every time measure 1 is played again! So the display will have steps 1-16 of the current measure in buttons 2-17; the 17th step, which overlaps onto the next measure, in button 18; and the currently-overlapping step from the last measure in button 1.

 

Now to the more specific features of the sequencer. Each step for each track contains:

• 1 bit note on
• 1 bit velocity: track-wide setting for what the two values are that this selects, default 80 and 120 or something
• 2 bit gatelength: selects 1/4 of a step, 1/2, 15/16, or 1 (full, no retrigger of note at beginning of next step)
• 1 bit variation parameter, that sends either 0 or 127 to the CC2/Variation modulator of this instrument, so you can get two different sounds out of a track

 

Even though the OPL3 only has 5 percussion voices (if enabled), namely Bass Drum, Snare Drum, Hi Hat, Tom Tom, and Cymbal, MBFM V2.0 will have 6 drum trigger buttons and apparent tracks (per OPL3), the extra one being for Hi-Hat Open. This is actually implemented by using the variation parameter--closed is variation = 0, open is variation = 127, and you can map that to Decay Time or whatever in order to get the two cymbal sounds. (So internally it's just one track for HH, with the variation bit determining whether the step shows up in the editor for HHC or HHO.) Thus the variation parameter per se is not available for the two HH channels; and due to bit widths, it is also not available for the Cymbal track.

 

18 patterns are selectable by holding down the PTN button and pressing a voice select button. If you press the button once, the sequencer will jump to that pattern at the end of the 8-measures; if you press it again, it will jump to the current position in that pattern immediately (morph). Edit: Again due to RAM consumption, the 18 patterns may not be actually loaded into RAM, it may just be the one. Estimated 2 ms delay between selecting a new pattern and it completely overwriting the current one (this delay will not affect the tempo clock, which is an independent hardware timer, just when the changeover between patterns actually takes place).

Edited February 23, 2014 by Sauraen

[Altitude]

as many voices as possible without degrading performance.

[Imp]

1 OPL is enough imho. I never ran out of voices when playing my sammichFM.

The possibility to add another, should the need arise, doesn't hurt though.

 

I'd put all controls for one OP on the surface, plus buttons to select the OP.

There are parameters which are not used frequently, so I'd keep them in a menu.

 

What i miss on my sammich is a fulll blown unison-mode. You can't detune OPs within a voice. I think it is a hardware limitation of the OPL.

But you can detune voices. FM v1 can do that with 2 voices, which is nice, but somewhat limited.

[m00dawg]

A feature I would like to see is perhaps more reliable CC and patch change support. I think it is more of an issue with Ableton Live than MBFM, but I have had to move to using Reaper for live performances to handle patch and parameter changing in large part due to having to use SysEx to make changes over standard CCs. For whatever reason, with CC's it doesn't work consistently for me. This is with sammichFM. After moving to Reaper, I have had no issues, so this is really more of a nice to have kinda thing.

Some of the additional modulation stuff provided by the LPC17 sounds really neat! But I don't know what that means in practice :smile: so I can't say too much about that.

[niklasni1]

I don't think paralel connections are a problem at these frequencies, except of course it's more solderpoints to fork up :)

 

2 modules would be very nice.

[Sauraen]

2 modules would be very nice.

 

 

Glad to see some interest! :D

 

 

I'd put all controls for one OP on the surface, plus buttons to select the OP.

There are parameters which are not used frequently, so I'd keep them in a menu.

 

So: all the controls for one operator; four buttons with LEDs to select between operators (if it's set to be a 2-op voice, only the first two will work); all the controls for that voice; 18 buttons with LEDs to select between voices, and two buttons with LEDs to select between OPL3s (if you have two). Do you want the controls for the software-implemented modulation, i.e. the two LFOs, EG, Wavetable, velocity response, and modwheel response for each voice, to also be on the surface, or in menus? (I'm leaning towards the former; that's not that many knobs, and the latter three are just a single button each to select the destination that the parameter modulates.)

 

A feature I would like to see is perhaps more reliable CC and patch change support.

 

This is how I was thinking of doing the patches.

 

Hold down MIDI button and press one of the voice buttons 1-16 (minus 10 which is permanently mapped to drums) to select a MIDI channel. MIDI button's light turns on as well as that voice button's light. Hold down SELECT button and press voice buttons to assign those voices to this MIDI channel. Now press FM button to switch back to voice editing mode. Select one of the voices you had assigned to that MIDI channel and edit its parameters until you get the patch you want.

 

Now, if you want all of the voices assigned to this channel to play that patch in polyphony, select each of them, hold the DUPL button, and select the voice that has the patch you made. This will do two things: lock the parameters of those voices to match the parameters of the one you made (so when you edit that voice, whether manually or through CCs, it updates all of them); and tell the polyphony engine to assign any incoming polyphony on that MIDI channel across all those duplicated voices.

 

However, if you want multiple voices (e.g. two) to sound when one note is played (e.g. for a stereo effect, or let's say 3 (or 36!) voices detuned for a unison effect), select the second voice, hold the LINK button, and select the first voice. Now edit any parameters of the second voice that you want to be different from the first voice (e.g. output assignment, tuning). These parameters will be saved per voice, but any parameters of the second voice that you haven't touched will be linked to the first voice (e.g. volume), so if you edit the first one it will update those for the second one. The polyphony engine will activate all linked voices at once.

 

When you save a patch, it will save it as needing as many linked voices as you have set up, but it will ignore duplicated voices. So later, you can load that patch into a channel that has been assigned a different number of voices, and it will automatically fill them up with duplicates of the saved voice for polyphony.

 

I think an example is in order. Let's say you want to make a pad that sweeps smoothly from side to side through the stereo spectrum. Since the OPL3 audio outputs are binary (not volume-leveled), you need to use two voices, one set to left channel and one to right, and change their volumes so one increases as the other decreases. Pick a MIDI channel and assign two arbitrary voices to it, let's say voices 13 and 14 because we happen not to need 4-operator voices for this patch. Select voice 13 and set up the pad, assigning it to L channel and hooking one of the software LFOs to the second operator's volume, with a starting phase of 0. Select voice 14, hold LINK, press voice 13 button, release LINK. Assign the voice to R channel and change the phase of the LFO to 180. Press SAVE, make up a name, it will say on the screen that this patch uses two 2-op voices. Now you want to play this patch with 18-voice polyphony across both your OPL3s. Select a MIDI channel and assign all 36 voices to it from both chips. Press LOAD and select your patch. Your patch will now be loaded into all 36 voices--or rather, the first voice of your patch will be loaded into the odd-numbered ones and all will be DUPL'd to voice 1, and the second voice of your patch will be loaded into the even-numbered ones and all DUPL'd to voice 2. Voice 2 will be LINKed to voice 1.

 

As far as MIDI CCs, this could be accomplished as follows. I'll set up some CC with a large value (over 100) that means "assign the voice whose number is the data to the given MIDI channel". So send a bunch of those CCs with the channel you want and data values 1-36. Then simply send a program change message for whatever index your patch was saved as, and it will do what I described above when you select your patch.

 

How does this sound?

[Thomasch]

Hi Sauraen,

I like your Idea to develop a V2.0!

 

Here are my thoughts about a potential V2.0:

 

1. Velocity

• Velocity mapping is meager with MBFM V1.4 - actual only one free assignable target and the 3stage velocity to global-volume chooser is possible...
  Thats far to less routing possibilities to make really living and breathing velocity sensitive sounds.
  Would be really cool to use velocity messages to modulate multiple parameters on independend modulation depths.
  When talking of modulation depth, i think of a low and a hi value. (With V1.4 it's a little different it uses instead of a hi value a range value.)
• with firmware V1.4 the base value of the velocity modulated target parameter is simply replaced by the velocity value you feed into.
  It woul'd be much better if velocitymodulation would not replace, but rescale the actual value of its target.

2. Filtersection

• a polyphonic Filter woul'd be great...

 

3. ext. LFOs, Envelopes

• LFOs should be switchable monophonic/polyphonic.
• much more external Envelopes - at least 1 per operator, to override the internal Envelopes and get rid of the 16step value limitation. maybe a flag to switch between internal and external envelopes woul'd make sense.

4. User Interface

• I'd vote for a full 4 OP Encoder Setup, to minimise stupid display page hopping.
• Even the use of LED-Rings would ease the use. You coul'd recognise the whole setting of a soundpatch with just one look.
• Using of OLED Displays woul'd also be a big benefit for readability from side angle views.
• Unfortunately some sizes and colors (2x40) of Character OLEDs are hard to get, graphic OLEDs are more easy to get.
  I woul'd prefer big Graphic OLEDs because things like algorithmstrucures, waveformpictures, slider, rotaries and even graphical elements to hilight and group Parameter. Different fonts and font sizes will also be possible.

5. V 2.0 and DAWs

 

• MBFM V 1.4 reacts a little critical in case of program- and bankchange messages recieved from DAWs.
• simultanious programchanges on more than 1 channel doesn't work. this blackout like behavior has to be adressed with the new V2.0
• MBFM V1.4 use programchange messages and bankchange LSB Messages on CC#0.
  Unfortunately Abeton bangs always Prog.change together with Bankchange LSB on CC#0 and additionally a Bankchange MSB on CC#32.
  Please keep this in mind, and keep CC#32 reserved when you attach parameter to CCs.
   

Best regards

Thomasch

[Sauraen]

Current front panel mockup design:

 

(Please ignore the floating toggle switches in the lower right hand corner... this was a quick job and I didn't notice until after uploading...)

 

The indications on the LCD represent: Channel 12; 6 voices assigned to it, patch uses 0 4-op voices and 2 2-op voices; 5 voices free, i.e. 1 4-op voice and 3 2-op voices; current polyphony on this channel 2 (two notes playing); Bank 0, Patch 102, Name: BrightRhodes2

 

I was going to just put in drum trigger buttons (you would only have one row if you put in only one OPL3), but then I figured I'd leave room on the front panel for a small fractal drum sequencer. The 18-position button array at the bottom (not all those LEDs are necessary) would be perfect for this: each measure actually stores 17 steps, and the 17th step from the last measure is played at the same time as the 1st step from this measure. The measures are played in the order 1-2-1-4-1-2-1-8, so you only have to store and edit 4 measures and you get an 8-bar pattern. The 17th step of bar 8 could be a crash cymbal, for instance, and then it would only play it at the beginning of the whole loop, not every time you played measure 1. Anyway, this is not going to be something I'm going to work on at first!

 

@Thomasch:

 

1. I was planning to have all the "mappable" controls (see panel: LFO1, LFO2, EG6, WT (Wavetable, i.e. 16-step parameter sequencer), VEL (velocity), and MOD (CC1, modwheel)) work like this. Hold down button of the modulator (e.g. VEL button) and turn the knob that is the parameter you want the modulator to affect (e.g. volume). Center of knob means zero effect, all the way right means full range positive sweep, all the way right means full range negative sweep. The value of the parameter (e.g. volume) that you put in while NOT holding the VEL button is the "center" value that you will hear when the modulator is in the middle (e.g. velocity 64 or LFO centered). So you basically have a control for the center of the modulation and then a control for amount around center. Each modulator can have as many targets as you want (though keep in mind the stuff in my first post about slowing down the framerate).

 

2. I like your filter idea (note the "Multimode Filter" section on the top of the panel), but it can't be polyphonic, since the OPL3 does not have it built in and it only has 4 audio outputs. In my build this will just be hooked up to Output 4 ("Bus 2"), but this would be up to each individual person--it's all analog, not driven by software at all. I'm also throwing into mine the guts of a cheap 80s guitar chorus pedal, hence the "Analog BBD Chorus" section, but again, not standard.

 

3. I didn't think of the switchable thing, but I'll make a softkey available when you're holding down the LFOx button to switch it. Why do you want more envelopes, though? I was going to include one per voice (per two operators, so two for a 4-op voice) like in MBFM 1.4. If you want authentic period sounds, the 4-bit parameters come with the territory! (And keep in mind that the external volume parameter is only 6-bit whereas the internal EGs can modulate the volume at a much finer resolution, so software EGs will give you improved timing accuracy at the cost of worse output resolution.)

 

4. I'm going to build it on the MIDIbox NG framework--the synth engine will simply be more parameters that you can put into your configuration files to have your front panel control. Personally I want to do a build with nearly all analog potentiometers, and I don't want to fiddle with LED rings; but if that's what you want, go right ahead! Everywhere I have a toggle switch could be replaced by two buttons-with-LEDs, and of course pots with encoders.

 

5. I will add a menu option of whether you want it to respond to only 7-bit bank change messages on CC0, only 7-bit messages on CC32, or 14-bit messages across both. I will not attach any other parameter to either CC. When you save a patch, it'll be some .mbfm file on the SD card, and you can tell it when saving what bank number and patch number to make it (they don't have to be contiguous).

Edited October 13, 2013 by Sauraen

[lazerbeat]

One thing I would be interested in would be a more flexible control over allocation of ops and voices. for example the Midibox FM ensembles are (as far as I can tell) hard coded as 6 voices over 4, 4 op instruments and the 5 percussion instruments. Being able to use for example 6 monophonic 4 op voices or a mixture of 2 and 4 op instruments like you could in Adlib tracker would be amazing.

 

Fingers crossed I didn't miss this somewhere in the existing FW1.4....

[Sauraen]

One thing I would be interested in would be a more flexible control over allocation of ops and voices. 

That is one of the reasons I wanted to do this build! I know I can be a little long-winded sometimes :), but I talked about that a bit above. The whole idea is to be able to connect it to a DAW/sequencer and have each MIDI channel be one patch, possibly across multiple voices, and then you could program it like an OPL3 in a soundcard.

 

One thing I didn't talk about was how it would handle 2-op versus 4-op voices. The short answer is select a voice that is the first of a pair that can be combined (i.e. 1, 3, 5, 7, 9, 11 on either OPL3), and press the 4-OP button (or throw the switch in my above drawing). Patches would be saved based on how many of each type (2/4-op) they needed. For 2-op patches, it would fill up the voices that can only be 2-op first, and then start using voices that could have been combined.

 

Fingers crossed I didn't miss this somewhere in the existing FW1.4....

I haven't built one, but AFAIK you are correct, it is not an option. MBFM 1.4 never even uses three of the two-op voices that cannot be combined or turned into percussion. Overall, you have 18-2d-3p 2-op voices, d 4-op voices (with 0 <= d <= 6), and 5p percussion voices (with 0 <= p <= 1) that are permanently attached to Bass Drum, Snare Drum, Tom-Tom, Hi-Hat, and Crash Cymbal. Since this was probably unclear, see the picture above.

[Imp]

Personally I want to do a build with nearly all analog potentiometers

 

If you don't come up with a very sophisticated method to prevent parameter-jumps, the usability of your project will suffer dramatically.

I know that for some parameters pots feel better than encoders , e.g. cutoff. This might also be the case for OP-volume or OP-multiplier on the FM, but imagine loading a patch and having to adjust those to the former positions. This would be a total nuisance, especially since FM is all about finetuning.

[Sauraen]

If you don't come up with a very sophisticated method to prevent parameter-jumps, the usability of your project will suffer dramatically.

Thought about it, did some searching on eBay, found encoders that were actually cheaper than potentiometers... I'm not sure now.

 

I've used the Korg Electribe and microKorg pretty extensively, both of which use potentiometers. The former uses hard-takeover, the latter soft-takeover. I very much prefer the former. If I'm turning a knob for a parameter, I want that parameter's value to change! And I want to change it as quickly as possible to the value I have in mind, which is only possible with an absolute control method (not relative like encoders). Most of the time I'm not tweaking the sound bit by bit while the synth is playing--instead, most of the time I want the synth to be tweaking the sound bit by bit while I'm playing (via EGs, LFOs, Wavetable, or even sequenced CCs). The soft-takeover on the microKorg was a pain for me, because I would first have to turn the knob to whatever the current value was, and then turn it to the value I wanted. Smooth, yes, but delayed--what if the value is at 0 and I want it at full and the knob is at full? If it had hard takeover I could just touch the knob and it would jump to full, whereas there I have to turn it all the way down and then all the way up. Relative motion like with encoders solves the delay problem, but you still have to know what the value was in order to know how to change it quickly, you can't just turn it to what you want it.

 

The other issue is the range of parameters. If I can take apart the encoders I get and remove the detent, they will be usable, because it will be 64/96 steps per complete turn (the maximum resolution of an OPL3 parameter is 64 steps for OP-volume). For the software-based modulators I suppose I could live with turning them four times around to go through the whole 8-bit range, though that's a bit obnoxious. However, if I can't mod the encoders without ruining them, and even if they had 24 steps, that would still be 10 complete turns to go through the range of a parameter of one of the LFOs or EG.

 

As far as seeing the values on the knobs, I'm NOT going to fiddle with (or pay for) LED-rings. Not for 26 knobs.

 

What do other people think? I know this is, like, one of the biggest ongoing arguments in MIDIbox-land, but would anyone else want to do a build with potentiometers?

[lazerbeat]

Another feature I would really like would be to mute individual operators from the front panel. This might sound like a weird request but if you are used for programming any of the older yamaha FM synths (love my dx11) it is a really useful feature for sound design. You can just work on perfecting an individual envelope or hear exactly how one modulator is effecting a specific carrier. 

 

Also just an observation, it might be worthwhile editing the 1st post to make it a bit clearer what you are actually planning on adding. Something like Thomasch's post #7 is really easy to understand. The current 1st post is a bit "wall of text"y!

[Sauraen]

@lazerbeat: Added, thanks! I know what you mean, working with the SY99. Though that has up to 24 operators per voice... :rofl: And I will update the first post soon!

 

 

@Imp: I'd love to do this, but there's no way I'm wiring all those LED displays on veroboard. That's 7 shift registers in the matrix just for selecting digits! Makes me REALLY want to do the potentiometers--SO much simpler... Unless a bunch of people want to do a bulk order for a front panel board, or I can persuade someone to let me use their CNC machine to rout a custom board, I don't think this is going to happen.

[Imp]

That's just one possible solution. I see no need for neither numericals nor LEDrings. What's wrong with showing those values on the display instead?  

 

BTW, the Electribe has an  "Original-Value" LED, which lights up when the recently adjusted pot is where the value was before. Just one LED for all of those pots. You could make that two, to show the direction, the pot has to be turned. It works quite well, but there is a significant  difference between parameters of the Electribe and OPL. While the former are mostly independent, the latter have to be adjusted almost simultaneously for proper scoulpting of sounds. That's what i meant by "finetuning".

 

Using pots would be like: [select OP>find former value>adjust value>change selected OP>find former value>adjust value]*n

 

While using encoders would be:[select OP>adjust value>change selected OP>adjust value]*n  That's much faster, especially since you'll repeat that sequence very often. It's an important advantage if you want to archieve results with limited patience.

 

Maybe having dedicated pots for MULT and VOL and a button for the waveshape for each of the 4 OPs while keeping the other controls shared or in the menu might work well.

Something like "KSCL" or "HOLD" is a pure waste of precious space on the frontpanel. I don't say that, because I'd be too lazy to wire those up, but because i like simple and tidy control surfaces.

Lot's of useless controls might look impressive to some people, but in fact they stand between you and an efficient workflow.

 

Keep that  OP-mute-ALG-select thingie though, I like that idea.

[Sauraen]

While the former are mostly independent, the latter have to be adjusted almost simultaneously for proper sculpting of sounds. That's what i meant by "finetuning".

You're right, assuming that most of your control inputs will be slightly adjusting an already-existing sound (or one that's playing), rather than creating a new sound from scratch. It depends on your style of using the synth: if you want to hook this up to a MBSEQ V4, press Play, and start tweaking things, absolutely; if you want to make patches and then program a complete song into your DAW or play it live with your keyboard, you're mainly going to be touching knobs to change them dramatically, not slightly. But I was thinking about it, and I didn't like one feature of the Electribe, which was jittery parameter values that required you to barely touch the knobs to get right. Detented encoders will never have that problem, and the only values here for which I would want the full speed of a non-detented encoder would be in the software modulators--none of the OPL3 parameters are high-res enough.

 

As far as the almost-useless parameters like KSCL, the control surface configuration will be through the MBNG platform, so you can put them in a menu if you want; I don't like menus at all, so I'm going to leave them out on the front panel. :) I do like lots of controls, and part of the purpose of this build for me is to demo MIDIbox FM V2, and really, to demo the OPL3. So I want a control directly on the front panel for every OPL3 parameter.

 

So let's say I take off all those LED displays. Do I add in a full set of encoders for all the parameters of the other two operators that may or may not be part of the current voice? Again, you can make your own build one way or the other, but what should I do? I think it would feel cluttered to include the controls for all four LFOs and two EGs, and after all those really aren't OPL3 parameters. Maybe the full controls for one of each, a button to select which one is currently mapped to the controls, plus an Assign button?

 

There are encoders on eBay for $0.99 per 10 (plus shipping).

[Imp]

You're right, assuming that most of your control inputs will be slightly adjusting an already-existing sound (or one that's playing), rather than creating a new sound from scratch.

 

Did you ever create a new sound with the OPL? It involves many iterations of "slightly adjusting". That's my whole point really.

You don't think of a sound, then set the pots once and save.

Maybe you'd be better off building a minimal FM1.4 first, to gain an overview. It will be little extra work in relation to the benefit.

Form should follow function, so to get the form right, you need to know the function.

 

Again, you can make your own build one way or the other, but what should I do?

 

I won't build another MBFM, as i am quite content with the Sammich. I'm just trying to give advise because i think it's a good idea to give the MBFM a little update.

[Sauraen]

Would this be satisfying?

 

 

Also, I completely rewrote the first post to be more like a feature list.

[Nasrudin]

wow, this is an enormous frontpanel! however, i am not sure if the quantity of all those dedicated LEDs and Buttons will simplify the use of fm synthesis. i am aware that modeling fm sounds is not that linear compared to classic subtractive sounds, but linking every parameter to a single haptic element instead of burring them into a fragmented displaymenu wont solve the problem in my opinion. i really liked the "quick set" concept of the old frontpanel, maybe selected extensions and using a larger display together with a new menu structure would do the job?

 

Regards,

Nasrudin

[Sauraen]

The picture is kind of enormous, but the actual front panel is sort of average-sized, I think it's 11" x 15" off the top of my head. It's to fit on a nice case from a device I got out of the trash. I guess it's enormous if you were expecting a sammich-type device!

 

I don't like layered menus at all. I avoided the use of a bunch of buttons for less-used parameters by using a sort of menu for them: hold down the PARAM button and the display shows all those parameters, press the softkeys to turn them off and on (built-in LFOs, key scaling rate + amp, hold mode). This also is how the wave select works for both the oscillators and the software LFOs.

 

I won't claim that having all those knobs directly available will make FM synthesis any easier--but it certainly can't make it harder than hunting through menus to edit parameters. I have an EMU ESI-4000 that's sitting completely unused on my rack, because while it's decently powerful, most of the time spent using it is navigating through the menus. I've also used the SY-99 decently extensively, and the menu-based structure is made up for by a graphical screen and the fact that the front panel would be the size of a mixing console if you had a control for every parameter of a sound! But if menus are what you like, again this is on the MBNG framework, so you can edit the interface however you want.

 

One more change I'm making to this is that I looked up the pricing for the buttons, and ouch! I decided to go with standard tact switches and LEDs on veroboard, and have custom translucent buttons 3D printed like for my ASIDITY project. This is actually much cheaper!

Edited October 28, 2013 by Sauraen

[Imp]

There's still way too much controls for my taste. Less is more.

The "OP-Block" is kind of what i meant, but it could be reduced. 

One row of envelope-controls could be used for all ops, just make it control the env of the op that has been tweaked last.

If you have a wave-button, mute, MULT and VOL per OP + one row of env, those could be arranged in a 4x5 pattern.

I'd keep the filter, but get rid of the sequencer and delay. Put them in a rack, that way their use is not restrictet to this machine.

The OPL has enough parameters on it's own and you need space for those.

As a rule of thumb, you need to be able to put one between adjacend knobs.

[Shuriken]

Just a suggestion, since FM based synthesis is hard to edited manually, wouldn't it be a good idea to design a frontpanel control later? first let people try like thru Lemur preset what is working? I think this is the reason why Thorsten's MBFM frontpanel is quite minimal in comparison to MBSID. FM is not like an analog synth where parameters make sense, you will have more chance of having a nice patch by using the random patch generator.

[niklasni1]

Shuriken -- I strongly disagree. If you know how FM works the parameters make perfect sense, and a good interface really helps learning. I spent a lot of time on Ableton Operator (part of Live), and after that even my TX81Z was a doddle (even though its interface consists of two arrow keys and +1/-1 buttons).

[Sauraen]

@Shuriken @niklasni1

Especially when learning to use a sound architecture (e.g. FM synthesis) for the first time, I would very much want to be able to see ALL of the options at my disposal. "FM is not like an analog synth where parameters make sense, you will have more chance of having a nice patch by using the random patch generator"--why bother trying to control anything then? :smile: (And that's only true because TK did such a good job with the random patch generator, making it not completely random!) Also, since this is basically a test build for the MBFM V2.0 driver and application, the easiest way to make sure that everything is working properly and as expected is to have everything on the front panel. Finally, I happen to already have a case that this front panel would be mounted on, so the size is fixed for me, and there's no point in having empty space where I could put a knob.

 

@Imp

The chorus and filter are fully-analog (not CV) modules I'm working on and going to connect to outputs 3 and 4 of the OPL3s; the application will know nothing about them, and I don't expect anyone else to replicate them. The delay parameter will allow you to delay note data triggering a voice; when you use two voices with one delayed, detuned, and possibly stereo-separated, you can get some nice chorus/delay/flanger/etc. effects, at the cost of one button and one knob on the front panel (and a bunch of RAM used, but that's not a problem as long as everything eventually fits). As far as the sequencer, I'm not going to work on that initially, I just wanted to save space for it on the front panel. If I was going to make a dedicated sequencer, it would be much more powerful than that. AFAIK MIDIbox FM V1.4 MIDIbox SID has a drum pattern thing that is about as powerful as what I am proposing.

Edited November 3, 2013 by Sauraen

[Imp]

AFAIK there is no sequencer in FM 1.4.  Never found it, the manual doesn't mention it.  You can easily sequence the drums via midi e. g. with the electribe, so it's not that important to have it on board.

The delay/detune feature sounds like a good idea. Chorus and filter might also be useful, since they could add some analog feel to the sound, which is kind of too clean on its own. But you may need that space they occupy.

 

 

there's no point in having empty space where I could put a knob..

 

That's true, as long as that space is concentrated in one location. If it's used for a wider spacing of knobs though, it helps to prevent unintended input.