TK.

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.

Hi Matteo, it's impressing that you are never giving up to save money and effort ;-) A change should be simple, open mb64e_ledrings.inc and replace following lines: incf MB64E_LEDRINGS_CTR, W, BANKED andlw 0x0f movwf MB64E_LEDRINGS_CTR, BANKED [/code] by: [code] ;; always display status of last modified encoder movff MB64E_LAST_ENTRY, MB64E_LEDRINGS_CTR Best Regards, Thorsten.

Hi Tijs, this solution to realize a trigger works only with serial chains. How long is the required trigger time? Best Regards, Thorsten.

Hi Sean, no, this isn't normal! Maybe there is a short between the output pins (O0..O7) and the SID address/data pins Best Regards, Thorsten.

Hi Matt, the MIOS concept doesn't allow to run applications in parallel - it's just a small PIC and not a multitasking capable computer like an Apple or PC ;-) So, the easiest way is the use of seperate boxes Best Regards, Thorsten.

it's just depends on the way how you implement this - you could store the button states in an array: 2 bits for up to 4 toggle states, grouped to one byte for 4 buttons, makes 32 bytes (no problem when you are programming an application from scratch with the C wrapper). The LEDs have to be time multiplexed, they get their on/off state from the same array Best Regards, Thorsten.

Hi Martin, I cannot recomment SMD caps for newbies - I tried the suggested 0805 size caps and noticed that they are difficult to solder, there is a high propability for unwanted shorts if somebody uses a common soldering iron without a special tip. Therefore I suggested common caps in the guide to avoid additional support effort. However, experts should know which ones are better ;-) Best Regards, Thorsten.

Hallo Snapper, mein Angebot steht uebrigens noch - vor allem, weil es das letzte noch offene Problem ist, das ich gerne vor dem Erstellen des Platinenlayouts geloest haben moechte :) Gruss, Thorsten.