TK.

Hallo, so etwas laesst sich mit Meta Events sehr einfach realisieren (siehe mb64_meta.inc). Rufe einfach nach dem Senden des Strings die Funktion "MB64_BANK_Change" auf. Beispiel zum Wechseln nach Bank 2: (0x01) movlw 0x01 goto MB64_BANK_Change Gruss, Thorsten.

It sounds like the transfer works fine with 100 bytes/s, but you are uploading a currupt .syx file. Could you please try the midibox64.syx default setup which is part of the http://www.ucapps.de/midibox/mk_syx.zip package, just to ensure that the MIDI connection works properly? if this happens, it is maybe better to use a regular MIDI connection via optocouplers, so that the USB and MIDIbox voltage domains are seperated (I did the same with the MBHP_USB integated into my MIDIbox LC and MIDIbox SID). Or supply the USB module from the MIDIbox (remove the jumper near by the USB socket, and connect the "power IO" of the MBHP_USB with J2 of the core module) Best Regards, Thorsten.

But 250 bytes/s was with a PIC16F core, where only 14 bit are saved at once, no? Best Regards, Thorsten.

You've mixed some informations here. I will try to explain it in detail. This is wrong. There is enough RAM to handle 16 tracks, and the timings are extremly stable. Stable means here, that the SEQ kernel never needs more than 1 mS in worst case to handle all 16 tracks at a clock event (I optimized the routines by viewing the timeslices with a scope). This worst case happens on every 16th step, means: every 107 mS @ 140 BPM The sub ticks are consuming about 200 uS --- so, CPU power is really no issue (for comparison: I measured a jitter of ca. 2 mS when Logic Audio plays a MIDI track, regardless if I'm using my Hammerfall DSP MIDI Out, MIDIsport 2x2 MIDI Out or MBHP_USB MIDI Out, so this must be a problem with Windows...) To give you an expression: here is the data structure for one track record: ;; ----------------------------------- ;; track record structure SEQ_TRKSTATEx EQU 0x00 SEQ_TRKMUTED0x EQU 0x01 SEQ_TRKMUTED1x EQU 0x02 SEQ_TRKPLYTICKx EQU 0x03 SEQ_TRKSTEPx EQU 0x04 SEQ_TRKPOSx EQU 0x05 SEQ_TRKQUEUE0x EQU 0x06 SEQ_TRKQUEUE1x EQU 0x07 SEQ_TRKQUEUELx EQU 0x08 SEQ_TRKEVNT0x EQU 0x09 SEQ_TRKMODEx EQU 0x0a SEQ_TRKDIVLENx EQU 0x0b SEQ_TRKASSGNx EQU 0x0c SEQ_TRKTRANSPx EQU 0x0d SEQ_TRKGROOVEx EQU 0x0e SEQ_TRK_RESERVEDx EQU 0x0f SEQ_TRKRECORD_LAST EQU SEQ_TRK_RESERVEDx As you can see, one track allocates exactly 16 bytes, and so it wasn't a big deal to instanciate 16 of them which are working independent from each other. RAM consumption: 256 bytes ;; ----------------------------------- ;; Live Editing Tracks SEQ_TRK0 EQU 0x200 SEQ_TRK1 EQU SEQ_TRK0 + 1 * SEQ_TRKRECORD_LENGTH SEQ_TRK2 EQU SEQ_TRK0 + 2 * SEQ_TRKRECORD_LENGTH SEQ_TRK3 EQU SEQ_TRK0 + 3 * SEQ_TRKRECORD_LENGTH ;; Tracks played from EEPROM SEQ_TRK4 EQU SEQ_TRK0 + 4 * SEQ_TRKRECORD_LENGTH SEQ_TRK5 EQU SEQ_TRK0 + 5 * SEQ_TRKRECORD_LENGTH SEQ_TRK6 EQU SEQ_TRK0 + 6 * SEQ_TRKRECORD_LENGTH SEQ_TRK7 EQU SEQ_TRK0 + 7 * SEQ_TRKRECORD_LENGTH SEQ_TRK8 EQU SEQ_TRK0 + 8 * SEQ_TRKRECORD_LENGTH SEQ_TRK9 EQU SEQ_TRK0 + 9 * SEQ_TRKRECORD_LENGTH SEQ_TRK10 EQU SEQ_TRK0 + 10 * SEQ_TRKRECORD_LENGTH SEQ_TRK11 EQU SEQ_TRK0 + 11 * SEQ_TRKRECORD_LENGTH SEQ_TRK12 EQU SEQ_TRK0 + 12 * SEQ_TRKRECORD_LENGTH SEQ_TRK13 EQU SEQ_TRK0 + 13 * SEQ_TRKRECORD_LENGTH SEQ_TRK14 EQU SEQ_TRK0 + 14 * SEQ_TRKRECORD_LENGTH SEQ_TRK15 EQU SEQ_TRK0 + 15 * SEQ_TRKRECORD_LENGTH SEQ_TRK_END EQU SEQ_TRK0 + 16 * SEQ_TRKRECORD_LENGTH-1 But there is also some other kind of data, and these are the RAM consuming layer informations. Every track consists of three layers, assigned to the first MIDI byte (e.g. the Note number or CC#), the second MIDI byte (e.g. the Velocity or CC value) and the gatelength. ;; ----------------------------------- ;; pot layer A SEQ_POT_VALUES_A_00 EQU 0x1c0 ;; ... SEQ_POT_VALUES_A_3F EQU 0x1ff ;; ----------------------------------- ;; pot layer B SEQ_POT_VALUES_B_00 EQU 0x080 ;; ... SEQ_POT_VALUES_B_3F EQU 0x0bf ;; ----------------------------------- ;; pot layer C SEQ_POT_VALUES_C_00 EQU 0x0c0 ;; ... SEQ_POT_VALUES_C_3F EQU 0x0ff You can see: 4 tracks * 3 layers * 16 steps makes 192 bytes Also the control surface requires some bytes, and the basic sequencer functions. With MIOS you've 896 bytes free for an application (with some tricks ca. 128 bytes more) --- but this is not enough for storing the layers of the remaining 12 tracks in RAM. So my solution was (and I haven't taken it into account before, therefore I refused the 16 tracks requests first...) to read the layer informations of the other tracks directly from EEPROM. The resulting use case: every pattern consists of 4 tracks you can play 4 patterns at the same time you can edit only one pattern w/o timing problems you can switch between the patterns w/o timing problems you can connect multiple cores together and you can send patterns to another core, so that it will be played from this slave in sync with the master and now the limitation: when saving a pattern in EEPROM, the sequencer engine will stall for about 100 mS, this is an audible effect and not desired during a live performance. On the other hand: this doesn't hurt when you are using prepared patterns, modifiying it during the sequencer is running but don't want to save the changes... for the records: when a song switches to 4 different patterns, it takes ca 10 mS and is therfore not audible (the switching is synchronized with the sequencer engine, it will happen automatically at the end of a sequence when no note is played). I achived this performance by implementing a new MIOS function "MIOS_BANKSTICK_ReadPage" which will be part of the next MIOS version (MBSEQ uses a copy of this function, so that it will be compatible with the current MIOS version). A sequencer is not a synthesizer ;-) But like you can read above, it's easy to send a pattern to another core, so that it plays this pattern (if you really need more than 16 tracks...) Please explain me exactly which advantages you are expecting from this method. Which workflow is your target? There are a lot of enhanced methods to make such a sequencer more powerfull, you could either use external SRAM (e.g. 128k, battery buffered - I already wrote how to realize this), or you could implement a bidirectional interface between multiple cores, so that the master can request and submit informations from/to the slaves (-> see the companion core concept). This works fine so long as it is guaranteed that the slave can handle a request without much delay. And here is the problem --- the delay: I guess that a slave is always so busy, that a latency of less than 100 uS cannot be ensured --- so, forget the parallel core concept with bidirectional transfers, it doesn't really help. If you are thinking on an alternative sequencer concept, then maybe a sequencer which doesn't work step-based? Ok, such a sequencer definitely desires more RAM -> think about an external RAM extension Or you are thinking about a step sequencer which isn't so flexible like MBSEQ, but is optimized for dedicated jobs (e.g. a drum machine) -> don't use 3 layers, but think about another data format to save the step information. For example, you could run 32 tracks in parallel, every track assigned to a single note, velocity and gatelength. You only want to control the "mute status" and "accent". Result: instead of allocating 32 tracks * 3 layers * 16 steps = 1536 bytes for the layer information, you would only need 16 bit * 32 = 64 bytes for the accent flags plus 3 * 32 = 96 bytes for the note/velocity/gatelength which is used for the whole track (mute flags are already stored in the track record) Ok, I think this is enough to give you some impressions about the art of system programming ;-) Best Regards, Thorsten.

No Idea, I've asked Jamie how MIDI-Ox transfers the delayed data to the MIDI interface. Either MIDI-Ox needs an alternative mechanism (similar to Serges Loader, since the transfer is working with this tool), or MBHP_USB requires a special firmware for MIDI-Ox (but it's unclear if there is a way to "cheat" the M$ driver) Did you try Serge's Loader again (see message above)? It *must* work with 100 bytes/s Best Regards, Thorsten.

Update: I've contacted Jamie OConnell (the Author of MIDI-Ox), maybe there is a way to find a workaround. Best Regards, Thorsten.

So, in this case it could also be an issue with MIDI-Ox, and not with the windows itself. With WinXP I also installed the most recent MIDI-Ox version, maybe they changed something which makes it impossible anymore to upload SysEx bytewise. So, maybe better to try it with vmidibox again, because I've now ensured that it works properly under WinME and WinXP with the MBHP_USB - Reboot Windows - start vmidibox64 - select your MIDI interface - set the transfer rate to 100 bytes/s - send SysEx > if my midi box get blocked again...can i upload mios with primary bootloader using usb? Sure, but I don't see a reason for doing this. The code area hasn't been touched by this SysEx upload. You must differentiate between code upload via SysEx, and data upload via SysEx. Code upload is a MIOS specific feature and requires exactly the settings which I've described in my first article. Data upload is an application specific feature, and it can differ with every application. The data upload of MIDIbox64 has been written in a way which makes it compatible to the old PIC16F, with the disadvantage that the transfer rate is significantly lower. If I wouldn't have to take care about such compatibility issues (or if I would have the time to enhance vmidibox...), I could provide an alternative MB64 bank upload mechanism which works much faster, but I see no timeslot for this. However, in fact you should continue with vmidibox and try to find a solution. If it still doesn't work, you could ask Serge for help. Best Regards, Thorsten.

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!