TK.

This time from Roberto / Australia - a really cool design with a professional touch! :)

Hi Matthias, I think that your PIC is damaged. The diodes might help, but I cannot give any success guarantee... don't waste PCB area for the diodes, just solder them directly to the buttons. Best Regards, Thorsten.

Alright, banknames would really be usefull. Another suggestion was to display the MIDI Time code like known from MIDIbox Plus. The next firmware will support both. :) Best Regards, Thorsten.

Hi Dave, a great idea! Since three layers are assigned to each pot-row, encoders would improve the handling. I think that 16 encoders are enough, and of course, I could use the MIDIbox16E firmware as skeleton for a MIDIbox16E-SEQ ;-) On the other hand I don't want to spent too much effort on the old firmwares anymore - just wait for MIDIbox NG, it will support both: pots and encoders. And with the plugin capability it will be possible just to "load" a sequencer module into the PIC when required. Best Regards, Thorsten.

Hi Tristan, you could build the LTC module of the MBHP, it can also plugged on the Rx/Tx pins of MIDIbox Plus. Best Regards, Thorsten.

Hi Mandingo, A MIDIbox-Plus like controller can be built with a core module, two 4051 analog multiplexers and one 74HC165 digital input shiftregister. The PIC must run with MIDIbox64 firmware. Best Regards, Thorsten.

Hi Tristan, yes, you should use simple Push buttons, the functional behaviour of the button can be changed in the MIDI Learn menu (or with the MIDIbox editor): "On/Off value" (it's like in your description), "On value only" and "Toggle". Best Regards, Thorsten.

Hi Juanjo, the Exec/Left/Right/Snapshot button should be soldered on special pins - all others are free assignable with special functions or MIDI events. Here the schematic for the first 32 inputs: http://www.ucapps.de/mbhp/mbhp_dinx4_32buttons.pdf Best Regards, Thorsten.

In the MIDIbox64 firmware a lot of tasks are running in parallel (Pot driver, Display driver, Button/LED Driver, Bankstick Driver, MIDI Handler). The sampling period for the buttons is only about 10 mS - thats not fast enough to detect the transitions (falling and rising pulse edges) which are sent by the encoder. The MIDIO128 firmware is optimized for digital IO, the sampling period is about 1 mS and works better, but in my oppinion it's much easier and more fail-save to use a second PIC, running with MIDIbox16E firmware, because the required adaption circuit for each encoder is complex and expensive. Or wait for MIDIbox NG - it will scan up to 128 digital inputs like MIDIO128 and will come with a built-in encoder driver, so that every single input can either be assigned to a button or to an encoder (every encoder requires 2 digital inputs...). Best Regards, Thorsten.

...but it's only available in a SMD package :-/ Best Regards, Thorsten.

Currently I'm rewriting the different display pages of MB64 since some more memory is available after I removed the sequencer and motorfader parts. So, if anybody has a good idea for an usefull layout for 2x40 displays (which additional informations should be displayed?), just let me know. At the moment the layout is similar to the MB16E http://www.ucapps.de/midibox16e_tutorial_en.html (Display Submenu) Best Regards, Thorsten.

Hi Mickey, unfortunately this is a preprogrammed ROM chip which is useless for MIDI. It's a pity that they don't offer the AN2131 of Cypress, because this derivative comes with a bootstrap loader - this special mechanism is activated when the USB cable is plugged in and allows to load the right descriptors and some additional code into the memory so that the device will be recognized as "Standard MIDI-USB device" by Windows, Mac OS X, Linux... without an selfwritten MIDI driver. Best Regards, Thorsten. P.S.: the AN2131 has 2 UARTs (=2 MIDI INs & 2 MIDI OUTs) and costs about US $3 --- but w/ a minimum purchase quantity of 1k devices :-/

Ok, under this circumstances I would do it on the same way. Hm No, I would replace the StudioMix fader logic by the MIDIbox MF driver ;D (Just kidding ;-)) Best Regards, Thorsten.

Hi Dimitris, thats ok - RB0-7 are high impedance digital inputs. Best Regards, Thorsten. P.S.: nice trick! :)

Hi, did you really try it with a PIC16F877, or is it a PIC16F874 with half of the required program memory? When you read back the memory content with IC-Prog, do you see program code the program code from 0x1000-0x1fff? Best Regards, Thorsten.

Hi Christoffer, no, the extended MIDI In is not standardized, but it's usefull :) I only know it from the Atari ST. The 15V input is ok for both modules - since no LCD, no pots and no LEDs are connected to the core module, the 7805 will not get too hot like on common applications. Best Regards, Thorsten.

Schade dass IC-Prog die Fuse-Informationen nicht direkt aus dem .hex File extrahiert, das wuerde solche Fehlerquellen ausschliessen :-/ Die Probleme mit dem BankStick resultieren wahrscheinlich auf der letzten Aenderung in der Dump Struktur. Wenn Du den Stick formatierst, sollte es eigentlich wieder funktionieren. Es lohnt sich allerdings noch nicht, dort Sequenzen dauerhaft zu speichern, da ich die Struktur nochmals aendern werde (jeder Layer soll seinen eigenen Min/Max Werte erhalten). Zu den LEDs: die 64 LEDs werden konfigurierbar sein. Idealerweise setzt man unter jedes Poti eine eigene LED, ge"mute"ete Tracks werden dann so angezeigt wie momentan die ge"mute"ten Poti-Reihen, also invertiert. Da ich meine eigene Box jedoch nicht so ohne weiteres umbauen kann, wird es auch eine alternative Belegung geben, bei der 16 LEDs den Status einer selektierten Poti-Reihe anzeigen, und die restlichen LEDs den Status des SFB's. Mit dem PIC18F kann man spaeter dann bis zu 128 LEDs ansteuern - eigentlich sollte ich die erste Version noch vor Weihnachten rausbringen, die vielen blinkenden LEDs machen sich bestimmt prima als Christbaumschmuck ;-) Gruss, Thorsten.

Hi Christoffer, yes, thats correct. :) I realized it on the same way on the first days. Later I built my SIDs into two seperate boxes, so that I'm able to lend one to friends and to use the other for my daily pleasure :D A particular variation is the way I realized the MIDI In - it comes with an integrated MIDI Thru on the outer pins, also know as "Extended MIDI In" (Atari ST). Here a schematic: http://www.ucapps.de/midibox_sid/mbsid_stereo_midi.pdf Best Regards, Thorsten. P.S.: I song I made with those two SIDs can be found under http://mp3.de/frequencies (Lovesong for my SIDs ;-))

Yes - unfortunately the statement I made in this old posting: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=old_forum;action=display;num=10308161100;start=2 are still valid. My still hope is that some day ultracheap USB devices are available (for example an USB-Mouse for less than 10 EUR) with an reprogrammable chip which can be canibalized for a MIDI adapter. Best Regards, Thorsten.

Servus, Lemonhorse: danke fuers Lob, auch mir gefaellt das neue Handling nun wesentlich besser. Vorbei ist die Zeit, in der man sich durch die cryptischen Play- und Loopmodes kaempfen musste, nun gilt es, die neuen Moeglichkeiten zu erforschen :) Ich habe gerade das releaste .hex-File nochmal in meinen PIC geladen - bei mir werden die MIDI Daten korrekt versendet. Ist bei Dir vielleicht etwas beim Flashen schiefgelaufen? Vielleicht solltest Du den PIC nochmals flashen und anschliessend die Verify-Funktion aufrufen. Simolch: ja, das kann man bereits alles so konfigurieren, allerdings nur direkt in der Firmware. Sobald die SysEx Dump Struktur "final" ist, werde ich die neue Variante in das mk_syx Script einbauen, so dass man sich die Buttons auch selbst konfigurieren kann (Stichwort: Special Button Events). Naeheres zu diesem Thema gibt es dann irgendwann auf einer separaten Webpage. Gruss, Thorsten.

In fact this is one kind of jitter when you combine the High- and Low byte to a 14-bit value. Since you want to send out a 7-bit value, the simplest way is to work internally with 8-bit values - the NRPN can be converted on this way: clrc rlf NRPN_HI, W ; shift left NRPN High byte IFSET NRPN_LO, 6, iorlw 0x01 ; copy MSB of NRPN low Byte (7-bit) to Bit 0 movwf FADER_VALUE ; save result in FADER_VALUE Best Regards, Thorsten. P.S.: your registers do partly overlap the RINGBUFFER0 address area at 0x70-0x7b. Suggestion: move the ringbuffer to Bank1 and locate the registers in between 0x30 and 0x7b. ;; 0xa0-0xef: SUART IN Ringbuffer RINGBUFFER0 EQU 0xa0 RINGBUFFER0_END EQU 0xef The Ringbuffer could also be located in Bank 2 or 3, but for this some additional changes are required

To which address did you assign the DELTA registers? If you want to access them on the normal way, they should be in between 0x20 and 0x7f. Registers above this range are located in different banks, and you have to switch to the appr. bank to get the right values. An oversight of available RAM registers for PIC16F877: 0x20-0x6f: Bank 0 0x70-0x7f: all Banks 0xa0-0xef: Bank 1 0xf0-0xff: all Banks 0x110-0x16e: Bank 2 0x170-0x17f: all Banks 0x1a0-0x1ef: Bank 3 0x1f0-0xff: all Banks Microchip recomments the use of a special assember directive to switch between the banks. But this directive generates 2 instructions for each bankswitching, and so I've created some macros which helps me to reduce the code, it's: SWITCHBANK_0_1, 0_2, 0_3, 1_0, ... 3_0 So, when your delta registers are located in Bank 1, write this: SWITCHBANK_0_1 movf DELTA2, W subwf JITTER_DELTA, W SWITCHBANK_1_0 If JITTER_DELTA is a constant, write: SWITCHBANK_0_1 movf DELTA2, W sublw JITTER_DELTA SWITCHBANK_1_0 Note: sometimes it's easier to access the registers indirectly. Btw.: here the jitter elimination code of MIDIbox MF. IRQFADER_SNAP contains the target position, IRQFADER_VALUE the current position: ;; --- check distance between current and target position ;; --- if fader is in between "deadband", don't move it ;; addlw 255 - Hi ;; addlw (Hi - Lo) + 1 ;; Carry is set if W is in range Lo - Hi movf IRQFADER_SNAP, W addlw 1 skpnc movlw 0xff sublw 0xff movwf IRQ_TMP1 movf IRQFADER_VALUE, W ; get last sampled value addwf IRQ_TMP1, W ; compare it with snapped value addlw 2+1 bnc MOTOR_Move ; carry is set if value is in between range bz MOTOR_Move ; special case if fader == 0xff and target == 0x00 MOTOR_DontMove ;; --- Dont Move Fader -> Standby call MOTOR_StandBy Best Regards, Thorsten.

Hi, normaly I don't use a debugger for my code. The MPLAB simulator is nice for verifying algorithms, but useless for checking a realtime system. Here an extract of different debugging methods I'm using: I print out some values on a LCD if I want to check the behaviour of my routines during runtime. This is only usefull if only a small number of values have to be displayed which don't change too fast. for fast changes I write the values into a seperate SFR region which acts as a ringbuffer and which is printed out by the LCD on every mainloop cycle. On this way the SFR region acts as "trace memory". When I have to observe a lot of value changes, I send them out as MIDI events and use MIDI-Ox to write them into a logfile When I have to send stimuli to the core module, I use the SysEx editor of MIDI-Ox which allows to send any (also invalid!) MIDI data. (type "BF 63 23 BF 62 17" into the command window and press the send button). The SysEx editor can also be used to save the stimuli I generate stimuli files with a short perl script, send them out with the SysEx editor, save the responses from the core module into a logfile and use a second perl script to filter out the data which is interesting for me I use a MIDIbox as stimulus generator I use a scope which is connected to the spare pin (J14) to monitor internal events in realtime. On this way I see how many times a particular routine is executed and how long it does get Best Regards, Thorsten.

Hi Matthias, the explanation for the problem can be found here: http://www.ucapps.de/midibox/midibox_plus_16.pdf Magnify the red text beside of the 8 additional diodes. Best Regards, Thorsten.

The messages are ok. Hrmpf, I'm totally unsure why your display doesn't work with the SID firmware. Does it work with other firmwares like MB64, MB64SEQ or MB16E? On the other hand: for the SID a LCD isn't required yet, it gives you no usefull messages. Best Regards, Thorsten.