zenpho

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 7. 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 8. Send overwrite sysex string for voice 1 (F0 00 00 7E 49 00 0A 00 F7) 9. MBFM firmware incorrectly overwrites patch 0 not patch 33 10. Send overwrite sysex string for voice 2 (F0 00 00 7E 49 00 0A 01 F7 11. 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)

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)

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)

Well I had a go at quickly testing this last night, tried voices 1-4, and ensembles too. Everything seemed to work without a hitch. I forgot to test the drums tho, but I'll get on that and let you know if there are any problems. I like how you've made the sysex command have separate sub-commands to address each voice. It's also neat how the Request/Write Dump and Direct Parameter Write commands also work with these numbers. I was imagining a more general "store the current patch on this channel" message, but I think this is more flexible. It was certainly good foresight to keep the ensemble references way up in the 70 and 78 range and the drums in the 10 and 18 range. Good thinking! I am still very interested in setting up a build environment such that I can make modifications to the MBFM code to get those drum maps - perhaps I'll post another thread on this when I get started. I'll no doubt be needing some guidance. ;o) Thanks for this mod again TK, it's much appreciated.

Awesome! I was expecting that you'd just point me at the places in the code that I should begin modifying, and leave me to chugg away. ;o) Thanks so much for this sir. I'll give it a try in a moment and let you know how I get on. Its very groovy of you to make an addition on request. hehe, classic! like this? http://www.cnet.co.uk/i/c/blg/cat/blog/off_switches/2.jpg

Thanks for the super-quick reply TK, much appreciated! That's perfect! ;o) I don't have a DIN board made, so I think a combination of "a MIDI event" and/or "SysEx" would be a good place to start, maybe I'll build a DIN board with "patch up/down" and "overwrite" buttons later tho. I remember from my limited experience in programming TexasInstruments DSP chips that triggering via an interrupt (i.e a pin directly on the PIC) ought to be simple in PIC assembly, but I'm not sure how to trigger it via MIDI or SysEx events. I don't think I'll need to store drum or ensemble parameters, maybe later tho. My idea is to slowly modify existing patches beyond recognition so it'd be perfect to overwrite the current patch (i.e the last recalled patch via ProgramChange). I can always restore the original patches by dumping SysEx back into the MBFM when I'm back at the computer. I only have one bank stick so it's tempting to hard code the bank to be "0" but if I add more banks I think it'd be perfect to overwrite the patch in whichever bank was last accessed. Do you mean how to name them, like in the first few bytes after the patch/bank of the SysEx dump? Probably best to keep the same name for now, although maybe I'll replace the last character byte of the name with a "*" or something? Not sure how I'd do this with PIC assembly tho! ---- At the moment, I'm just reading the .inc files in my favourite text editor, but I'm not sure how to turn them into PIC code. I've discovered http://www.midibox.org/dokuwiki/doku.php?id=windows_toolchain_core but it looks like things could get quite convoluted in order to modify a few lines of code! Maybe I ought to save up some of my other wishes before I make tweaks. (like custom drumkit maps which detect note numbers and load in percussive patches from banks before actually triggering the notes) ;o) Thanks again for helping sir - very much appreciated,

Hi there, I built a very minimal Midibox FM (box with midi+audio sockets and psu) a while ago, but I didn't build a control surface and I've been having some trouble with the JSynthLib editor (see http://www.midibox.org/forum/index.php?&topic=11662). Ever since I laid eyes on the MidiboxFM project and saw that each register on the OPL was mapped to a midi CC for realtime parameter tweaking, I've been wondering if I could hook the MBFM directly to my Edirol/Roland PCR 500 to control a few key parameters for on-the-spot patch generation without a computer. Only one problem: After tweaking a patch by sending various CC messages, I can't save it into the bank stick. I've looked at the documentation and I can't immediately find an answer for this problem. The sysex implementation textfile only mentions dumping an entire patch explicitly, i.e all parameters in one sysex blob. Is there a sysex command that will tell the MBFM to "save the current parameters to a bankstick", without having to keep a copy of every parameter and then send a complete sysex patch dump? I wonder if this isn't implemented because of the way the MBFM MIOS program is programming the OPL. If the OPL registers are "write only" and MIOS isn't keeping track of all the parameters, then there's no way to collect all the information for a patch back up into a bank stick. If this is the case however, how does a full MBFM with control surface save the current parameters to a bankstick? Perhaps only parameters edited with the control surface get stored by the MBFM MIOS program? I wonder if I built a control surface, could I still tweak the parameters by CC then save the patch to bankstick? Any help greatly appreciated, Thanks!

Hi again, Thanks stryd_one, good detective work on digging out the old style bank-stick request message. It all makes sense now! ;o) I wonder how easy and safe it is to downgrade MIOS? Maybe it'd be safer to stick with it almost-working.

Thanks for the help stryd_one, good idea! Here's a dump from JSL (2006 snapshot): F0 00 00 7E 49 02 00 00 00 4E 65 77 20 50 61 74 63 68 20 20 20 20 20 20 20 01 00 00 00 06 01 0B 01 01 00 00 00 28 37 14 37 00 00 01 01 00 0C 0A 0D 07 09 04 07 05 09 0A 09 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 05 00 50 40 40 40 40 40 40 40 00 00 00 40 40 00 05 00 70 40 40 40 40 40 40 40 00 00 00 40 40 00 00 20 60 20 20 20 40 20 40 40 40 40 40 40 40 40 02 00 00 00 40 02 00 00 15 17 52 00 00 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 F7 And Here's a dump from TL's tool: F0 00 00 7E 49 00 02 00 00 00 4E 65 77 20 50 61 74 63 68 20 20 20 20 20 20 20 01 00 00 00 06 01 0B 01 01 00 00 00 28 37 14 37 00 00 01 01 00 0C 0A 0D 07 09 04 07 05 09 0A 09 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 05 00 50 40 40 40 40 40 40 40 00 00 00 40 40 00 05 00 70 40 40 40 40 40 40 40 00 00 00 40 40 00 00 20 60 20 20 20 40 20 40 40 40 40 40 40 40 40 02 00 00 00 40 02 00 00 15 17 52 00 00 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 F7 It seems that there's a missing byte between the MBFM SysEx ID byte "7E 49" and the patch dump byte "02". ---- I think I may have found the source of the problem tho, JSL is routed through MidiOx and MidiYoke - but TL's tool is routed directly to the MIDI interface. I remember routing JSL through MidiOX because a page on the midibox ucapps site mentioned a bug in Java, easily corrected by routing MIDI in this way with the added bonus of being able to monitor the bytes sent from JSL in the MidiOX monitors. I noticed that the MidiOx monitors were showing the sysex dump broken into two sections - one of 256 bytes, and another of 12 bytes! Some investigation revealed "low level SysEx buffer" options in MidiOx which were set to 256 bytes with a delay of 60msec between buffers. Increasing the size to 268 seems to solve the problems. JSL now sends and receives patches without failure! I guess the MidiOx buffers were missing out bytes in that 60msec pause. Interestingly: reducing the delay to zero didn't solve the problem, and reducing the buffer size to 64 bytes produced some very interesting (broken) messages in the MidiOx monitors, sysEx messages missing their F0 and F7 markers, random splurges of hex numbers, all sorts of digital nonsense... ;o) ---- One last problem tho. JSL (2006 snapshot) still doesn't receive a Patch Bank - JSL sends: F0 00 00 7E 49 00 03 00 00 F7 and the MBFM replies with F0 00 00 7E 40 06 0E 0B 00 F7 (parameter not available) Interestingly, the reply isn't from the MBFM layer, it has a MIOS "7E 40" SysEx ID. Shouldn't JSL be sending a bunch of F0 00 00 7E 49 00 01 00 <patch> F7 messages with <patch> increasing from 00 to 7F?

Hi there, I built a midibox FM recently, and I should say that I'm extremely grateful to TK for being a groovy kinda guy and making his midibox projects available for people like me to build so openly. Also thanks to SmashTV for organising PCB fabrication for the core and OPL boards that make up the MBFM, and to the midibox forum community in general (where I lurked most heavily before populating the PCBs). ---- Unfortunately, I'm experiencing some strange problems with using Jsynthlib to edit and store patches on the MBFM. I built and tested the core board sucessfully, uploaded MIOS (v1.9f), and the MBFM program (v1.1a), tested that the default patch works successfully, plugged in a 256 bankstick, and loaded up Jsynthlib. I set up Jsynthlib (JSL) to work through MidiOx and MidiYoke. The Synth driver page of JSL shows: SynthID: FM Device: MIDIboxFM MidiIN: from MIDI Yoke 2 MidiOUT: from MIDI Yoke 1 Channel: 1 DeviceID: 1 The routing page of MidiOX shows: [Midi Yoke 1: IN]---------------------------[uSB Audio Device: OUT] [uSB Audio Device: IN]----------------------[Midi Yoke 2: OUT] [MidiOX Event Port]-------------------------[Midi Yoke 2: OUT] The USB Audio Device is a (cheap, but working) Alesis IO/2 interface. ---- I tried the version of JSL (Snapshot-2006-01-28) on the MBFM page first, since it mentions that it was tested for compatibility with the MBFM specifically in order to fix a bug uploading patches. Unfortunately, it still seems to have a problem uploading patches. I load JSL, load the midibox_fm_presets.patchlib, click the PatchBank (containing default voice patches), pick "Store" - selecting "bank A" JSL thinks for a while whilst MidiOx shows a number of Sysex messages being sent - followed by replies from the MBFM. Unfortunately, looking at the MidiOx input monitor, after every patch dump output from JSL, the MBFM responds with an error message: F0 00 00 7E 49 00 0E 01 F7 Which, looking at "midibox_fm_sysex_implementation.txt", translates as: "received less bytes then expected". ---- I tried JSynthLib-0.20.0_midibox_mod1 (linked from a thread in the forums) - same error "F0 00 00 7E 49 00 0E 01 F7" == "received less bytes then expected". ---- I also tried JSynthLib-0.20.0 (from the JsynthLib sourceforge page) in a vain hope that maybe it would succeed - but this also didn't work. Same error. ---- I finally managed to upload the default patches by using TL's MidiboxPatchManger (MBSIDPatch-0.8.exe) - loading the "midibox_fm_voices.syx" resulting in the response: F0 00 00 7E 49 00 0F F7 which translates to an "acknowledge" message. I can receive the uploaded patches with JSL (Snapshot-2006-01-28) again, and all the patchnames and data seem to show up okay. This, to my mind, seems to narrow down the problem to JSL sending data. Anyone here have any ideas what to do next? I'm wondering if this is a purely software issue, but then how come nobody else is posting similar JSL problems... I'm at a loss. Cheers, -Zenpho