Bug? Realtime parameter modification, and LFOs

MIDIbox FM
1

Hi there,

My MBFM does not have a control surface, so I have to lovingly program it with midi CCs and sysex. ;o)

I’m using the firmware version (v1_1d_rc1) which adds a cetain sysex string that overwrites the current patch in RAM to a bankstick. (Thread about this here: http://www.midibox.org/forum/index.php/topic,12554.0.html)

Lately I’ve been wondering about playing the MBFM in a live situation, sending CCs whilst notes are playing to morph the sound whilst a sequencer plays.

The first four CCs I tried were 28,29,30, and 31 (the amplitudes of the four operators). But they only seem to update between note messages, not _during_ a note.

I’ve noticed that if you map any of these to the aftertouch (using cc 92), the amplitude parameters _are_ updated in real time. I can change the volume of one of the operators during a note - but obviously this only works for a single controler. I want to press and hold a note and wiggle the faders and knobs on my control surface to wreak FM havoc on stage! ;o)

Have I found a bug TK?

I’ve a sneaky request to make if we discover it _is_ indeed a bug; When you’re editing the code, could you also modify the way the LFOs work slightly?

Whenever I set either of the LFOs to modulate the pitch (using CC 67 or 83), the depth is quite extreme even on low settings like +/-1 (cc value 65/63).

It’d be great if there was a way to optionally narrow the LFO depth. It’d be really ultra-great if this was mapped to a CC of its own (rather than a binary bit of the LFO1/2 mode parameters) so that when writing wavetable sequences that modify CCs iteratively, you could create some pretty whacky LFO sequences that suddenly go crazy then back to normal, or create really gradual slowly evolving LFO textures using the finer depths.

I realise it’s cheeky of me asking you to do this, so no problem if not. This all just dreams and wishes. ;o)

2

Hi,

yes, you are right. The volume parameter wasn’t updated correctly.

Since you are not the first one who complains about the pitch depth, I reduced the intensity by factor 4 - more doesn’t make sense, as you won’t notice any effect anymore due to the (low) 16bit resolution of the frequency register.

It isn’t possible to provide an alternative CC

I hope that this change won’t lead to MIDI IN buffer overruns if all voices are modulated, as it increases the synth update cycle by ca. 10 uS! The synth engine already extremely loads the CPU, so that I cannot exclude failures anymore.

Here a snapshot of the current version - please try and give feedback:

http://www.ucapps.de/tmp/midibox_fm_v1_1d_rc2.zip

Best Regards, Thorsten.

3

Man, you’re the best TK! LFO mods and all… Thanks for this - top work sir. I’ll give it a go and let you know how I get on.

Wheee~ ;o)

4

Okay, so I’ve had some time to test out the 1.1d_rc2 MBFM software… I’m very happy now that the operator amplitudes update in realtime - this is fun stuff! ;o)

Thanks for making the changes to the LFO depths too. There seems to be a bit of a glitch around depths 32-33 and depths 95-96, but otherwise fantastic stuff. Thanks again TK!

I was thinking for backwards compatibility with patches made with older versions it might be good (but perhaps complicated to code!) to use one of the reserved bits in the LFO flags to set the new narrower depth.

I appreciate that the synth engine is already really loaded down with things to do. The MBFM for me is an already brilliantly flexible tool, the amount of control available is really expressive and empowering.

I think the fact that it is _so_ flexible means that it is much more easy it is to get wrapped up in dreams and wishes - I find myself thinking “hey, i wonder if it could do this, lets see if it can do that too, what about the other?” ;o)

For example: I’d love to be able to assign an LFO to alter the finetune frequency of a single operator to create patches that start out with a harmonic relationship between the operators, then gradually drift - leading to a subtlely shifting FM texture.

… like I said, it’s very easy to get wrapped up in dreams and wishes. ;o)

The only major problem I’ve been having with 1.1d_rc2 is with the SysEx message for storing back the current patch.

After sending a “RAM voice dump” sysex request, the next “RAM ensemble dump” request incorrectly reports the current patch loaded on a channel. This has a knock-on effect, since the “Store back the current patch” SysEx message will now store the patch in the incorrect location. I’ve lost a few killer patches this way. ;o(

Here’s how to reproduce the problem:

  1. Send Program Change 33 - Chan 1

  2. Modify parameters via CC - Chan 1

  3. Send Chan 1 RAM dump req (F0 00 00 7E 49 00 01 08 00 00 F7)

  4. Send PC 41 on chan 2

  5. Modify parameters via CC on Chan2

  6. Decide to save both patches but forget which patch was loaded on Chan 1!

  • could need to save at a different location if the old patch was also good

  • or could just overwrite

  1. Send Ensemble RAM dump req (F0 00 00 7E 49 00 01 78 00 00 F7)

chan 1 incorrectly reports 0

chan 2 reports 44

… etc

  1. Send overwrite sysex string for voice 1 (F0 00 00 7E 49 00 0A 00 F7)

  2. MBFM firmware incorrectly overwrites patch 0 not patch 33

  3. Send overwrite sysex string for voice 2 (F0 00 00 7E 49 00 0A 01 F7

  4. MBFM firmware correctly overwrites patch 44

I think this is happening because the RAM voice dump request in Step 3 requires that a bank and patch number be specified - even though they are not used (since the requests refer to RAM and not banksticks).  Since I use two zeros in the RAM voice dump request (F0 00 00 7E 49 00 01 08 00 00 F7), the ensemble in Step 7 reports back with these zeros - even though a the last patch to actually load into channel 1 was patch 33.

At the moment, I’m working around the problem by keeping a notepad to write down all the program change messages I send. Steps 6 and 8 are replaced by looking at the notepad, then re-sending the voice dump to a specific bank and patch location. …which is a bit crazy. ;o)

5

For example: I’d love to be able to assign an LFO to alter the finetune frequency of a single operator to create patches that start out with a harmonic relationship between the operators, then gradually drift - leading to a subtlely shifting FM texture.

Inharmonic frequency rations of course would be fantastic, but it is simply not possible with the OPL3 chip. It cannot detune single operators, and it only allows integer (except 0.5 of course) frequency multiplicators (0,5 / 1 / 2 / 3 …). That’s the OPL3 chip’s limitation - and its charm.