TK.

The new library is available here: http://www.ucapps.de/midibox_sid/preset_patches_20051109.zip From the Change Log: [tt] o A018 (Arpeggio): changed Arp speed from 99 to 110 o A052 (Nice Lead): changed Portamento speed from 66 to 30 o A067 (SEQ TranceBass): optimized Attack/Decay/Curve of ENV1, activated HP filter in addition to LP o A074 (ARPSEQ Three): activated oscillator phase synchronization o A076 (SEQ Mighty Bass): changed ENV1 depth from 14 to 33 o A078 (Analog Dream 2): increased Release of VCA ENVs o A080 (Analog Dream 4): increased Release of VCA ENVs o A089-A091 (Miami *): set volume to 80 o A093/A094 (Monty Bass *): increased CutOff o A105 (Curve Filter D): increased CutOff o added Patch B006-B011 made by Sebastian (aka Rio) [/tt] Best Regards, Thorsten.

Can't say it better... Best Regards, Thorsten.

This question has to be answered by Smash himself Best Regards, Thorsten.

Druckfehler Gruss, Thorsten.

Why ripping the firmware of a controller, when MBLC offers much more features? ;-) Best Regards, Thorsten.

If your host program offers the possibility to "learn" MIDI events (this is mostly the case today), you could use the ain64_din128_dout128 application - it supports 64 pots, 128 buttons and 128 LEDs Best Regards, Thorsten.

Hi Robin, I wouldn't use the MIOS_DOUT_PinGet value to toggle the LED, but I would store the state in an array. This has the advantage, that the LEDs could temporary display different informations, and could be switched back to the old saved state. Maybe you don't see the need for such a feature yet, but sooner or later you will be happy that you took this into account from the beginning. There is a simple, and a clever way to realize toggle LEDs. The simple way is the use of an array, which contains one variable for each button/LED. Let's say, DIN 16..31 should be used. Then declare a global array at the top of your .c file: unsigned char toggle_state[16]; // 16 buttons should toggle and write your DIN_NotifyToggle like shown here: void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { unsigned char array_index; // DIN 16..31 should toggle if( pin >= 16 && pin <= 31 ) { if( pin_value == 0 ) { // only react when button is pressed // determine the index of the array element (starts from 0) array_index = pin - 16; // toggle the flag which saves the current button state toggle_state[array_index] ^= 0x01; // '^' is a XOR operation // send MIDI Note event depending on toggle state MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(0x30 + array_index); MIOS_MIDI_TxBufferPut(toggle_state[array_index] ? 0x7f : 0x00); // set LED (same pin number like button) MIOS_DOUT_PinSet(pin, toggle_state[array_index] ? 0x7f : 0x00); } } else { // this branch handles DIN 0..15 and DIN 32..127 } } [/code] The disadvantage of this method: it consumes one byte (8bit) per DIN, but only 1 bit is used to save the toggle state. In order to save memory, it's more clever to store 8 toggle states per byte. This can be done in the following way: global array: [code]unsigned char toggle_state[16 / 8]; // 16 buttons should toggle DIN hook: void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { unsigned char array_index; unsigned char bit_index; // DIN 16..31 should toggle if( pin >= 16 && pin <= 31 ) { if( pin_value == 0 ) { // only react when button is pressed // determine the index of the array element (starts from 0) array_index = (pin - 16) >> 3; // fastest way to divide value / 8; // determine bit position bit_index = (pin - 16) & 0x07; // remainder of x/8 // toggle the flag which saves the current button state toggle_state[array_index] ^= (1 << bit_index); // '^' is a XOR operation // send MIDI Note event depending on toggle state MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(0x30 + pin - 16); MIOS_MIDI_TxBufferPut((toggle_state[array_index] & (1 << bit_index)) ? 0x7f : 0x00); // set LED (same pin number like button) MIOS_DOUT_PinSet(pin, (toggle_state[array_index] & (1 << bit_index)) ? 0x7f : 0x00); } } else { // this branch handles DIN 0..15 and DIN 32..127 } } [/code] Best Regards, Thorsten.

Hi Yarek, I've no experiences with 1x16 displays, therefore I don't know, if this is the normal behaviour or not. But I can confirm, that if the black blocks are displayed only at the left half, that the LCD characters are propably organized like described above (first 8 characters: first line, following 8 characters: second line), and that this is not caused by a connection error. Without changing the firmware at many places (I cannot tell you exactly, at how many... it's a lot of effort), there is no way to use such a LCD - a 1x16 layout was never taken into account Best Regards, Thorsten.

I think it's better to use polarized caps Best Regards, Thorsten.

Hi Marcel, link to the layout: http://www.ucapps.de/mbhp/mbhp_aout_lc_v1.brd link to orderlist: http://www.ucapps.de/mbhp/mbhp_aout_lc_orderlist.txt Yes, the SHX8 board can be used, but there is currently not firmware which supports this combination. And I'm sure that it won't be possible with MBSID or MBFM, but it will be supported by MB64 and MBCV (sooner or later...) Best Regards, Thorsten.

My own MBLC is powered by a cheap switched PSU (5 EUR). after two years of usage it still works great without failures. See also http://www.ucapps.de/midibox_lc/midibox_ng_switching_psu.pdf Best Regards, Thorsten.

The timecode will also be displayed on LCD (in display page #1) - this allows you to check, if Cubase supports this feature. Best Regards, Thorsten.

The PCB: Best Regards, Thorsten.

These are the MIDIbox SID and SEQ made by Julian. Check also his website, where you can find some other SDIY stuff and especially some nice 8bit tunes! :) -> http://www.monome.de

Zu den Encoder-Problemen: vielleicht hilft es schon, wenn Du in mios_tables.inc "MIOS_ENC_MODE_DETENTED" statt "MIOS_ENC_MODE_DETENTED2" eintraegst Ausserdem kann man noch am CS_MENU_ENC_SPEED_VALUE wert in main.src drehen, doch ich wuerde erstmal versuchen, den geeigneten Encoder-Typ herauszufinden. Und noch ein tip: Ich weiss nicht, warum das passieren sollte (evtl. sendet Dein Host Sequencer ein Program Change?), doch wenn es erstmal passiert ist, brauchst Du nicht in das CFG zu gehen. Selektiere einfach beide SIDs gleichzeitig (SID1 druecekn, SID2 druecken, SID2 loslassen, SID1 loslassen), und waehle den Patch direkt auf der Hauptseite an - diese Moeglichkeit klappt uebrigens mit saemtlichen Parameteraenderungen direkt am Control Surface, was im Stereobetrieb sehr angenehm ist :) Gruss, Thorsten.

Hi Knuf, thanks a lot for this input! It seems, that the output impedance of your PC gameport is so high, that the Rx signal level doesn't reach the required TTL low level. I've modified mbhp_midi_gameport.gif (propably you have to push the reload button of your browser to see the change). It's now recommented to remove this resistor, or to replace it by 100k to ensure that MIDI In doesn't get invalid data if the core is not connected to the gameport Best Regards, Thorsten.

should work, but it provides only 8kbyte. All applications which feature BankStick functions always expect at least 32kbyte, but if you are planning to program your own application, this shouldn't be a problem for you Best Regards, Thorsten.

there is only one thing which can cause such an effect, and thats the "brown out reset" unit, which restarts the chip (or holds it in reset state) so long Vdd is less than the selected voltage level. The Bvdd level was ca. 2V before MIOS V1.8, and it is ca. 4.45..4.83V with MIOS V1.8 So, if your PIC is running with MIOS V1.8, there is a high chance that if the PSU is not strong enough, a short voltage drop will cause the reset, and that then the circuit remains in this state due to higher power consumption. I activated this protection mechanism for a good reason, because once the voltage drops below 4.5V, there is a high propability that the BankSticks will be formated unintendionally - therefore a PSU problem cannot be fixed by releasing the protection, but it must be fixed by improving the power connections (or by using a better PSU) A simple way to check if this assumption is the reason for the failure: disable the backlight of your LCD. If this doesn't help, remove also the DOUT module. Is the MBSID running stable under these conditions? Best Regards, Thorsten.

The reason why I recommented to disable interrupts some postings ago was, to find out if a problem is caused by a programming error or not. If you've programmed everything properly (no resource conflicts), this is not required, and debouncing alone helps. The delayed caused by 5 NOPs is not enough, I guess that you need a delay which waits for at least one mS, better 10 mS A proper way to realize such a delay is the use of timers... but I don't have the time to explain you the details, I'm sure that there are informative application notes at the microchip.com website, which explain all the basics! Best Regards, Thorsten.

Could it be, that you forgot to mount the 1k pull-up resistor (R2)? Best Regards, Thorsten.

yes, debouncing is a must, when buttons are connected directly to IO pins and used to trigger events. Best Regards, Thorsten.

Hi, regardless if the application is running or not, you are always able to overwrite it with the first level bootstrap loader, which is active 2 seconds after power-on. So, just switch off/on the power supply, and start the transfer immediately. This will help. Another point: I would suggest the use of MIOS Studio, where you don't need to change the device ID manually Best Regards, Thorsten.

Hi Jan, there are a lot of tips, just search in the forum for "interconnection test" and "interconnection_test" Best Regards, Thorsten.

Please disconnect them all when measuring the voltages - so long the MF module is not controlled by the core, the 74HC595 drive the faders into random directions (or not... or anything randomly happens) Best Regards, Thorsten.

The schematic doesn't show pull-ups at Port B, since this port provides internal pull-ups Best Regards, Thorsten.