TK.

There is a new MIOS Studio Version available, which supports uploads to code memory range >64k http://www.midibox.org/mios_studio/MIOSStudio_beta7_5.jar.zip Best Regards, Thorsten.

Now, this is interesting! I should consider to overwork the schematic Best Regards, Thorsten.

In the meantime USB interfaces are so cheap, that it doesn't make a difference if you are using a DIY unit or not. Some commercial interfaces have the advantage, that they are not using the legacy MIDI USB driver of M$ - accordingly they are mostly multi client capable, thats a big plus I'm not planning to try other chips... the PIC18F4550 desaster was already frustrating enough, and answering requests like "could you please make it available", "why not trying another chip" do frustrate me even more, because I don't need this interface for myself, I don't want to spend the time for additional support effort if the interface doesn't work with the exotic windows version somebody is using, and I've a lot of other interesting projects in the queue. Best Regards, Thorsten.

Hi, I remember, that somebody else had similar problems with a switching power supply. What kind of PSU are you using, and does the v_mf voltage change when a fader is moved? Best Regards, Thorsten.

bit #0 should set the leftmost LED (D7) on a common DOUTX4 board - this mirroring has historical reasons Best Regards, Thorsten.

Great!!! :) (because I was really out of ideas ;-) Best Regards, Thorsten.

Hi Simone, sounds, like there is a problem with the shift register. See this troubleshooting page for debugging instructions: http://www.midibox.org/dokuwiki/doku.php?id=din_module no, the 1st level bootloader will always send this request at startup - no problem. thats not correct, "00" is an invalid SysEx command and not sent under normal circumstances. Where did you read this? Maybe a typo Best Regards, Thorsten.

Hi Radek, it's already finished, but not available for public. Best Regards, Thorsten.

No, a special configuration is not required to get the buttons working. The random behaviour on stop button changes indicate, that there is a problem with the shift register connections. A troubleshooting guide for the DIN registers can be found here: http://www.midibox.org/dokuwiki/doku.php?id=din_module Hope it helps - if not, just write about your observations during the tests. Best Regards, Thorsten.

This "bug" has been declared as a feature ;-) You will find these addresses in the specification, and MBFM uses translation tables based on this spec in order to address the operators correctly. But note also, that MBFM uses the OPL3 in 4 operator mode only, 2 operator mode (which would result into more voices, but also with less quality) is not supported! Best Regards, Thorsten.

The resistances are ok, the intention of this test was, if you get 0 ohm (-> short) or a high resistance (-> ok) I don't know the typical resistance, I never take care for such details, and it differs with the used parts anyhow (as you already noticed) The transformer connections you made are still unclear to me, but the problem is, that so many transformers look so different. I cannot really help you here, only motivate to continue with experiments. E.g., you could doublecheck if the center cable is really the center cable by measuring the voltages between the 3 transformer outputs. The voltage difference between this cable and the outer should be 12V, the voltage difference between the outer cables should be 24V Best Regards, Thorsten.

I don't see an error on your PCB. Does the trouble start once the PSU is connected to the MBHP_OPL3 module, or did you measure the voltages before doing this? The +/-12/Ground tracks on the MBHP_OPL3 module can be checked very easily against shorts if you have a multimeter or similar. Just check the resistance between the tracks, or use it as a logic tester (if this mode is available), and check for unexpected "beeps" (=short) Best Regards, Thorsten.

In general please note, that live record mode currently only supports monophonic notes - so in fact only Event Mode #1 (Note/Vel/Len). Recording polyphonic notes or CC is planned for future versions (as it will require a lot of work). The usecase you are mentioning here is working like expected (I just have checked this again). You have to consider, that a) like mentioned above, only a single note is recorded, and this is the base node passed to the arpeggiator b) a loopback track should have a higher priority, so that on a step change a new note is played, before the next track plays a note based on this input. Example: transposed track#1, loopback track#2 [tt] 1: C-3 C-3 C-3 C-4 C-3 C-3 C-3 C-4 2: C-3 --- G-3 --- C-3 --- F-3 --- [/tt] The sequencer will play: [tt] C-3 C-3 C-3 G-4 G-3 C-3 C-3 F-4 [/tt] which is wrong, because the transponation is one step too late When the loopback track is located at Track 1, it will work like intended: [tt] 1: C-3 --- G-3 --- C-3 --- F-3 --- 2: C-3 C-3 C-3 C-4 C-3 C-3 C-3 C-4 [/tt] Output: [tt] C-3 C-3 G-3 G-4 C-3 C-3 F-3 F-4 [/tt] For an arpeggiator loopback, event mode #4 (Note/Note/Note) with a high clock divider value (e.g. 96ppqn/64 = 1 measure per step) is the better choice. In this event mode live recording is not working! I would say it's an imperfection, and not a bug. It's related to the way, how the LCD screen handler overlays the current menu page when the track view is temporary displayed. I'm aware that this sometimes doesn't work without artefacts in the screen, but a solution is not so easy to realize here (clearing the whole LCD screen on page changes costs a lot of time - this is a LCD hardware issue, it inserts busy cycles), and I think that the impact on the usability is low. Best Regards, Thorsten.

Any PSU which delivers a bidirectional voltage will work. You could even supply the OPs with +/- 9V or +/- 15V. Have a look into your 1U racks, maybe there is already a suitable PSU which you could canibalize? Nobody else reported an error in this schematic in the past. I don't know, what should be wrong there. Did you cross-check your circuit with the PCB of Talion? It is a nice reference! I hope that I haven't clicked on the delete button by fault. I remember that I did this some months ago in another posting when I moved my mouse under unstable conditions (on my sofa ;-) too quickly. But I noticed this immediately. What I want to say: if I removed your posting unintentionally, please don't take this personally! When did you write your posting? If it was before 2007-02-11, ca. 18:00, I'm sure that it wasn't my error... Best Regards, Thorsten.

I remember that I enjoyed your two live recordings months ago. Do you offer new ones for free download in the meantime? :) Best Regards, Thorsten.

Unfortunately yes - MIDI data forwarding is the easiest way to reproduce the EUSART bug. :-/ But the MBHP_IIC_MIDI module could be advantageous for your sequencer anyhow, as it allows you to add independent MIDI ports for different MIDI devices (no MIDI channel assignment trouble). Also the bandwidth is higher, because MIDI events can be sent to different devices in parallel. However, so long only your small PC sampler is connected, this doesn't really matter - just an idea Best Regards, Thorsten.

Please don't add the fuse to the high-voltage lines, this is too dangerous (especially when the sockets are not isolated). Only add them to the 12V lines Best Regards, Thorsten.

I think it doesn't matter, which ~ pins you select. I made a quick diagram just to ensure: By exchaning the ~ pins (difference between left and right circuit), from the electrical point of view nothing will change. It's like if you would flip the diodes at the vertical axis. Since the bridge is symmetrical, you would see "the same picture" I highly recomment to add fuses to the AC lines. A short circuit at the DC side could not only blow up the bridges, but also other components! Best Regards, Thorsten.

Look at these beautiful cases - if you haven't already found them in Artesia's Blogs: http://www.midibox.org/forum/index.php?topic=7854.0 http://www.midibox.org/forum/index.php?topic=5818.0 Combined MIDIbox SID/FM MIDIbox SEQ Beautiful! :)

And it looks extremely solid! Great! :) Best Regards, Thorsten.

Hi Matthias, yes, this was the reason. The transformer has to be connected to the AC inputs Best Regards, Thorsten.

Fast alle Befehle sind in 16bit codiert, manche auch in 32bit. Es gibt Prozessoren, die mehr daraus machen... ;-) Gruss, Thorsten.

Na das ist doch mal wirklich ein brauchbares Feature! Sobald alle Listen eingegeben sind, werde ich die Links in meine Homepage einbauen :) Gibt es dafuer auch Bonusmeilen? ;-) Gruss, Thorsten.

An dj3nk: was soll das? Dein Verhalten ist fuer mich absolut unverstaendlich! Ich bin ich kurz davor, Deinen Account zu verbannen, denn Leute wie Du haben hier im Forum nichts zu suchen! Gruss, Thorsten.

A single OPL3 already provides so many voices, that there are 4 independent instruments + 1 drum channel available. This saves you from building 4 core modules, and I don't think that you really need much more than one OPL3 in your setup. The number of knobs was my design decition, the firmware isn't prepared for more. But you can add a MB64E before MBFM if you want, the available CC parameters are documented on the website. This adds a latency of 1 mS Best Regards, Thorsten.