TK.

Super! :) Nun frage ich mich wirklich, warum das Problem nur bei der MBSEQ V3 auftritt, und nicht bei anderen MIDIboxen, die teilweise mit wesentlich mehr Shiftregistern ausgestattet sind. :-/ Gruss, Thorsten.

It should be described in the manuals which are comming with the debugging tool. But so far I know, PICkit get use of the low-voltage programming mode, accordingly the RB5 pin cannot be accessed by the firmware anymore - you won't be able to use a LCD. I'm sure that there are many people here who could burn and test the PIC for you. Where are you living? Best Regards, Thorsten.

My first thought: why are the waveform and ring/sync buttons so dominant? Wouldn't it be better to add 8 volume pots for the SIDs + 4 "Mono" buttons (which merge two channels together for multi engine) instead of spending area for functions which are not permanently used live? There is no "Poly" engine, it's called "Multi" engine (as you can play up to 6 instruments) The modwheel makes "Knob 1" obsolete Why not adding a second modwheel? CutOff and Resonance knobs are too close together. The modulation matrix is missing :) Best Regards, Thorsten.

Just use a PIC18F4685 and install the MIDIbox SID V2 firmware - beside of LFOs with MIDI-Sync, Sample&Hold, Envelopes it provides much more features you probably haven't thought of yet. :) -> http://www.ucapps.de/midibox_sid_manual_cv.html Best Regards, Thorsten.

Note, that this code will send invalid MIDI events when BLM_MIDI_STARTNOTE >= 65 It's better to write: MIOS_MIDI_TxBufferPut((pin + BLM_MIDI_STARTNOTE) & 0x7f); [/code] and something similar in MPROC_NotifyReceivedEvnt(); so that the "wrapped" note number is still maching between LEDs and Buttons Best Regards, Thorsten.

I updated the README.txt; version number not incremented Best Regards, Thorsten.

Me too, it is matching with the schematic (D0 is bit 7, D1 is bit 6, etc...) Ooops, you are right! I fixed this in version blm_example_v1_2 (-> see MIOS download section) For the 4x16 matrix (which I own) this scrambling is better. Therefore I guess it's only a documentation issue - I added your input to the README.txt file The processing routines in main.c (or in the host software) can easily map the column/row numbers to the "physical layout" if desired. Best Regards, Thorsten.

No - I'm working on USB devices maybe one week per year and therefore don't follow the progress. Which ID is printed on the package? E.g., my non-working (EUSART bug) rev2. has 0504409, the working rev5 has 07351KG I guess that the first four digits stand for year and calendar week of production. I've released the source code + some documentation now: -> http://www.ucapps.de/mbhp_usb_pic.html Best Regards, Thorsten.

Although I initially planned to cancel the project (which I've implemented years ago), I finally decided to release the MBHP_USB_PIC "as-is" with a documentation of the known issues. -> http://www.ucapps.de/mbhp_usb_pic.html Short summary: In general it works fine under Windows and Linux, but there is a potential risk for data loss when large SysEx dumps are sent and received concurrently. However, MIOS uploads are unidirectional, and therefore working stable enough Windows legacy driver is not multiclient capable. This means: you have to close your MIDI software (or release the MIDI ports) when using MIOS Studio The module is not working correctly under Mac OS X (tested with Leopard only) the latest PIC18F4550 (or PIC18F2550) revision 5 is required to overcome the EUSART bug no PCB available (yet), but MBHP_CORE module can be used. Just add the USB socket, a 470 nF cap, replace the crystal by a 20 MHz type, and add a Reset and Bootloader button. Best Regards, Thorsten.

Addendum: Rutger's MBSID V2 editor is doing very good progress - once it is available, configuring voice and MIDI assignments will be a piece of cake! :) Best Regards, Thorsten.

Schicke mir mal den PIC zu, ich moechte ihn an meinem MIDI Interface testen. Meine Adresse findest Du im ucapps.de Impressum Gruss, Thorsten.

You could solder the "link" cable at the bottom of the Core PCB. You are already doing this for the parallel bus connections to OPL3, so this would be a consequential solution. Best Regards, Thorsten.

Support for more than 4 cores is not possible due to conceptional reasons. Best Regards, Thorsten.

Please note that you are talking about the MBSID V2 firmware, and not about Wilba's MB6582 hardware variant. This isn't possible with the lead engine due to conceptional reasons, but with the multi engine. Use two instruments, assign them to different MIDI channels or keyboard zones. This can be done in the INS menu of the ensemble. Assign the voices of the first instrument to left SID (VAs=L), and the voices of the second instrument to right SID (VAs=R). This has to be done in the CFG menu of the patch Thereafter disable the Poly flag in CFG menu and you are done :) Yes, all this can be done with multi engine. You only need to configure the voice assignments and MIDI channel assignments as desired. No problem, with multi patches you have access to 24 seperate mono synths. Yep, MIDIbox SID V2 can be 24-part muli-timbral. Just have a look into http://www.ucapps.de/midibox_sid_manual_m.html Best Regards, Thorsten.

An update is now available (-> sdcc_skeleton_v1_9c) with a minor change in the makefile generator (GPASM_DEFINES variable added to pass parameters to gpasm) Migration copy tools/mkmk.pl into your project. Best Regards, Thorsten.

Thank you! I added the inversion parameter the following way to blm.asm: ; set an inversion mask for the DOUT shift registers if sink drivers (transistors) ; have been added to the cathode lines ; Settings: 0x00 - no sink drivers ; 0xf0 - sink drivers connected to D0..D3 ; 0x0f - sink drivers connected to D4..D7 #define DEFAULT_SRM_CATHODES_INV_MASK 0x00 [/code] The cathodes of your LEDs are connected correctly - DOUT registers are mirrored, this might be confusing... I will consider to add sink drivers to my own hardware as well. They are not really required (as I'm using low-power LEDs), but it makes sense to be "source code compatible" with other solutions. I also added your optimied LED toggling code. -> blm_example_v1_1 in the MIOS download section. Best Regards, Thorsten.

Please have a look into main.c and decite by yourself, if modifications are easy to realize or not. Best Regards, Thorsten.

Yes, I like your attempt! Best Regards, Thorsten.

BLM example application is now available here: http://www.midibox.org/forum/index.php/topic,10476.0.html Best Regards, Thorsten.

blm_example is now available at http://www.ucapps.de/mios_download.html I used this small application during the development of the Button/Duo-LED hardware for MIDIbox SEQ V3 in order to check different wiring options. The driver (blm.asm) is mainly based on sm_simple.asm of the sm_c_example1. Today I added a debouncing option as requested by bugfight I would like to highlight again, that the hardware as shown in http://www.ucapps.de/mbhp/button_duoled_matrix.pdf needs to be improved for high current LEDs. I don't see this as my task. Newbies: there are no premade PCBs available, and manual wiring on vero boards requires advanced soldering experiences! Pictures: http://www.midibox.org/midibox_seq_blm_ext/ From the README.txt [tt] Button/Duo-LED Example =============================================================================== Copyright 2008 Thorsten Klose (tk@midibox.org) Licensed for personal non-commercial use only. All other rights reserved. =============================================================================== A precompiled binary is already part of this package: o project.hex (can be loaded into MIOS Studio) o project.syx (can be loaded into any SysEx upload tool) Following tools are required to recompile the code: o SDCC v2.5.0 o gputils o perl The details are described under http://www.ucapps.de/mios_c.html =============================================================================== Required hardware: o one MBHP_CORE module o one DINX2 module (or DINX4) and two DOUTX4 modules or dedicated board for BLM matrix as specified under: http://www.ucapps.de/mbhp/button_duoled_matrix.pdf =============================================================================== This program demonstrates the so called "BLM" driver (-> blm.c) This driver handles a 4x16 Button/Duo-LED scan matrix of up to 64 buttons and 64 Duo-LEDs by using the circuit documented under: http://www.ucapps.de/mbhp/button_duoled_matrix.pdf The hardware was originally used for MIDIbox SEQ V3, but could also be useful for other projects. Note that the buttons/LEDs can be easily arranged to a 8x8 matrix w/o software modifications. Please note also, that the shift register assignments in blm.c (DEFAULT_*) need to be adapted to your hardware. The setup used in this example is prepared for connecting the DIN/DOUT chain directly to the MBHP_CORE module (there are no additional DINX4 or DOUTX4 modules between the BLM and the core like on the MBSEQ V3 hardware). The function "BLM_NotifyToggle()" in main.c is called when a button has been pressed or released. LEDs are accessible from the blm_row_green[8] and blm_row_red[8] array. By default, this application sends Note Events from Number 0 (C -1) to 63 (E 4) and it receives the same numbers to control the LEDs: Velocity 0x00 (or Note off): green and red LED off Velocity 0x01..0x3f: green LED on, red LED off Velocity 0x40..0x5f: green LED off, red LED on Velocity 0x60..0x7f: both LEDs on Optionally some code can be enabled in the BLM_NotifyToggle function (located in main.c) to cycle the LED colour with the appr. buttons. Buttons can be debounced with a definable delay (-> blm_button_debounce_delay) The resulting delay is calculated as <value> * 4 mS The Init() function in main.c sets the value to 20 (-> 20*4 mS = 80 mS) If you want to experiment with different delays, you could (temporary) control it with a CC event from MPROC_NotifyReceivedEvnt() function in main.c with following code: if( evnt0 == 0xb0 && evnt1 == 16 ) { // control debounce delay with CC#16 over Channel #1 blm_button_debounce_delay = evnt2; } Don't forget to remove this change, so that a common MIDI application isn't able to modify the value unintentionally. =============================================================================== Description about the most important files: - mios_wrapper\mios_wrapper.asm and mios_wrapper\mios_tables.inc: The MIOS wrapper code and MIOS specific configuration tables - pic18f452.c: exports PIC18F452 specific SFRs - main.c: the main program with all MIOS hooks - blm.asm: the assembly optimized scan matrix code There are additional .h files for all .c files which contain general definitions and the declaration of global functions/variables These .h files must be included into the program parts which get use of these globals =============================================================================== [/tt] Best Regards, Thorsten.

Ok, fuer mich ist das ein superinteressanter Fall, da wir es hier wahrscheinlich mal wieder mit einem Interface zu tun haben, welches auf den Legacy-Treiber von Windows aufsetzt, und nicht korrekt funktioniert (mehr zu diesem Thema, wenn sich meine Vermutung bestaetigt). Installiere mal den alternativen Windows-Treiber von EMU, er befindet sich hier: http://www.emu.com/support/files/download2.asp?Centric=1009&Legacy=&Platform=1 Es koennte sein, dass es damit bereits funktioniert (d.h.: der komplette SysEx String wird fehlerfrei empfangen) Falls nicht, probiere es mal ohne das LTC Modul aus (vielleicht sorgt hier ein Quasi-Kurzschluss fuer ein schlechtes Signal am MIDI Out) Immerhin scheint der MIDI In Port schonmal zuverlaessig zu funktionieren (ein SysEx-Request wird erkannt und beantwortet) Gruss, Thorsten.

Before I wrote the BLM driver for MBSEQ, I enhanced the sm_c_example1_v1 for testing the hardware. It was a quick&dirty hack, but it shouldn't be so much effort to clean up the code, and to release it as blm_example I will also integrate a debouncing function for buttons Best Regards, Thorsten.

I've created a primitive application for this 4x16 button/duo-LED matrix a while ago http://www.midibox.org/midibox_seq_blm_ext/ It doesn't support layering, but this could be easily added. How many layers do you need, and which MIDI events should they send? Best Regards, Thorsten.

I haven't enough C++ experiences to integrate my "MIDI hack" correctly into sidplay2 All I did was to enhance the resid builder by some MIDI output routines. Normaly a seperate builder has to be created (as they did for HardSID), but my solution requires an emulation in background, so that .sid routines are able to read out the SID "random/env3" register. MIDI interface is currently hardcoded to /dev/midi - I don't know how to forward a device argument from command line to a builder. How about your programming skills? I could give you the changed builder "as-is" for a proper integration into the sidplay project. Best Regards, Thorsten.

typing "ablethon banks" into the search function delivers this info: http://www.midibox.org/forum/index.php/topic,9722.0.html Maybe there are more hidden treasures burried in the forum? ;) Best Regards, Thorsten.