TK.

Hm, I just tried the suggested MIDI-Ox settings and noticed the same. I'm sure that this worked under WinME, but I updated to WinXP some days ago... so, maybe the MIDI-USB driver of WinXP is worst than the one from WinME :-/ Problem: this is not in my hands... take a look into the MBHP_USB sources and you will notice that the code is very primitive. Most of the work will be done by the Operating System itself. Which windows version are you using? But: I also tried Serge's vmidibox and there the download works fine with 100 bytes/s See also the MIDIbox64 ChangeLog: Best Regards, Thorsten.

Thanks Doc, this layout has been made by Marfurt Cyrill, I will inform him about the error and upload your file instead. Note: the LED digit extension for MBLC is in beta state now, I'm not able to test it, so I'm waiting for input from D2k, who will try it out. Schematic: http://www.ucapps.de/midibox_lc/midibox_lc_leddigits.pdf Best Regards, Thorsten.

This remembers me that vmidibox transfers the data in a "dirty" way. Since the SysEx handler of MIDIbox64 requires delays between every single byte (data will be written into EEPROM on-the-fly and every write access needs ca. 5 mS), but the M$ API doesn't provide such a function, Serge uses a trick to achive the delays. Maybe it doesn't work with newer Windows versions anymore? Could you please try the transfer of the .syx file with MIDI-Ox? You can write out this file from vmidibox64 The required MIDI-Ox SysEx settings: Best Regards, Thorsten.

I'm pretty sure that MBHP_USB works fine ;-) Sorry, but with such incomplete informations I cannot help you. After your first posting I assumed that you are trying to upload a new firmware, but now you are writing that you are using the vmidibox to upload the MIDIbox64 bank... Please write down every detail which could be useful to understand what is going on with your setup (you don't need to start a new topic for this...). I (or somebody else) will give you an answer if anything sounds like a configuration or hardware problem. If you get no answer, then try to find out more details (e.g. use another program to upload SysEx and keep in mind that the MIDI-Ox configuration for uploading banks is completly different than the configuration for uploading a firmware) and report it here (again: no new topic, use this article so that everbody know the history of your issues...) Best Regards, Thorsten.

You are using the wrong timing parameters: Best Regards, Thorsten. Addendum: after an invalid download it makes sense to try it with the "first level bootstrap loader", which is active during the first 2 seconds after power-on, because it can happen that the second level loader is blocked due to invalid application code.

Nun, eine 8-kanalige CV Out Erweiterung wird seit v1.6alpha1 unterstuetzt (siehe http://www.ucapps.de/midibox_sid_changelog.html), wobei sie in Zukunft noch ein bisserl komfortabler eingebunden wird. Fuer CV Ins sehe ich prinzipiell keine Probleme, man koennte bspw. in sid_ain.inc einfach die analog-Werte an die SID_CCIN_Set Funktion weiterleiten oder (besonders komfortabel) speziell an die Funktionen fuer Modulation Wheel/Aftertouch/Velocity. Vorteil: auf diese Weise koennte man dann die CVs bequem zu den CCs routen, sowie den Initial- und Depthwert (Positiv/Negativ) vorgeben --- ist ja alles bereits eingebaut, muss man nur nutzen ;-) Gruss, Thorsten.

Dieses Modularsystem ist polyphon ausgelegt, und jede Modul-Einheit hat etwa 32 Parameter. Wir wollen die Module einzeln ansteuern. :) Gruss, Thorsten.

Could somebody please write a beginners tutorial which answers such basic questions about the various options which can mostly be found in main.asm - because it's really too much effort for myself to write not only the program code, but also to describe the behaviour of such minor features again and again (which mostly consumes more time than the programming!) Sorry Christoffer, hope that you don't feel offenced, I don't want to left your question unanswered, but I also want to let you know that you could try to find out the purpose of those funny numbers at the end of the #define statements by yourself. And then you could think about the reason, why such minor features cannot be found in a schematic which describes the basic requirements for a control surface. Best Regards, Thorsten.

Hi, as I already wrote, the MBSEQ will finally provide 16 tracks, but only 4 which can be edited live. The others are played directly from EEPROM. Switching between different patterns (e.g. during Song mode) won't affect the timings, but writing into EEPROM - thats the only limitation. However, for live playing it's cool to have some additional tracks (e.g. Arpeggios or transposed CC sequences) in background, normaly you won't edit them all at the same time during a performance. And in the (home)studio - when preparing songs - it doesn't matter... Of course, MBSEQ can also be daisychained and synchronized via MIDI clock. Every core can run standalone without control surface - so, every additional core gives you 16 additional tracks. Groove: yes, the groove parameter is continuously variable and can be changed with the datawheel. The tracks never get out of sync when changing the groove parameter in realtime (this was the most difficult part, but finally solved). Groove works also with external clock, the MIDI clock will be quadrupled by some kind of software implemented PLL (phase locked loop). I've prepared 16 different groove styles, but currently only "shuffle" is implemented. I need your input (mathematical formulas) for more different styles. Thanks for the suggestion for drum editing, I will think about this. In fact everything is prepared for such features, becaue it would also mean to introduce a new layer type, which then has to be assigned in the "Layer Assign" menu. There is also enough room for such features, only problem is my available sparetime. ;-) Maybe important to say this: I'm planning an initial release in some days which will provide the most important features and which will especially support all the hardware options, so that people (who like beta version adventures) will have concrete informations about the hardware and can begin with building their boxes. This version won't support all features which I've agreed here. Not because the implementation would be impossible or difficult, but because I've already a lot of effort to documentate the project and need to decide which functions are really essential for a first release, and which could be programmed and documented later. Only after the initial release I can tell you, which features can be added, to the main version, which could be provided as alternative option, and which have to be programmed by somebody else. When you follow the MIDIbox SID project, you know that "planned feature" can mean: sometimes you've to wait for one day, sometimes for 6 months, sometimes for one year or more... ;-) Best Regards, Thorsten.

Thanks Chriss! :) yes - the CURVE parameter is unexplored territorial, I see a lot of potential for fresh new SID sounds :) CC names: they are allocating too much internal memory (more than 1k), which should be free for upcoming features, therefore I've disabled the strings. Sooner or later I will provide an option which allows to store these strings in an external BankStick. By doing this, the strings could also be longer than 12 characters and therefore more readable Best Regards, Thorsten.

Just another blind change added (-> cs_menu_exec.inc), main.hex and main.syx are up-to-date again Best Regards, Thorsten. /edit: last change for today in cs_menu_exec.inc and cs_menu.inc (this time not "blind" ;-)

Hallo, vielleicht kann ich in ca. 1-2 Monaten mehr zu diesem Thema beitragen. Ich bastel gerade zusammen mit einem Analog-Freak an der MIDIfizierung von einigen Synthesizern (darunter auch ein etwas komplexeres Modulsystem mit ueber 128 CV Ein- und Ausgaengen *aechz*), dabei wird spaeter auch ein Keyboard-Scanalgorithmus abfallen, den ich als Software-Driver veroeffentlichen werde (der sich dann in beliebige Applikation integrieren laesst) Gruss, Thorsten.

See the release notes: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1048462029 Best Regards, Thorsten.

why not... ;-) (I've added a comment into the source file) Best Regards, Thorsten.

fixed. Best Regards, Thorsten.

Hallo Carsten, weil ich sowieso gerade an einer neuen Alpha Release rumgebastelt habe, konnte ich die CBM8580 Jumper option noch schnell mit reinbringen. > Mit deiner Hilfe hat auch das genialste Remake laufen gelernt- ML303 die Bassline. Freue mich uebrigens schon auf den Giftzwerk! :) Gruss, Thorsten.

Hallo, MIDIbox SEQ kann das meiste schon, und die Dinge, die sie nicht beherrscht (bspw. Step Programming) koennte ich evtl. in einer spaeteren Release beruecksichtigen. Nun moechte ich das Projekt erstmal in trockene Tuecher bringen, deshalb bin ich bezueglich neuer Feature Requests leider erstmal nicht mehr aufnahmebereit. Die Firmware wird uebrigens auch eine Sparvariante der MBSEQ mit einem Core Modul, einem DIN Modul, einem 2x40 Display, ein paar Buttons und einem Datawheel unterstuetzen... Das drueckt die Hardwarekosten auf ca. 50-70 EUR, je nach Qualitaet der Bedienelemente Gruss, Thorsten.

Habe mich daran erinnert, warum das Menue nur mit dem Cursor scrollt(e): weil die Tastaturbelegung anfangs noch anders definiert war. Habe mich dann nach den Aenderungen so an das Handling gewoehnt, dass ich es eigentlich gar nicht ausbauen wollte. Habe es nun trotzdem geaendert (wer es nicht mag, darf den CS_MENU_OLD_STYLE switch einschalten) Gruss, Thorsten. P.S.: wegen des neuen Display Update Handlings: da ich viele kleine Aenderungen an Code-Stellen vorgenommen habe, die teilweise ein Jahr alt waren, besteht nun erhoehte Buggefahr! (Das hast Du nun davon! ;-)) --- deshalb bitte gruendlichst testen!

Hi Seppoman, too bad that I just have release alpha2 ;-) Could you please check it with the new version? See also: http://www.ucapps.de/midibox_sid_changelog.html Best Regards, Thorsten.

Hallo, die erste Idee ist eigentlich schon obsolet, wenn Du Dir mal die v1.6alpha1 anschaust. Hier wird das Display nicht aufeinmal, sondern schrittweise mit jedem USER_Tick aufgebaut. So ist es nun voellig egal, aus wievielen Items ein Menue besteht, Du wirst das Delay von ca. 300 uS pro Parameter (bei Deinem Display ca. 1.2 mS) nicht merken! Die Kopplung an den Edit-Button waere nicht ideal gewesen, sie wuerde die Bedienung nur noch komplizierter machen. Egal, wo ich auch etwas dokumentiere, meistens landen Dinge, die man nicht auf Anhieb versteht, doch im Forum. Und die Frage "warum zeigt das dumme Control Surface keine Parameter an, wenn ich an einem Knopf drehe" haette sich sehr schnell zu einem Dauerrenner entwickelt... Zum Vorschlag fuer das Menue-Handling: Anfangs war die Menuesteuerung sogar ohne den laufenden Cursor programmiert, genauso wie Du es vorgeschlagen hast, aber aus irgendeinem Grund habe ich es dann doch anders gemacht - leider kann ich mich an den Grund gerade nicht erinnern, aber vielleicht faellt es mir irgendwann mal wieder ein... ;-) Ja, CS_MENU_ENC_CS_Handler muss in diesem Fall angepasst werden - hier habe ich bisher auf Code Size optimiert, deshalb laesst er sich nicht so bequem erweitern. U110: habe die XG Karte einfach zusaetzlich eingebaut, und dabei an den MIDI Thru sowie an die Audio-Ausgaenge 5 und 6 angeschlossen. Habe das Teil aber auch schon seit Monaten nicht mehr angeruehrt... ;-) Gruss, Thorsten.

Hi Thomas, 1) check the MIDIbox64 and MIDIbox MF applications, they already support remote access via SysEx, and therefore give you some good examples. The control bytes for MIDIbox Link are sent by MIOS_MIDI_BeginStream and MIOS_MIDI_EndStream --- see also the functional description (http://www.ucapps.de/mios_fun.html The easiest way for sending MIDI events: just copy the "midi_evnt.inc" driver from the MIDIbox64 application into your project. 2) > When exactly will this functions be called You know where to find the documentation of MIOS functions? > USER_MPROC_NotifyFoundEvent After a complete MIDI event has been received and have been found in MIOS_MPROC_EVENT_TABLE > USER_MPROC_NotifyReceivedByte After any byte has been received > USER_MPROC_NotifyReceivedEvent After a complete MIDI event has been received > What happens if two events come directy after each other? USER_MPROC_NotifyReceivedEvent will be called twice, for every event seperately. > What happes if there are to many events to store? MIOS provides a Rx buffer of 64 bytes, so an overrun could only happen if your application would stall the USER_Tick for about 60 mS - so long as your project is programmed properly, this shouldn't be an issue. The max. usage of the Rx buffer is normaly about 3 bytes > Does the last one win or will it be lost? The last bytes will lost - but as I wrote: this is no issue with the fast PIC18F > What happens after MIDI-Timeout? The whole buffer will be cancled Btw.: some additional infos about latency, delays etc. can be found in the uCApps FAQ Best Regards, Thorsten.

Hi John, there are a lot of simple and also more complex examples for parsing SysEx in the MIOS download section. A simple one: see the led_digits_mtc_v1_3.zip example or the midimon (mtc.inc) More complex ones: see the MIDIbox applications like "midibox64" or "midibox_lc" Don't use USER_MIDI_NotifyRx for parsing SysEx streams, this is an interrupt service routine which should only be taken on very special cases (e.g. for receiving a MIDI clock or for a software implemented MIDI In LED) USER_MIDI_NotifyReceivedByte is a low priority task (at the same level like USER_Tick) - which doesn't mean that it has a mentionable latency!). Best Regards, Thorsten.

Hi, normaly the MIOS device ID has to be specified when burning the bootstrap loader (see also the Bootstrap Loader help page), but the change_id application allows you to set a new ID w/o using a PIC programmer. Best Regards, Thorsten.

The easiest way to change the MIOS device id is the use of "change_id_v1_4" - it can be found in the MIOS download section. Best Regards, Thorsten.

"rastnest" renders the layout again, thereafter you will see a ground plane between the pins (which fortunately also can be found on Mikes premade PCBs) SmashTV has updated the .brd file - thanks! :) Best Regards, Thorsten.