TK.

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.

The firmware is already complicated enough, from MBSID V1 and MBFM I learned, that such extra BankStick partitionation options only causes a lot of additional effort at my side. Initially I planned not to support 24LC256 at all - search in the forum to find out, how many times people missed the info about the different number of patches, and the resulting side effects (e.g. during a bank upload). I really don't know, where to put this information so that people are aware of this. :-( But there is also a practical reason why two BankSticks cannot be combined: because the first patch slot is always used as storage for internal informations (Magic bytes, and future extensions) - so, in fact a 24LC512 only stores 127, and a 24LC256 63 patches - the remaining patch (Patch #1) is always stored in internal EEPROM, and it's the same for all banks (A001, B001, C001, ...). So, combining two 24LC256 to a single bank would result into 126 patches - don't want to know, how many times I would have to answer questions about such strange side effects again and again to clarify, that this wouldn't be a bug? So, please believe me: it's easier to use seperate banks for each BankStick than combining two BankSticks to a single bank. Once the SysEx editor and patch manager is available, it will be possible for you to split the presets over different banks Best Regards, Thorsten.

See http://www.ucapps.de/midibox_sid_manual_hw.html search for "banksticks" or "24LC256" Best Regards, Thorsten.

You could use Special Function buttons to switch between different MIDI event setups located in different banks (see -> http://www.ucapps.de/midibox64e/midibox64e_sfb_table.txt) - but the big issue is, that informations which have been received before (e.g. absolute encoder positions or LED states) will get lost during a bank switch. Your host needs to support a "controller snapshot" function in order to update the encoder/LED settings. On the other hand: are you sure, that banking isn't natively supported by your host software? So far I remember, it isn't a problem to setup this with Cubase or Nuendo (but I'm a Logic user and cannot help you here - different movie ;-)) The advantage of host based bank switching: always consistent, especially when you are changing parameters with the mouse or load a new song. Today the MIDI controller support of DAWs is mostly so powerful, that only a really stupid hardware is required to communicate with the host. Thats one of the reasons why I haven't spent much more effort into the MB64/MB64E firmware implementation anymore. Best Regards, Thorsten.

Es handelt sich hier sehr wahrscheinlich um ein Problem mit Deinem MIDI Interface. Welches hast Du Dir denn gekauft? Vielleicht hat der Treiber einen Bug, und eine aktuelle Version muss installiert werden (das hatten wir in letzter Zeit schon des oefteren) Gruss, Thorsten.

There is no encoder mode which would cause an event sent over different MIDI channels while the encoder is moved. Could it be, that it is connected to wrong pins? Encoders can only be connected to D0/D1, D2/D3, D4/D5 or D6/D7 of a 74HC165 If you would connect it to (for example) D1 and D2, you would notice exactly this effect. Best Regards, Thorsten.

Did you change the LED_MAP, so that it is only controlled by the received MIDI status? See also this posting http://www.midibox.org/forum/index.php/topic,6039.0.html Best Regards, Thorsten.

The voltage inputs have to be connected together with two isolated cables at the bottom of the PCB. I just noticed, that this isn't documented on the MBHP_AOUT page. I will take a photo and add it to the soldering guide. Best Regards, Thorsten.

Hi Steve, if your variant still doesn't differ so much from the MIDINator code, it doesn't make much sense to test it on my site yet. I guess that it will also fail under MacOS. My own (assembly-based) firmware is mainly based on the Microchip framework as well, the class handler is completely rewritten (however, nothing spectacular) therefore the bytecount is read before releasing the semaphore to SIE. Last saturday I incorporated all the framework errata which are documented here http://forum.microchip.com/tm.aspx?m=275422, but they don't solve the problem. I also found a bug in my own code (risk that wrong byte counter used in the OUT ringbuffer), unfortunately it wasn't related to the issue. I feel that I'm not able to continue debugging without a hardware based USB analyser. But they are too expensive, especially for a sparetime project. For next weekend I'm planning to write down all the findings, put the documentation and unstable firmware on the website, and to freeze the project again - in the hope that sooner or later somebody else will find the bug, or can give me a fully working firmware for further analysation. Best Regards, Thorsten.

Have you ever read the "readme.txt" file? Best Regards, Thorsten.

See this article: http://www.midibox.org/forum/index.php/topic,10135.0.html MBSID V2: NRPNs aren't easy to manage, it's better to assign the sound parameter to knob functions. Thats the way I'm normaly doing, especially because it's possible to assign multiple parameters to the knob, and to define the range. Best Regards, Thorsten.

See this article: http://www.midibox.org/forum/index.php/topic,9767.0.html Current state: Linux version is running fine, I'm planning a port to MacOS X once I find the time to dig through the docs. Wilba started a Windows variant, but encountered issues with the MIDI API of Windows (so far I remember) Best Regards, Thorsten.

no, MBSID V2 is just a fake to sell more MBHP modules - nothing but the version number has changed. ;-) Best Regards, Thorsten. P.S.: IO functions are now defined in setup_*.asm

The current behaviour is important for first-time users to get an understanding, what an encoder is doing. Or why you don't hear a change - because you don't see the value. In distance to an analog pot, this is the only way to give "visual feedback". However, I would find a special button function more useful, which jumps back to the previous page which was visible before you started to move encoders. This would give you the advantage, that you will always get visual feedback, but don't miss the page which was previously edited. Such a function could be integrated into the SHIFT menu page. Best Regards, Thorsten.

Actually it's a program change event which select the patch. CC#0 is used to select the bank Best Regards, Thorsten.

In MBSID V1, wavetables were only stored in EEPROM due to limited RAM of PIC18F452. And writing into an EEPROM takes a lot of time - you can calculate ca. 2 mS per byte. For 128 bytes this makes 256 mS! However, there is a simple solution which has been integrated for this purpose: use CC#12 to change to another Wavetable which is already stored in BankStick. This CC gives you --> ZERO LATENCY <-- access to up to 128 wavetables per bank! :-) Best Regards, Thorsten.