TK.

I like the idea to vary the gatelength for controlling an envelope, but I can also say, that the current implementation is not sufficient for that what you are planning. The gatelength of a step is quantized into 24 microsteps, derived from the internal or external MIDI clock. In order to improve the readability, the MBSEQ doesn't display the number of steps, but the relative gatelength in percent (4%, 8%, 13%, 17%...100% and Glide). There is no 0% as 0% means no gate (trigger switched off) This quantisation is perfect for common patterns, as it scales with the BPM. But I think that you are searching for a way to enable the gate for a specific time. E.g., from 1 to 127 mS in steps of one mS, independent from the BPM, and maybe controlled with the velocity (advantage: when an event layer is setuped for Drum mode, you can control 3 drumlines with variable velocity from a single track) Best Regards, Thorsten.

What I mean: I just have removed the comment about the compatibility from my webpage, because it is obsolete. I wrote this 4 years ago, where most of my projects were running on a PIC16F877 with a totally different firmware. Ok, I see that I'm not the right person who could help you... Ignorant: it seems that this word has a different meaning in english. Thats funny. Not sure how many times I wrote it for a totally different purpose. ;-) Best Regards, Thorsten.

removed hint (prehistoric comment from 2003) No more time to answer all your questions - sorry, I'm an ignorant guru. Best Regards, Thorsten.

Dass auch ungueltige Werte im Pattern landen koennen, ist ein wichtiger Input. Somit muss irgendetwas im Flashspeicher korrupt sein, denn es gibt keine Routine, die bspw. den Event Mode auf 16 stellen wuerde. Zur weiteren Auswertung braeuchte ich mal einen kompletten Speicherabzug von Deinem PIC. Den koennte ich dann bei mir aufspielen, und naeher untersuchen. Am einfachsten laesst sich der Dump via MIDI-Ox erstellen: SysEx Fenster oeffnen, folgende Zeile in das Command Window pasten: F0 00 00 7E 40 00 01 00 00 20 00 F7 und mit Command Window->Send/Receive SysEx den Transfer starten. Im Display Window werden 37896 Bytes empfangen, diese mit Display Window->Save as.. in ein SysEx file abspeichern (bspw. flash_0.syx) Dann die zweite Haelfte requesten mit: F0 00 00 7E 40 00 11 00 00 20 00 F7 und in flash_1.syx abspeichern. Zusaetzlich vielleicht auch noch einen Dump vom internen EEPROM machen: F0 00 00 7E 40 00 01 20 00 01 00 F7 und in eeprom.syx abspeichern an tk@midibox.org schicken. Die MIDIbox wird nach einem Dump neu gebootet - keine Panik, das ist normal ;) Gruss, Thorsten.

Francois: maybe you remember, that we modified the AOUT module for your polykobol to a voltage range between -5V..+5V - you could use it for the PS3100 now, just upload the MIDIbox CV firmware to the core module, which is currently in the IBM box ;-) Sooner or later, we could modify the firmware, so that it can control the DOUT + AOUT module - only one core would be required anymore, and the second core is free for some other MIDIfication stuff ;) Best Regards, Thorsten.

Hallo Lars, Das war vielleicht der entscheidende Hinweis - koennte es sein, dass die Track-Gruppe von G1Tx auf G2Tx, G3Tx oder G4Tx (x=Track Nummer) wechselt? Dann wuerde es an der F4 Taste legen, mit der die Gruppe umgeschaltet wird. Diese Taste hatte in der alten Firmware noch keine besondere Funktion. Druecke mal mehrmals die F4 Taste - kommen dadurch die alten Einstellungen wieder zum Vorschein? Falls die F4 Taste nicht funktioniert (Wackelkontakt oder Kurzschluss?), kannst Du die Gruppe auch mit Encoder #1, oder mit gehaltener Mute-Taste + GP 1..16 Taste wechseln. Gruss, Thorsten.

I can only strongly suggest to spend some more effort into the planning phase, and especially to do some programming evaluations before building up the complete LED matrix in order to find out the best performance solution which meets your requirements (which are still a little bit unclear to me... however :)) Just for the records - this is how a 8x64 = 512 LED matrix could be controlled from the MIOS SDCC wrapper: // LED pattern array - prepared for 512 LEDs (=64 bytes) unsigned char led_patterns[64]; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS before the shift register are loaded ///////////////////////////////////////////////////////////////////////////// void SR_Service_Prepare(void) __wparam { static unsigned char row_ctr; unsigned char i; // increment counter on each cycle, wrap at 8 row_ctr = (row_ctr + 1) & 0x07; // select LED row, the appr. DOUT is the 9th shift register in the chain MIOS_DOUT_SRSet(8, 1 << row_ctr); // init pattern of DOUT 1..8 (= 64 outputs) // offset depends on row_ctr for(i=0; i<8; ++i) MIOS_DOUT_SRSet(i, led_patterns[row_ctr * 8 + i]); } [/code] So, there is no need for a special timer, as the update cycle of the SR upload is already interrupt driven by a timer resource. Just to highlight it again (for the case that you change your decition): such a LED matrix, where one shift register controls the common line of so many LEDs (64 per row) definitely requires a transistor on the 9th DOUT (where the common lines are connected) Best Regards, Thorsten.

It's the toggle function which you need to activate. It can be done for each button seperately. You could do this from the menu interface (go into MIDI learn mode and press the SELECT button to change the button mode before a new MIDI message is learned), or if you want to use the mk_syx.zip script, write @Toggle instead of @OnOff I believe the button behaviour can also be changed with Serge's editor... so there should be multiple ways which are worth for trying out :) Best Regards, Thorsten.

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.