TK.

I would prefer the table based method, it's much faster (just compare the produced .asm code in _output) Fine that you are starting with a CS in C - this will be a great contribution! :) Best Regards, Thorsten.

So, which voltage do you get with the shift register - not the PIC - out? Best Regards, Thorsten.

You mean the shift register, not the PIC, right? I'm not 100% sure. Since you own a DINX4 module, you could swap the faulty (?) one with another and check what happens Best Regards, Thorsten.

Da man nur innerhalb eines Patterns (4 Tracks, 32 Steps) verketten kann, kommt man auf maximal 128 Steps. Ja. Die Button Loesung eignet sich vor allem fuer Drums, aber auch fuer Synth-Sequenzen, bei denen man dann waehrend der Laufzeit die bereits vorbereiteten Steps ein- und ausschaltet (siehe die beiden Videos auf YouTube). Eine Kombination aus zwei MBSEQ's macht sich sicherlich gut, zumal ich im SysEx Menue eine Moeglichkeit eingebaut habe, Patterns auf eine andere MIDIbox zu uebertragen. Theoretisch waere es auf diese Weise sogar moeglich, bis zu 127 MIDIbox SEQ "Slaves" zu betreiben, wobei jeder Slave lediglich aus einem Core Modul besteht ;-) Gruss, Thorsten.

Should be 5V... which voltage do you measure, when the 74HC165 is not stuffed (remove it from the socket) Is it still 3.3V? Best Regards, Thorsten.

Zum Thema "MBSEQ Varianten" ist mir noch eingefallen, dass zwar zusaetzliche Encoder und LCDs die Performance zu sehr beeintraechtigen, zusaetzliche Buttons und LEDs jedoch problemlos bedient werden koennen, wenn man sie zu einer Matrix zusammenschaltet (aehnlich wie bei der MIDIbox FM) Beispielsweise wuerde man fuer 4x32 LEDs und Buttons gerade mal drei 74HC595 und zwei 74HC165 benoetigen - ideal zum Live jammen :) Theoretisch waeren uebrigens auch LEDs und Buttons fuer alle 16 Tracks drin. Bleibt die Frage, wie man 512 LEDs und Buttons sinnvoll in einem bezahlbarem Gehaeuse unterbekommt? Gruss, Thorsten.

Seems that you are accessing the wrong registers, they have a "0" access type instead of "BANKED" ("1") like in the original and like in stryd_one's example. This explains also, why you don't see the expected pattern at the DOUTs try this, it might work better: unsigned char loop_ctr; // loop counter unsigned int aout_sr0; // chain data unsigned int aout_sr1; void AOUT_Load2SR(unsigned int sr0_value, unsigned int sr1_value) { aout_sr0 = sr0_value; aout_sr1 = sr1_value; __asm bcf CV_AOUT_LC_LAT_SCLK, CV_AOUT_LC_PIN_SCLK ; clear clock COPIED FROM MBCV DRIVER ;; bcf AOUT_LAT_CS, AOUT_PIN_CS ; activate chip select NOT NEEDED FOR AOUT_LC ;; I believe that the below might be able to be ignored for the AOUT_LC? ;; you will notice that the instructions are sometimes arranged ;; in a special order to ensure proper output signals - for example: ;; between a rising and a falling SCLK edge there is at least one ;; other instruction to ensure that the high pulse of the SCLK ;; is longer than 100 nS (the MAX525 datasheet specifies at least 40 nS) banksel _loop_ctr movlw 32 ; init loop counter FOR 2 AOUT_LC modules movwf _loop_ctr, BANKED ;; This is the same as the original AOUT driver with the names changed, and the latching copied from the MBCV AOUT_Load2SR_Loop: banksel _aout_sr0 bcf CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT ; set DOUT depending on current MSB btfsc _aout_sr1+1, 7, BANKED bsf CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT rlcf _aout_sr0+0, F, BANKED ; start to shift the 16-bit value rlcf _aout_sr0+1, F, BANKED ; second step for the 16-bit shift rlcf _aout_sr1+0, F, BANKED ; third step for the 16-bit shift rlcf _aout_sr1+1, F, BANKED ; last step for the 16-bit shift bsf CV_AOUT_LC_LAT_SCLK, CV_AOUT_LC_PIN_SCLK ; rising clock edge MOVED FOR AOUT_LC DRIVER bcf CV_AOUT_LC_LAT_SCLK, CV_AOUT_LC_PIN_SCLK ; falling clock edge banksel _loop_ctr decfsz _loop_ctr, F, BANKED ; loop 32 times bra AOUT_Load2SR_Loop bsf CV_AOUT_LC_LAT_RCLK, CV_AOUT_LC_PIN_RCLK ; latch SID values bcf CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT ; clear out pin (standby) bcf CV_AOUT_LC_LAT_RCLK, CV_AOUT_LC_PIN_RCLK ; release latch } [/code] Best Regards, Thorsten.

A shorter form to write this is: 76543210 76543210 76543210 76543210 00000000 11000000 00000000 00110000 Expected pattern is: 76543210 76543210 76543210 76543210 10000000 10000000 10000000 10000000 How does the AOUT_Load2SR routine look like in the meantime? Best Regards, Thorsten.

After the values are shifted, which logic levels do you measure at the output pins of the 74HC595s? With 0x8080,0x8080 I would expect: O7=1 O6=0 O5=0 O4=0 O3=0 O2=0 O1=0 O 0=0 With 0x4040,0x4040 I would expect: O7=0 O6=1 O5=0 O4=0 O3=0 O2=0 O1=0 O 0=0 etc. Does AOUT_Load2SR shift the registers 32 or 16 times? Best Regards, Thorsten.

Thats correct. The usage of 74HC595 is easier, because all bits are directly transfered to the output, there is no command register, and no channel multiplexer like on the MAX525 This means in other words: when you shift in 8 bits, and toggle the RCLK, the bits will be visible at the output ports. When two 74HC595 are chained, like on the AOUT_LC module, you need to shift in 16 bits, and toggle RCLK thereafter. And when multiple AOUT_LC modules are chained (which means n*2 74HC595 chained), you need to shift in n*2*8 bits and toggle RCLK thereafter. This can be very easily debugged. Just replace all the stuff inside AOUT_Update with a single call of the AOUT_Load2SR function. I don't know, if you are using 16 or 32 bit shifting in the meantime, but at the beginning just write following: void AOUT_Update(void) { AOUT_Load2SR(0x8080, 0x8080); } [/code] now you should see 2.5V at the R-2R ladder output. (I assume that you are using the 2*8 bit configuration of the AOUT_LC module) When you are writing: AOUT_Load2SR(0x4040, 0x4040); you should see 1.25V Does it work? Best Regards, Thorsten.

Hallo, Vielleicht koennte man die wirklich extremen Ueberweisungskosten minimieren, indem jemand die Teile innerhalb Deutschlands bestellen, und Dir dann zuschicken wuerde. Hast Du einen PayPal Account? nein, das geht nicht. Zum einen wird diese Option nicht von der Firmware unterstuetzt, zum anderen wuerden noch mehr Encoder und LCDs die CPU so stark auslasten, dass das MIDI Timing in Mitleidenschaft gezogen wuerde. Auf die Timings sollte man hoechste Prioritaet legen. Ja, das ist richtig, wobei dies eigentlich keine ideale Konfiguration ist. Sie eignet sich eigentlich nur zum tuefteln an einzelnen Tracks, sobald man auf einen anderen Layer (bspw. Velocity oder Notenlaenge), oder auf eine andere Trackgruppe (es gibt 4) umschaltet, zeigen die Potis ja nicht mehr auf die aktuellen Werte. Insofern mag diese Loesung vielleicht freakig sein, aber in der Praxis muss man viele Abstriche in Kauf nehmen. Die Poti-Variante gibt es eigentlich nur deshalb, weil MBSEQ V1 damit ausgestattet war. Es gibt eine FAST Taste, mit der eine Beschleunigung aktiviert wird, die aehnlich wie bei einer Computermaus funktioniert. Mit einem schnellen Dreh kann man so ueber den gesamten Wertebereich fahren, wenn man langsamer dreht, kann man nach wie vor den Wert mit einer feinen Aufloesung einstellen. Mal schauen, was die anderen dazu sagen. Ja, insofern hast Du da auch noch ein bisschen Spiel. Wenn sie dafuer vorgesehen sind: ja. Die Panasonic Encoder sind wohl nicht zum Verschrauben, sondern nur fuer Printmontage vorgesehen. Noch ein Hinweis zum Schluss: fuer MBSEQ V3 benoetigt man statt des PIC18F452 einen PIC18F4620. Dieser Chip hatte bisher einen Bug, der ihn fuer MIDI unbrauchbar machte. Vor ein paar Wochen ist eine neuere Version herausgekommen, die hoffentlich bald auch in Europa verfuegbar sein wird. Der Chip kostet genausoviel wie ein PIC18F452 (ca. 8 EUR)... Ich wuerde vorschlagen, dass Du den Sequenzer erstmal mit dem PIC18F452 bestueckst, und mit der MBSEQ V2 in Gang bringst. Spaeter kannst Du dann umruesten. Der Umstieg lohnt sich dann auf jeden Fall, denn es sind eine Menge Features hinzugekommen - auch was die Bedienbarkeit angeht - die man in der V2 schmerzlich vermissen wird :-) Gruss, Thorsten.

What happens, when you are entering "type tools\mkmk.pl" in the command shell? Does it find the file? Best Regards, Thorsten.

The prebuilt .hex files are used by most people, and not at least by myself. Therefore the propability is very low, that we are hunting for a software issue. Charles is using the default hardware setup... Best Regards, Thorsten.

I don't think that it is required to build a new .hex file If there is an hardware issue, it's easier to debug this with the MIDIO128 application - all buttons should trigger a single MIDI event, see also http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

It's basically the same procedure like with the old ones. You only need to select the right binaries in the mios_v1_9_update package. The applications are binary compatible and don't need to be recompiled Just only take care that you are using the latest MIOS Studio release, which contains a bugfix for PIC18F4620 uploads I haven't started with MBSID V2 yet, but MBSEQ V3 is nearly finished. It's available via email request. I've now released a small application which allows you to determine the revision ID, it's available under http://www.ucapps.de/mios_download.html From the README.txt This program displays the Revision ID of a PIC18F and sends it also via MIDI as CC# event Known numbers (mostly documented in the errata sheets of the PIC devices) - 0427: PIC18F452 C1 Silicon (latest and greatest) - 0C03: PIC18F4620 A3 Silicon (contains EUSART bug) - 0C04: PIC18F4620 A4 Silicon (contains EUSART bug) - 0C06: PIC18F4620 B4 Silicon (the good one w/o EUSART bug) [/code] Best Regards, Thorsten.

Sieht ganz gut aus :) Aber ich wuerde das Datawheel nicht oberhalb des Displays platzieren - wenn Du an den Werten schraubst, ueberdeckt Deine Hand das LCD Gruss, Thorsten.

If it really helps: http://www.ucapps.de/tmp/mbsid_old.zip (link will be removed tomorrow) If you want to learn more about CS programming, than have a look into the MIDIbox TC application - this was a "prove of concept" for the MBSID menu handling, and contains more comments for the "simple" things, which are not commented anymore in MBSID Best Regards, Thorsten.

They are out? This sounds great! Than higher the propability that they will get the brand new chip revision from Microchip :) Best Regards, Thorsten.

I don't know SmashTV's variant so good, therefore I cannot help here so much. But you could just compare your wiring with the original schematic. You can follow the tracks from the 74HC165 to the terminals of your board in order to find out the right pinning Best Regards, Thorsten.

http://www.farnell.de for 8.10 EUR Best Regards, Thorsten.

In the other lines it's 1, 2, 3 - it just selects the output channel I must say, in the meantime I find it funny which details can be discussed on a code I hacked in within 10 minutes ;-) Most of this stuff is just "standard programming". Some lines might look strange when they are out of context, but they make sense when you see the whole code and compare it with the MAX525 datasheet. Best Regards, Thorsten.

I think this was a typing error - Altitude is right, R1 is connected correctly to the LM317, but it's hard to see it without eagle. Best Regards, Thorsten.

It's the *_plus.brd file - Mike will send me a fixed version in the next days Best Regards, Thorsten.

Wow! What a great price! How to highlight this posting? Because some people asked for faders in the past and found much more expensive offerings - they could be saved from paying too much money Best Regards, Thorsten.

In my oppinion it makes sense to talk about a single board solution again after the first release. Who knows what will change until then... as mentioned several times before: I can only guarantee, that with the modular concept you will have the highest flexibility. Best Regards, Thorsten.