TK.

I think I will change this in the next official release, because it really allows more variations than the current BPM divider settings. This would mean that BPM/32 and BPM/64 won't be available anymore. However, if somebody needs this (I don't think so), then he is always allowed to reverse the change ;-) Best Regards, Thorsten.

This is the MIDIbox FM of sjakie - he wrote:

ZK12 redesigned his MIDIbox Plus case (it's an old computer keyboard) - although the PIC is running with a very old firmware version (v1.004, this release is older than 4 years), it works fine :)

This is the MIDIbox64 of MAG, he built it especially for Logic Audio:

Hi Hermes, check the tracks around the MIDI In port, it seems that you damaged one of them with the soldering iron (by fault) Best Regards, Thorsten.

please read the step-by-step instructions in the main.asm header Best Regards, Thorsten.

yes, there are several reasons - all PICs with integrated USB have bugs which affect the compatibility with existing MIOS projects. In addition, the USB PICs cannot be used as USB->MIDI bridge due to a silicon bug in the EUSART which I found during the firmware development for the PIC18F4550: -> http://forum.microchip.com/tm.asp?m=85120 therefore I've given up to use this chip - it's a waste of time Best Regards, Thorsten.

Independent BPM rates would require dedicated hardware timers for each track --- this is not possible, all timers of the PIC are allocated. But you could customize the BPM divider if you want. Currently only even numbers are provided, since they can be easily derived from a bitmask. I haven't taken odd numbers into account, but there is only one place in the sequencer core which needs to be changed: SEQ_CORE_Clk_NextStep_No1st ;; increment SEQ_TRKSTEPx and save new value in TMP1 movlw SEQ_TRKSTEPx incf PLUSW0, F movff PLUSW0, TMP1 ;; check for max value which depends on divider setting movlw SEQ_TRKDIVLENx movf PLUSW0, W ;; 0->1, 1->2, 2->4, 3->8, 4->16... hey, thats simply the output of MIOS_HLP_GetBitORMask call MIOS_HLP_GetBitORMask [/code] so, if you would call an own jumptable function instead of MIOS_HLP_GetBitORMask, you could realize any divider. up to 16 different divider settings are possible, this means that for the case BPM/1 ... BPM/16 you could just replace "call MIOS_HLP_GetBitORMask" by "andlw 0x0f" and "addlw 1", this will work without changing the data structures Best Regards, Thorsten.

Meeshka has written a really informative documentation about MIOS Studio and released a new version with some nice new features: http://69.56.171.55/~midibox/mios_studio/ http://69.56.171.55/~midibox/mios_studio/apps/miosstudio/gui/help/index.html Don't miss this application, compared to the old upload flow via MIDI-Ox it can save you from a lot of trouble! Best Regards, Thorsten.

The low/high byte order has been changed (again) in SDCC 2.5.0, this means that all MIOS functions which are using 16bit words (like some AIN and BANKSTICK/FLASH/EEPROM functions) don't work anymore. However, I will release a new wrapper soon Best Regards, Thorsten.

Hi Maik, everbody is allowed to use resistor networks if he wants, the reason why the PCBs are stuffed with common resistors is, that I have to ensure that the parts are worldwide available for low prices (not every mailorder company sells resistor ladders). The first version (from 1999) was stuffed with resistor ladders, but I removed them on request Yes, the advantage is, that buttons, rotary encoders, etc... can be connected to ground. This is mostly easier to handle once they are mounted on a metal panel. Another advantage is, that the pin used for ground can be connected together with the cathode of LEDs (LEDs are driven high-active in my designs) Best Regards, Thorsten. P.S.: I'm missing the bypass caps! ;-)

Hi, I can understand your frustration, too much things are playing together: JDM parts/mainboard/operation system/drivers/IC prog software, with so much error sources it can be a long way to find the reason for a failure. I/O delay 4 is maybe the only working solution for your PC(s), but why are other people happy with other delay values? Don't know... In order to improve the situation I've already developed the new MBHP_BURNER which should work much more reliable. I think the best way is to remove the MBHP_JDM page once the MBHP_BURNER layout is done, so that nobody stumbles accross such problems anymore. Best Regards, Thorsten.

Link to a solution for WinXP http://69.56.171.55/~midibox/forum/index.php?topic=4498.0

Hi Martin, yes, SDCC 2.5.0 is ok I'm just working with the C wrapper and found a major problem in conjunction with MPLAB (first time I'm writing a more complex application with it) The details can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=1203088&group_id=599&atid=100599 However, in the meantime I'm using gpasm which is also available for Win32 - it works perfectly. I will write down the details once the C based MIDIbox MM application is finished and once I'm sure that there is no other issue .hex file: you will get it via email Best Regards, Thorsten.

Hallo, es gibt eine feste Zuweisung zwischen den Schieberegistern, die wird in main.asm und im midibox64.ini Script (mk_syx Package) eingestellt (Kommentare lesen...) Leider nicht auf Anhieb siehe MIDIbox LC, es handelt sich um eine komplette Mackie/Logic Control Emulation. Du muesstest sie jedoch an Deine Hardware anpassen (siehe Kommentare im main.asm Header) Den Link zur Doku findest Du im MIDIbox Wiki Gruss, Thorsten.

Hi Frank, I'm planning to port this application to C, so it could be that such changes will be easier in the future :) Best Regards, Thorsten.

Hallo, hierfuer muesstest Du den Toggle Modus aktivieren - gehe in das MIDI Learn Menue und selektiere mit der Snapshot Taste den gewuenschten Modus (es gibt: ON/OFF, ON only, Toggle), danach ein MIDI event zuweisen, fertig. Optional koenntest Du das auch mit dem Editor oder (eigentlich schneller) mit dem mk_syx Script konfiguieren ohne zusaetzliche Programmierung (in mb64_lcd.inc) ist da nichts zu machen Kommt darauf an, welche Protokolle LogicPro unterstuetzt (gibt es hierzu irgendwo eine Auflistung?) Gruss, Thorsten.

Hallo Stefan, Du koenntest den Merger deaktivieren und die Applikation so aendern, dass sie die MIDI Events selbst weiterleitet. Dabei hast Du auch die Moeglichkeit, die MIDI Events nach belieben zu konvertieren --- Startpunkt: USER_MPROC_NotifyReceivedEvent Gruss, Thorsten.

You can use 128 DINs with MB64, just enhance the USER_DIN_NotifyToggle hook. Only problem is that the SysEx structure doesn't support so much configurable MIDI events, but so long you only want to send static events (e.g. Notes or CCs which are always the same, and where only the Velocity/CC value changes), this doesn't really matter. The MB64 supports also 64 AOUTs (requires SHX8 module) Best Regards, Thorsten.

Hi René, this would require a USB host interface, the PIC offers only a USB slave interface and thats something completely different Best Regards, Thorsten.

I think it makes sense to program a Korg protocol emulation in C, just to evaluate SDCC in combination with the MIOS wrapper, and to give everybody the possibility to extend the program without the need for assembler knowledge. Just give me some days - first I want to migrate the Motormix emulation since I'm able to test this protocol with different host applications, once this is working I can modify it for other protocols. Best Regards, Thorsten.

Hi, of course, this is possible - but it has to be implemented by somebody who would use (and test) such features by himself So, is there anybody who will take care about such feature requests for MIDIbox LC? Best Regards, Thorsten.

If a SysEx block wasn't received or returns an error, and if you don't check the return messages in the MIDI-Ox window visually in order to react if anything goes wrong (switch off the core module and try the upload again with the 1st level BSL), everything can happen in a non-deterministic behaviour. This won't destroy your PIC, but of course: something within the flash could be overwritten by fault, e.g. MIOS or the bootstrap loader. I spend a lot of effort to reduce the propability for such a failure, but it is impossible to avoid all possible cases. Another possible case is, that you are overwriting the flash due to a programming error (nobody can prevent this, only you by yourself ;-) However, if you would use MIOS Studio, the probability would be much lower, since this program checks the return messages, retries to upload the code if the acknowledge is missing or if it wasn't received at all. So --- please don't ignore this nice piece of software! Wilba and Adam implemented it to make your daily live with MIOS easier and more fool proven! Best Regards, Thorsten.

Hi Frank, I would integrate such changes into the USER_DIN_NotifyToggle and USER_MPROC_NotifyReceivedEvent hook (the can be found in main.asm). Currently they are branching directly to MM_BUTTON_Handler and MM_MPROC_NotifyReceivedEvent Before these branches (goto's), you could check for a certain button number (or button group) and - if the check matches - branch to your own routine which sends Note On/Off events LEDs: check for the expected MIDI events before branching to MM_MPROC_NotifyReceivedEvent Best Regards, Thorsten.

Hi Tijs, thanks for your kind words! :) no - the "advantage" of the appr. service routines is, that it updates the DOUT chain each milisecond (the update cycle can be adjusted). This means that this behaviour can be misused to generate 1 ms triggers without deep programming knowledge --- the internal DOUT registers just have to be cleared after the update cycle, so that the pins will be reset with the next cycle, and it works. For the J5 solution (which is only provided as an example) something similar could be realised with seperate 8bit counters for each pin. The counters have to be incremented within USER_Timer (which could be called each 100 uS or so...), and which reset the pins on a counter overrun. By doing this, you can realize configurable pulse lengths from 100 uS to 25.5 mS However, on the other hand: I just remember that I tinkered some simple MIDI triggers for two Roland analog drum machines of a friend some months ago. I didn't spend effort on creating pulses with a defined pulse width. The pins were set with a Note On event, and cleared with a Note Off event. It works perfectly So - if it isn't clear to you if short triggers are really required, just try the J5 application without any modifications and it will possibly already work. Best Regards, Thorsten.