TK.

As described at the User Manual: Hardware page, the 4x16 BLM is already supported. For future, I consider to create a new 16x16 button/LED matrix, this time built on a PCB to avoid all the soldering effort. Probably it will be based on MAX7221 chips as serial shift registers and LED driver. Once I have the hardware, I can add a sophisticated SW support. I'm planning a lot of functions for such a matrix, like direct drum track editing (all 16 instruments in a view), direct track mutes editing (all 16 tracks in a single view), setting loop points, alternative pattern selection (as 256 buttons are available), etc... It's even feasible to cascade 16x16 matrices to a giant display ;) MIDI Clock can be sent by any MIDI port, and it can be enabled individually as described at the User Manual: Menu Pages IIC: 4 modules are natively supported, the usage of 8 modules is feasible (with a firmware hack) as described at the User Manual: Hardware page Best Regards, Thorsten.

Ploytec told me, that the legacy USB MIDI driver provided by Microsoft doesn't work with Vista 64bit (thats one of the reasons why they developed an own driver - but it will only work with a GM5). I don't know, if Microsoft supports the legacy driver for the 64bit version of Win7 Best Regards, Thorsten.

Thats the normal behaviour of most 1x16 displays - unfortunately... When you are using the search function of this forum, you will find many postings where people reported the same. What's exactly your boot message? Controller compatibility doesn't ensure, that characters are print at the same position. The character position depends on the way, how the manufacturer connected the LCD row/columns to the controller. However, if you are planning to program your own application, the solution is simple: use 0x00..0x07 to address the left half, and 0x40..0x47 to address the right half. Best Regards, Thorsten.

Will be shipped tomorrow: Khron_X verpeiler roman01 Napiks joeribl gbraad timyo unit-sound Best Regards, Thorsten.

There are (more or less) bad news, but also good news: The PCB fab delivered the old v1_1 layout by mistake. It has no J8 jumper (1) and no ground rings around the USB socket (2). Both are minor improvements, the v1_1 board will work perfectly. (1) requires to solder a cable from pin IO5 (#10) to ground if your interface should be named "midibox.org" instead of "ploytec". The GM5 will work perfectly as "ploytec" device, so that this cable is really optional. (2) has only been added for mechanical robustness reasons. Your board will work without changes, but if you want to improve it, just follow TheProf's instructions The good news: Ploytec is very sorry for this mistake, and the Fab will send us 100 v1_2 PCBs for free! The PCBs will be available in some weeks. If I already sent you a v1_1 board, and you want a replacement (for whatever reason), just contact me and I will send you the new ones (once available). Shipping will be free People who haven't got their order yet, will be asked if they prefer v1_1 or v1_2 (as mentioned above: it will take some additional weeks until the PCBs will be available) I will sell the remaining free v1_2 boards to cover the additional shipping costs, and the rest of the extra money as a donation to finance my upcoming MIDIbox projects. Best Regards, Thorsten.

Hi Solarvent, it really surprises me every time to read from people who use a MIDIbox since years, but never had to ask for help. :) In SmashTV's MIDIbox Shop you will get the PCB + presoldered STM + kit components for ca. 32 EUR But we are missing a lot of components which are useful for MBHP related purposes, like the 3.3V->5V level shifter for two LCDs, two MIDI IN/OUTs, etc. You should also consider, that the STM32 board from SmashTV comes with MIOS32 bootloader, so that the application can be uploaded via USB (no need to use a RS232 bootloader interface in order to program the MIOS32 bootloader into flash) A killer - I guess it's only a STM32F103RB derivative. Not only the flash/RAM is limited. There are only 8 (instead of 16) DMA channels, etc... No, MBSEQ V4 currently requires ca. 200k flash and ca. 60k RAM. For future versions I'm planning to use the complete flash of course. Yes, there is a "MIOS32_BOARD" option for the first Primer, it works but it's just a toy (especially because of the smaller STM32F103RB derivative) An adaption for Primer2 is feasible w/o much effort, but I don't have this board right here. You won't save time and/or money by buying this evaluation board. As Smithy already wrote: you would have to add the additional components (like MIDI ports and 74HC595 based LCD levelshifters) on a prototype board anyhow. Thats basically more effort than soldering a MBHP_CORE_STM32 kit Best Regards, Thorsten.

Will be shipped tomorrow: fussylizard rosch audio-mobster xaoe morganphalen Janis1279 Tamiflu meToo listen202 Protosx Flexinoodle Lorcan zemika bluescreen niietzshe benuron Shortplay kc Pivado cokrax Best Regards, Thorsten.

Alternatively you could just upload the table with MIOS Studio (only a small .hex file has to be uploaded to a specific range). The implementation would be much easier for me, as the infrastructure already exists! Why not creating a modulation path from Key -> Wavetable position ("MOD" flag must be enabled in WTC!), and controlling the finetune parameter from there? The WT can store up to 128 bytes, accordingly you can assign a dedicated finetune value for each key! :) You could also control Detune this way... or any other parameter. Thanks - I will come back to this table once I find the time. Best Regards, Thorsten.

Thank you! :) Wilba handles the Bulk order. Best Regards, Thorsten.

Yes, the module and the optional kit is now available in SmashTV's Shop. :) It won't be available in Mike's shop since it doesn't make much sense to distribute only the PCB w/o presoldered and tested STM32 chip. Have fun! (Looking forward for more videos once your box has been upgraded! :)) Best Regards, Thorsten.

Auch diesen Typo habe ich nun gefixed ;) Ok, habe ich in MIOS und MIOS32 nun ebenfalls eingebaut. Das waere nett - das Tolle an Deiner Loesung ist ja u.A, dass sie sich so einfach dokumentieren laesst! :) Ich werde noch ein wenig warten, bis ich eine neue MIOS Version release - vorher moechte ich mir 100% sicher sein, dass die Aenderung nicht zu neuen Problemen fuehrt. Es ist uebrigens schon abzusehen, dass ein paar Newbies ueber diese Aenderung stolpern werden - bspw. wenn sie eine neu kompilierte Applikation auf einen PIC aufspielen, der von SmashTV mit MIOS V1.9f vorprogrammiert wurde - umso wichtiger, dass alle betroffenen Projekte einen nicht uebersehbaren Hinweis ueber den erforderlichen MIOS Update erhalten. In MIOS32 ist die Aenderung mit sofortiger Wirkung gueltig ;) Gruss, Thorsten.

Waehrenddessen habe ich die Aenderung auch in MIOS32 eingebaut: mios32_enc.c if( (enc_state_ptr->state == 0x01 && (enc_type & (1 << 4))) || (enc_state_ptr->state == 0x07 && (enc_type & (1 << 5))) || (enc_state_ptr->state == 0x0e && (enc_type & (1 << 6))) || (enc_state_ptr->state == 0x08 && (enc_type & (1 << 7))) ) { // DEC ... } else if( (enc_state_ptr->state == 0x02 && (enc_type & (1 << 0))) || (enc_state_ptr->state == 0x0b && (enc_type & (1 << 1))) || (enc_state_ptr->state == 0x0d && (enc_type & (1 << 2))) || (enc_state_ptr->state == 0x04 && (enc_type & (1 << 3))) ) { // INC ... } [/code] Sieht schon wesentlich kompakter aus, und funktionierte deshalb auch auf Anhieb mit meiner MBSEQ V4! :) So sieht uebrigens der vom Compiler generierte ARM Assembler Code aus: [code] if( (enc_state_ptr->state == 0x01 && (enc_type & (1 << 4))) || 801d56c: f818 2007 ldrb.w r2, [r8, r7] 801d570: f002 030f and.w r3, r2, #15 ; 0xf 801d574: 2b01 cmp r3, #1 801d576: d102 bne.n 801d57e <MIOS32_ENC_UpdateStates+0x9e> 801d578: f014 0f10 tst.w r4, #16 ; 0x10 801d57c: e00d b.n 801d59a <MIOS32_ENC_UpdateStates+0xba> 801d57e: 2b07 cmp r3, #7 801d580: d102 bne.n 801d588 <MIOS32_ENC_UpdateStates+0xa8> 801d582: f014 0f20 tst.w r4, #32 ; 0x20 801d586: e008 b.n 801d59a <MIOS32_ENC_UpdateStates+0xba> 801d588: 2b0e cmp r3, #14 801d58a: d102 bne.n 801d592 <MIOS32_ENC_UpdateStates+0xb2> 801d58c: f014 0f40 tst.w r4, #64 ; 0x40 801d590: e003 b.n 801d59a <MIOS32_ENC_UpdateStates+0xba> 801d592: 2b08 cmp r3, #8 801d594: d13b bne.n 801d60e <MIOS32_ENC_UpdateStates+0x12e> 801d596: f014 0f80 tst.w r4, #128 ; 0x80 801d59a: f000 808a beq.w 801d6b2 <MIOS32_ENC_UpdateStates+0x1d2> (enc_state_ptr->state == 0x07 && (enc_type & (1 << 5))) || (enc_state_ptr->state == 0x0e && (enc_type & (1 << 6))) || (enc_state_ptr->state == 0x08 && (enc_type & (1 << 7))) ) { // DEC ... } else if( (enc_state_ptr->state == 0x02 && (enc_type & (1 << 0))) || 801d60e: 2b02 cmp r3, #2 801d610: d102 bne.n 801d618 <MIOS32_ENC_UpdateStates+0x138> 801d612: f014 0f01 tst.w r4, #1 ; 0x1 801d616: e00d b.n 801d634 <MIOS32_ENC_UpdateStates+0x154> 801d618: 2b0b cmp r3, #11 801d61a: d102 bne.n 801d622 <MIOS32_ENC_UpdateStates+0x142> 801d61c: f014 0f02 tst.w r4, #2 ; 0x2 801d620: e008 b.n 801d634 <MIOS32_ENC_UpdateStates+0x154> 801d622: 2b0d cmp r3, #13 801d624: d102 bne.n 801d62c <MIOS32_ENC_UpdateStates+0x14c> 801d626: f014 0f04 tst.w r4, #4 ; 0x4 801d62a: e003 b.n 801d634 <MIOS32_ENC_UpdateStates+0x154> 801d62c: 2b04 cmp r3, #4 801d62e: d140 bne.n 801d6b2 <MIOS32_ENC_UpdateStates+0x1d2> 801d630: f014 0f08 tst.w r4, #8 ; 0x8 801d634: d03d beq.n 801d6b2 <MIOS32_ENC_UpdateStates+0x1d2> (enc_state_ptr->state == 0x0b && (enc_type & (1 << 1))) || (enc_state_ptr->state == 0x0d && (enc_type & (1 << 2))) || (enc_state_ptr->state == 0x04 && (enc_type & (1 << 3))) ) { Im Endeffekt benoetigt der Cortex M3 ca. 90 Bytes zur Auswertung, und der PIC 106 Bytes. Hier laesst sich vielleicht noch etwas rausholen, doch dann wird der Code wirklich unlesbar... Gruss, Thorsten.

Habe die Aenderung nun an meiner MBSID (DETENTED2) gestestet, und einen weiteren Tippfehler gefunden. Nun funktioniert es! Es zeigt sich mal wieder, wie fehleranfaellig Assemblercode beim RabidRapid Prototyping ist... Gruss, Thorsten.

Haette den Code vorher vielleicht doch nochmal ausprobieren sollen - ich habe ihn nach einer zweiten visuellen Kontrolle abermals geaendert, ihn jedoch nach wie vor nicht getestet - dafuer bist Du ja da ;) Der Typo: das TABLAT, <bit> war nach IRQ_TMP4, <bit> gerutscht. Das kommt davon, wenn man am kleinen Notebook Bildschirm tippt... Gruss, Thorsten.

P.P.S.: Du musst nochmal updaten, da war noch ein Schreibfehler...

Ok, habe die Aenderung eingebaut, nun muesstest Du mal Dein Repository updaten, ein neues MIOS bauen und aufladen. Geaenderte Files: mios_enc.inc macros.h cmios.h Unschoen: die Applikationen sind nun nicht mehr binaerkompatibel zur alten MIOS Version - muessen also ebenfalls neu kompiliert werden. :-/ (zum Glueck kein Problem fuer MIOS32, da es direkt in die Applikation gelinkt wird) Viel Spass beim Testen! Gruss, Thorsten. P.S.: hier der geaenderte Code - er sieht zwar etwas laenglich aus, verbraucht jedoch exakt genausoviele Bytes wie die Jumptable zuvor - und wird zudem schneller abgearbeitet und ist dank Deiner Idee mit der speziellen Kodierung des Encoder Typs flexibler! BRA_IFSET IRQ_TMP4, 3, ACCESS, MIOS_ENC_Do_89ABCDEF MIOS_ENC_Do_01234567 BRA_IFSET IRQ_TMP4, 2, ACCESS, MIOS_ENC_Do_4567 MIOS_ENC_Do_0123 BRA_IFSET IRQ_TMP4, 1, ACCESS, MIOS_ENC_Do_23 MIOS_ENC_Do_01 ;; 0: Do_Nothing ;; 1: Do_Dec BRA_IFCLR IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 4, ACCESS, MIOS_ENC_Do_Dec rgoto MIOS_ENC_Do_Nothing MIOS_ENC_Do_23 ;; 2: Do_Inc ;; 3: Do_Nothing BRA_IFSET IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 0, ACCESS, MIOS_ENC_Do_Inc rgoto MIOS_ENC_Do_Nothing MIOS_ENC_Do_4567 BRA_IFSET IRQ_TMP4, 1, ACCESS, MIOS_ENC_Do_67 MIOS_ENC_Do_45 ;; 4: Do_Inc ;; 5: Do_Nothing BRA_IFSET IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 3, ACCESS, MIOS_ENC_Do_Inc rgoto MIOS_ENC_Do_Nothing MIOS_ENC_Do_67 ;; 6: Do_Nothing ;; 7: Do_Dec BRA_IFCLR IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 5, ACCESS, MIOS_ENC_Do_Dec rgoto MIOS_ENC_Do_Nothing MIOS_ENC_Do_89ABCDEF BRA_IFSET IRQ_TMP4, 2, ACCESS, MIOS_ENC_Do_CDEF MIOS_ENC_Do_89AB BRA_IFSET IRQ_TMP4, 1, ACCESS, MIOS_ENC_Do_AB MIOS_ENC_Do_89 ;; 8: Do_Dec ;; 9: Do_Nothing BRA_IFSET IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 7, ACCESS, MIOS_ENC_Do_Dec rgoto MIOS_ENC_Do_Nothing MIOS_ENC_Do_AB ;; A: Do_Nothing ;; B: Do_Inc BRA_IFCLR IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 1, ACCESS, MIOS_ENC_Do_Inc rgoto MIOS_ENC_Do_Nothing MIOS_ENC_Do_CDEF BRA_IFSET IRQ_TMP4, 1, ACCESS, MIOS_ENC_Do_EF MIOS_ENC_Do_CD ;; C: Do_Nothing ;; D: Do_Inc BRA_IFCLR IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 2, ACCESS, MIOS_ENC_Do_Inc rgoto MIOS_ENC_Do_Nothing MIOS_ENC_Do_EF ;; E: Do_Dec ;; F: Do_Nothing BRA_IFSET IRQ_TMP4, 0, ACCESS, MIOS_ENC_Do_Nothing BRA_IFSET TABLAT, 6, ACCESS, MIOS_ENC_Do_Dec ;; rgoto MIOS_ENC_Do_Nothing [/code]

Das nenne ich mal eine Innovation! :) Die Verwendung einer Tabelle wuerde zu mehr Code und einer laengeren Laufzeit fuehren, da TBLPTR[LHU] ja bereits zum Auslesen der Encoder-Tabelle verwendet wird. Es gibt jedoch eine einfache Methode, um selbst die Jumptable zu umgehen (via Checkbit- und Branch). Ich werde das gleich mal blind einhacken, und die Aenderung in das Repository stellen - heute noch Lust, die Aenderung auszuprobieren? Dank der speziellen Codierung muss MIOS wohl nur einmal neu aufgeladen werden :) Gruss, Thorsten. P.S.: den Thread splitte ich gleich

Hi, it's difficult, but not impossible. Basically the formula is: (128 * (POT_VALUE-MIN))/(MAX-MIN) This has to be calculated in fixed point arithmetic. Let's check the required value range for the worst case (MIN=0, MAX=1023, POT_VALUE=1023): dividend: 128*(1023-0)) = 130944 (thats a 17 bit value) divisor: (1023-0) = 1023 (thats a 10 bit value) To calculate the dividend, a multiplication with 128 is required. This can be done by leftshifting (POT_VALUE-MIN) 7 times. In addition, we have a 16bit substraction. The divisor has to be calculated with a 16bit substraction as well. The divison will be 24/16 bit I've an example here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fmath_div24_16.inc In the MBSID source code you will also find many examples for a 16bit substraction and for leftshifting values if required (I don't know your knowledge level, unfortunately you forgot to introduce yourself!) Best Regards, Thorsten.

Ich werde Deine Tabelle in die aktuelle MIOS Version einbauen. Das kostet dann zwar 40 zusaetzliche Bytes, doch die sind es wert! ;) Wenn man DETENTED[45] wie folgt codiert: MIOS_ENC_MODE_DETENTED2 EQU 0xc3 MIOS_ENC_MODE_DETENTED3 EQU 0xc4 [/code] dann koennte man einfach nach einer positiven Ueberpruefung des 7ten Bits zur alternativen Tabelle verzweigen. Gruss, Thorsten.

- USB for more than 100 times faster transfers - the capability to drive any graphical LCD type (even the cheap ones) without performance impact - possibility to communicate via ethernet by using OSC messages (not related to LC protocol, but a nice option) Best Regards, Thorsten.

Yes, you can! (see the two MBSEQ V4 demo videos) MBHP_CORE_STM32:J8/J9 and J1 of the Frontpanel PCB can be connected with a 1:1 cable: Best Regards, Thorsten.

:) Best Regards, Thorsten.

Which MIDI interface is connected to the MIDI OUT of your core module? And: http://www.ucapps.de/howto_debug_midi.html What's the result of TEST_INOUT1? Best Regards, Thorsten.

It will work with PBrennerNG: http://www.sprut.de/electronic/soft/pbrenner/pbrenner2.htm Best Regards, Thorsten.

Hallo Alex, danke fuer die Ursachenforschung! Ich habe bereits erwartet, dass sich das Problem so einfach loesen laesst, bin jedoch nicht davon ausgegangen, dass da noch jemand anderes "durchsteigt". ;) MIOS scannt die Pins periodisch, und wertet sie dann mit einer Finite State Machine aus. Deine Tabelle findest Du unter mios_enc.inc wieder: ; State Machine (own Design, the Machine from Microchip on AN519 ; is too simple and doesn't work correctly!) ; changed 2000-1-5: special "analyse" state which corrects the ENC direction ; if encoder is rotated to fast - I should patent it ;-) ;; ENC_STAT[3..0] = LB, LA, B, A ;; type 0x00 - INC: 2, B, D, 4 ;; DEC: 1, 7, E, 8 ;; type 0x80 - INC: B, 4 ;; DEC: 7, 8 ;; type 0x81 - INC: B ;; DEC: 7 ;; type 0x82 - INC: 4 ;; DEC: 8 movf IRQ_TMP4, W andlw 0x0f JUMPTABLE_2BYTES_UNSECURE rgoto MIOS_ENC_Do_Nothing ; 0 rgoto MIOS_ENC_Do_Dec_ND ; 1 - only if NON_DETENTED rgoto MIOS_ENC_Do_Inc_ND ; 2 - only if NON_DETENTED rgoto MIOS_ENC_Do_Nothing ; 3 rgoto MIOS_ENC_Do_Inc_D13 ; 4 - only if NON_DETENTED, DETENTED1 or DETENTED3 rgoto MIOS_ENC_Do_Nothing ; 5 rgoto MIOS_ENC_Do_Nothing ; 6 rgoto MIOS_ENC_Do_Dec_D12 ; 7 - only if NON_DETENTED, DETENTED1 or DETENTED2 rgoto MIOS_ENC_Do_Dec_D13 ; 8 - only if NON_DETENTED, DETENTED1 or DETENTED3 rgoto MIOS_ENC_Do_Nothing ; 9 rgoto MIOS_ENC_Do_Nothing ; A rgoto MIOS_ENC_Do_Inc_D12 ; B - only if NON_DETENTED, DETENTED1 or DETENTED2 rgoto MIOS_ENC_Do_Nothing ; C rgoto MIOS_ENC_Do_Inc_ND ; D - only if NON_DETENTED rgoto MIOS_ENC_Do_Dec_ND ; E - only if NON_DETENTED rgoto MIOS_ENC_Do_Nothing ; F [/code] Bisher ist sie jedoch nur fuer 4 Encoder Typen ausgelegt. Um Speicher zu sparen (was ja beim PIC leider gang und gaebe ist...) sind diese Typen trickreich zusammengefasst, was eine Anpassung an einen weiteren Typ etwas schwierig machen wird. Doch Du koenntest die Tabelle ja mal versuchen so anzupassen, dass Deine Encoder richtig ausgewertet werden - und ich koennte dann bei Bedarf bei der Speicher-Optimierung helfen. Fuer MIOS_ENC_MODE_DETENTED3 gibt es noch keine Grafik, ich habe das mal irgendwann fuer jemanden auf die Schnelle eingebaut, doch nie sauber dokumentiert... :-/ Zum besseren Verstaendnis des Algorithmus koenntest Du auch mal in die C Variante des Encoder Treibers reinschauen: mios32_enc.c Gruss, Thorsten.