TK.

Stop! I'm not talking about the BankStick EEPROMs, but about the internal EEPROM, which is used as storage for global settings (like the router configuration). My assumption was based on the only case I can imagine for such a misbehaviour. But since it seems that you haven't overwritten the internal EEPROM with a special SysEx dump, I can only say: either there is an important point which you missed to mention, or something went wrong during the installation of the new firmware. Which MIOS version is installed? And did you receive any error message during the code upload of the new firmware? (Especially for the last parts at address 0x00F00200 .. 0x00F03FF ? Do you see the wrong values immediately after power-on when you enter the MIDI configuration menu, or are you doing anything else in between? Best Regards, Thorsten.

Hi, from the Wiki: Troubleshooting tips: follow this link http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

Alright! Could it be, that the MAX232 is stuffed? It should be removed when the normal MIDI In port is used Best Regards, Thorsten.

Hallo Lars, damit der Core defaultmaessig Daten ueber das MBHP_IIC_MIDI Interface sendet, muesstest Du noch den PIC ID Header modifizieren. Das geht am einfachsten mit der change_id Applikation, hier gibt es auch schon ein vorgefertigtes .hex file: iic_midi_10.hex Dass die BankSticks neu formatiert werden, ist leider normal, denn das Datenformat hat sich ja komplett geaendert. Vielleicht sollte ich auf meiner Homepage irgendwo darauf nochmal hinweisen, doch ich befuerchte, dass man solche Warnungen sowieso uebersieht. :-/ Dass die MIDI-Kanal Einstellungen verloren gehen, kommt mir sehr seltsam vor. Alle Einstellungen werden jederzeit direkt und permanent uebernommen. Koenntest Du mir eine kurze Anleitung schreiben, wie ich das reproduzieren kann? (wie wechselst Du den Track?) Wenn die Einstellungen resetet werden, koennte es aber auch daran liegen, dass der Song Modus aktiviert ist - leuchtet die Song LED? Funktionen sollten natuerlich nicht zufaellig angewaehlt werden (vielleicht bist Du so unabsichtlich im Song Modus gelandet?) - hat sich irgendetwas an Deiner Hardware geaendert? Vielleicht ein Wackelkontakt an den Leitungen zum DINX4 Modul? Du koenntest mal die MIDIO128 Applikation aufladen, und ueberpruefen, ob zufaellig MIDI-Noten getriggert werden. Drum Modus: den gibt es tatsaechlich noch, allerdings ist die Bedienung nicht offensichtlich. Man waehlt Event Modus 5 an (Vel/Vel/Vel), und drueckt die Taste unter "COPY PRESET" - nun kann man mit den drei Parameter Layern die Velocity einstellen, und mit den drei Trigger Layern die Gates steuern. Gruss, Thorsten.

If short execution time does matter (I think you mean: saving CPU performance for other tasks), time multiplexing is the way to go. "Very often": here it really depends which timing requirements you mean with "often" --- one microsecond, one millisecond, 10 milliseconds? The idea is: you won't notice a big difference when the LEDs are updated within 1 microsecond or 10 milliseconds, because they cannot switch so fast. So, why not using the same output pins for driving mutliple rows of LEDs - one row after another - so fast that your eyes won't regognize the difference. Here a link which gives a nice explanation: http://www.fpga4fun.com/Opto4.html, but I'm sure that there are also other ones, especially with AVR programming examples. For 512 LEDs you would use a 8x64 pin matrix (8 common lines it makes sense to add a big driver transistor here, as each common line has to sink the current of 64 LEDs at once!) Such a matrix would require 9 * 74HC595 - and this number of registers can be updated very fast. With the PIC propably within ca. 100 uS. You could update the LED rows from a timer interrupt which is called each millisecond. On each invokation of you time you would have set a new pattern for 64 LEDs, and select a new common line. With the effect, that all 512 LEDs are updated within 8 mS, but the CPU is only loaded by 10%. This is the way, how most of the LED multiplexing routines of MIDIboxes are working (e.g. MB64E, which can control up to 1024 LEDs this way) Best Regards, Thorsten.

Hallo, die Modulationsmatrix sollte auch ohne Stuetzkondensatoren funktionieren (wie bei mir), doch er tut natuerlich nicht weh - solange er nicht unbeabsichtigt so schlecht verloetet wurde, dass er einen Kurzschluss produziert. ;) Dem Fehlerbild nach zu urteilen ist irgendetwas mit der SC oder RC Leitung los. Diese geht zu allen DIN und DOUT Registern. Wenn hier ein Kurzschluss vorliegt, werden die Shift Register nicht mehr richtig getaktet, und zeigen somit zufaellige Muster. Am einfachsten lassen sich diese Leitungen mit einem Durchgangspruefer testen. Dazu alle ICs (auch den PIC!) aus den Sockeln entfernen! Alternativ kann man mit dem PIC auch 0V/5V auf die jeweilige Leitung legen, und die Spannung durchmessen - das geht mit der srio_interconnection_test_v1 (Info in main.asm lesen) Gruss, Thorsten.

Hi Daniel, I have to ask for some more details to get a clear picture. Are you planning to use MIOS routines to preload the DOUTs this way, or should be it an own (assembly based) routine? In both cases I think that this is the wrong way. The best way to control 512 LEDs is time multiplexing. So far I remember, I've a C based test routine for my 64 Duo-Colour-LED/button matrix somewhere on my harddisk, which can be easily extented for much more than 128 LED output functions. So, if this would help, I can publish it as a programming example. Best Regards, Thorsten.

Unfortunately the LTC module cannot be used as MIDI replacement for MIDIbox SID. It doesn't surprise me that you will see MIDI timeouts, as the whole synth engine is optimized for "slower" MIDI transfers (baudrate 31250), whereas 38200 used for RS232 transfers is definitely too much. Best Regards, Thorsten.

Yes, it is possible to add an Inc/Dec button instead of the rotary encoder (-> CS_MENU_USE_INCDEC_BUTTONS) which selects the patch by default (so long you don't press a select button to enter the root menu). But I'm sure that you won't be happy with this solution, as there are four instruments + 1 drum engine, makes 5 selectable patches. It's easier for you and especially more deterministic to select the patches via JSynthLib (-> ensemble page) or to send them via Program Change Best Regards, Thorsten.

Do you see these values really for all destination channels, or only for the IIC1 source? And did you upload an old EEPROM dump after installation of MBSEQ V3.2? Only this would explain the behaviour. In line 411 of seq_dump.inc, the "movlw 8" has to be replaced by "movlw 2*8", so that IIC1 routing definitions are stored. This is the reason why some definitions are not stored. But if you are not using the new IIC1 MIDI In, then this isn't really an issue for you, correct? The root cause why you see the invalid values could be, that the unusued EEPROM content is not preloaded with zeros from seq_preset.inc - this would only be a problem if somebody stores the EEPROM content via MIOS download request, and stores it back via MIOS upload. A proper solution will be available with the next release (I'm sure that there are more bugs in the firmware which need to be fixed - yesterday I found two ;-)) Best Regards, Thorsten.

Some more pictures are here now: http://www.midibox.org/forum/index.php?topic=9387.0 http://www.midibox.org/forum/index.php?topic=9388.0 The knobs are from a local shop in Munich. Best Regards, Thorsten.

The easiest and most secure way to MIDIfy a vintage poly synth is the use of reed relays. This has been proven today by Francois and me :) View with removed frontpanel - each key has a seperate pin, which is connected to -15V when the key is pressed. In parallel to these key->gate board connections, Francois has led through the inputs via ribbon cables: The backside of the synth with a nice view to the voice boards (sorry for the bad picture quality!) Core Module + 6 DOUTs stuffed with reed relays. Schematic can be found here: http://www.ucapps.de/mbhp/mbhp_doutx1_reed_relays.pdf The bottom of the vero board: After two hours all cables were soldered and tested. First checks with a MIDI keyboard and with MBSEQ V3 were very successfull! :) Hard to believe, but this was only the first of three Polysynths which should be MIDIfied! ;-) Best Regards, Thorsten.

This MIDIbox SEQ V3 has been built by Francois Buat. The flat case is really great and especially very stable. It fits nicely with desktop synths like you can see in the last picture ;-)

I had the possibility to test the DIN sync today with a TR808 while I visited a friend --- it works perfectly! :) MBSEQ/MBSID and TR808 are a good combination for a jam session, btw. ;) Best Regards, Thorsten.

Hi, welcome aboard! :) Yes, I collect the frequently made errors since years, they are all part of the MIDI troubleshooting guide: http://www.ucapps.de/howto_debug_midi.html In the meantime this list is quite complete - remaining issues are mostly just variants, where I must say, that I fully understand if a newbie is not able to qualify the effects. But therefore this forum exists, where you could get help if really required. :) Problem is, that most mailorder companies don't specify the crystal good enough. In general: parallel cut is what you are using for microcontrollers, serial cut is mostly used for RF circuits (analog stuff...) If a shop doesn't specify the type, it's mostly a crystal with parallel cut Core/OPL3/BankStick is fine! MBFM can be completely remote controlled with JSynthLib! Best Regards, Thorsten.

Thanks for the input! Seems that ACN really is a step forward. I especially like the clear separation between control and configuration part, so that each package type is optimized for its purposes. However, it depends on the audio software industry, if they are starting to support such a new protocol or not. And before this doesn't happen, it doesn't make much sense to build up a MBHP based infrastructure... At the technical side, you are right - such complex protocols shouldn't be handled by an 8bit controller, 32bit is a better choice. There are many ARM development boards available which support CAN (sometimes with multiple nodes for parallel networks), but there are also CAN-to-USB and CAN-to-Ethernet bridges (which are mostly ARM based as well...) Just got a quick idea: did you know that some Linksys routers are running under embedded Linux, and that the firmware can be easily modified - see also http://openwrt.org/ Assumed that there are some unusued IO or interface pins in this router, it could be possible to add a MBHP_IIC_MIDI or CAN controller interface to this device. It would be the cheapest MIDI->Ethernet or MBNet->Ethernet bridge ever --- and it would support WLAN by default ;-) Best Regards, Thorsten.

Two of the pictures can also be found on the midibox.org server: http://www.midibox.org/midibox_gallery/eufex3.jpg http://www.midibox.org/midibox_gallery/eufex4.jpg Best Regards, Thorsten.

One of the big advantages compared to MIDI is the replacement of strict data structures and MIDI channels. Take MBSID V2 as an example: the full stuffed version allows to run 4 multi engines, each multi engine controls 6 voices, makes 24 independent voices. But there are only 16 MIDI channels - so, not only that the user has to define suitable channels and keyboard splitzones (to overcome the channel limitation) - has has to do this at both sides (synth and keyboard/sequencer), which makes the handling difficult, inflexible and error-prone. With OSC you are working with pathes instead. E.g. voice #3 if SID2 could be addressed with /sid/2/voice/3, voice #6 of SID4 with /sid/4/voice/6 And now the power of OSC: by using wildcards, you can access a set of voices the same time, like: /sid/*/voice/* or /sid/2/voice/* What I don't like on OSC is (but I could have missed this in the past), that there is still no solution for a client to find out which parameters are supported by an OSC server. Or in other words: wouldn't it be nice if you plug a MBSID and MB64E together, and MB64E would automatically get a list of all parameters on a standardized way, so that you only need to assign the named and characterized parameters (resolution, center value, long and short name, button behaviour) to the faders, knobs and buttons? And that the same would work, when you select other servers from MB64E like your favourite host sequencer or VST instrument without changing the cabling? If such features would be supported by the protocol, it would be a killer argument against MIDI. So, does anybody know more about this topic? Best Regards, Thorsten.

It isn't possible to support continue, you can connect it to ground. Start is the same like Start/Stop or like Run. The signal is 1 when the sequencer is running, and 0 when it is not running. This matches with the description I've found about this sync input at various websites... Best Regards, Thorsten.

the same issue exists when the SID is controlled from a C64 of course. It also exists on other SID synths, like the SIDstation, and people have learned to live with this... Have you ever heard the background noise we are talking about? ;) I mean - the s/n ratio is about -60 dB on a 6581, and ca. -90 dB on a 8580 (depending on the quality of the PSU), therefore you only notice it when the SID is silent (which was not the case in C64 tunes ;)), and when the audio output is dynamically amplified, e.g. with a compressor. But there are simple Fx (e.g. VST) based solutions without need for additional hardware to remove the background noise completely if desired. Also - if a compressor is used, tweak on the parameters (keyword: knee) so that at a certain silence level the output won't be amplified. I for myself mostly don't use such measures, there is just no real need for this -> in the mix <- Therefore I don't understand the endless discussions about alternative, more complex and more expensive solutions. I also don't know, who should document and support all these solutions... However, if this is a 50 Hz buzz, then it is another problem of course. Have you grounded the unused audio in channel? (strongly suggested) Best Regards, Thorsten.

OSC is a protocol like MIDI, there is no need for using python in order to convert messages, you can just send them directly to the host, e.g. via ethernet; you could also use an alternative interface, like CAN, USB or similar. But as most computers are stuffed with an ethernet interface today, and in OSC host applications this interface is also prefered, it's the first choice. Best Regards, Thorsten. P.S.: for LiveAPI it seems that OSC is only available through the python interface, but I haven't digged so deep into the docs (not really interesting for me...)

I'm sure that OSC has a future, and I'm also sure that there will be MIDIboxes with ethernet support sooner or later. It could even be possible to connect an external ethernet controller like the ENC28J60 to a common core module to prevent a major hardware re-design. But I fear that for a decent application which satisfies all the request we normaly get from you guys, an 8bit controller is not sufficient. In this special case (complex controller which supports OSC) maybe an ARM based microcontroller with Embedded Linux installed would be fine and easy to handle... However, for simple OSC controller applications the PIC could still be sufficient. Best Regards, Thorsten.

We had this suggestion many times, but my assumption is: when somebody asks such generic questions, it will be very difficult for him to build and setup external DACs and VCAs Such an option will only be supported by MBSID V2 anyhow (see the appr. postings about external outputs) But to make it short: it's still a tinkering solution - it especially won't work on multi or drum patches Better solution: use a 8580 or 6582, or some Fx VSTs like an envelope follower or noisegate (like you mentioned) Best Regards, Thorsten.

Yes, of course. But MBCV also provides a more generic way for requesting and sending dumps: a) F0 00 00 7E 48 <d>1 F7 Request a Dump <d> = device number (0-7) b) F0 00 00 7E 48 <d>2 <dump> F7 Write a Dump <d> = device number (0-7) <dump> = 512 bytes dump data [/code] It's the same format which is sent out when you press the SELECT button within the SysEx menu page With a common sequencer (only tested with Logic) you can record and replay such a dump. Normaly I'm doing it this way: start record, go into SysEx menu, press SELECT - done Once you playback the track, the configuration will be sent to MBCV, and it will update the internal parameters automatically. Best Regards, Thorsten.

Hi Toby, the 3 multiplexer control lines of the two AINX4 modules have to be connected together like shown in this schematic: http://www.ucapps.de/mbhp/mbhp_ainx4_64pots.pdf It doesn't matter, if you link them at the AIN module, or core module side. Only the electrical junctions are important. :) But the control lines should not be connected to J7 of the core module, this port has another purpose Best Regards, Thorsten.