TK.

That'ss indeed an unexpected error mode! I'm glad that you got this fixed :) Best Regards, Thorsten.

No, ribbon cables are not included. Best Regards, Thorsten.

What happens if you pull IC1 of the DINX4 module out of the socket, and connect pin 9 (QH pin) directly to ground (Vs) or +5V (Vd) I would expect 128 "on" events if connected to ground, and 128 "off" events if connected to 5V without retriggers. Can you confirm this? Please use MIDIO128 for testing, as on the MB64 firmware this experiment could cause unintended menu operations (like a snapshot) Best Regards, Thorsten.

Sounds like a cold/loose connection/insulate contact/slack joint or however you call it... ;) Did you already resolder the pins around the affected SID/74HC595s and PIC? Best Regards, Thorsten.

What do you guys think about following inexpensive solution for a giant 16x16 Duo-LED Button matrix? :) I got this inspiration from the Flame Six-in-a-Row project, the creator Per Salzwedel was very helpful and gave me the construction details. Self-adhesive "3M elastic buffers" (rubber feets) are used as button caps. Costs: ca. 0.06 EUR pp. if we organize a bulk order. Buttons are "TASTER 3301", available at Reichelt for 0.11 EUR pp. Single-color LEDs are "SLK 5MM RT", available at Reichelt for 0.07 EUR pp. For Duo-color (red/green) "LED 5 RG-3" could be used (0.15 EUR pp.), but this one has only a diffuse cap. Does anybody know where to get them with transparent cap? In addition - and this is the trick! - some kind of transparent silicon mat (german: "transluzente Silikonplatte") is required (2x240x500 mm for ca. 7 EUR) to give a perfect tactile feel like if the button would be directly under the cap. So, estimated costs (w/o PCBs and Case/Frontpanel) for a 4x16 BLM: ca. 20 EUR, 8x16 BLM: 40 EUR, 16x16 BLM: 80 EUR Best Regards, Thorsten.

http://www.ucapps.de/gallery_midibox64.html http://www.ucapps.de/gallery_midibox64e.html http://www.ucapps.de/gallery_midibox_lc.html http://midibox.org/forums/index.php?/forum/20-midibox-of-the-week/

Hi, do you mean digital gate outputs, e.g. to trigger percusive sounds? 8 gates are available at J5, and up to 64 gates can be added by using two DOUTX4 modules. The upcoming BLM_SCALAR (hardware) will give you a nice user interface :) Here a snapshot of the SW based emulation: Best Regards, Thorsten.

Hm... nobody reported such an issue before. Wrong MIDI values normally indicate a baudrate mismatch, e.g. because the wrong crystal is used (GM5 requires 16 MHz). But this would also lead to wrongly received MIDI events, and the correct events would be received on a direct MIDI OUT->IN loopback. So, the only explanation I have (yet) is, that you are using the wrong resistor value for R38 and/or R50. Both should be 220 Ohm. A higher value would lead to unstable transfers. In your examples more 1s are received than 0s, which confirms my hypothesis (1 is the idle state) If this isn't the reason, please try following experiment: put at jumper at J6:I1 and J6:O1 to short the In/Out connection (don't worry, this won't lead to damages) - is the loopback working now? Best Regards, Thorsten.

Hi, see the mios32_config.h file of this tutorial application: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F012_ain_muxed%2Fmios32_config.h The three AIN multiplexer selection lines can be mapped to any free IO pin. In this example I used some J5C pins, but you could also use J19 pins if they are free - this would allow you to use J5C for 32 additional pots/faders. Best Regards, Thorsten.

The reason why you took two cores was, that only 64 multiplexed AIN inputs are supported by MIOS8. This limitation doesn't exist for MIOS32 anymore. Three AIN modules can be connected to J5A/B/C, and the three AIN multiplexer select lines have to be mapped to free IO pins (e.g. J19) Best Regards, Thorsten.

Here a closer lookup - due to the imperfections (see LEDs) this one isn't qualified for the MIDIbox of the Week section ;) The engravings are painted with "Revell Email Color" (this is neither an acryl color, nor a new web 2.0 invention - email means translated "enamel"), available for 2 EUR in toy/modelbuilding departments of bigger supermarkets (at least in germany). During the session yesterday I noticed three bugs in the Multi Engine which I would like to fix before the next release. Best Regards, Thorsten.

Successfully built my sammichSID - thanks Wilba! This video is for you! :) Best Regards, Thorsten.

I'm unable to reproduce this. Could you please give me step-by-step instructions? Please try it with the default lead patch first (press SHIFT+GP2 (E.) multiple times until "Ld" appears) If the issue cannot be reproduced with this patch, please send me your patch for further analysis. Best Regards, Thorsten.

I never got a LPT based wiggler working on my PC, I tried it with the internal LPT port, and with an extension card. The UART based bootloader worked w/o issues through a USB COM interface. Best Regards, Thorsten.

Hallo, ja, in einem BankStick kannst Du 32 separate Baenke speichern. Allerdings werden nur 8 Motorfader supported - mehr ist mit dem PIC nicht moeglich. Gruss, Thorsten.

Hi, the AOUT module option integrated into MB64 was made at a time where neither the MBCV firmware, nor the MBHP_AOUT_NG module was available. Today I should probably remove this option to avoid unnecessary confusion (and/or the hope that gates could be provided as well, etc.) I think that the better option for your usecase is a modified MBCV firmware with support for up to 64 pots, up to 128 buttons, and up to 128 LEDs (resp. 120 LEDs, as 8 DOUT pins will be required for the gates if J5 is allocated by AIN modules) This will work under the assumption, that Numerology allows you to configure the MIDI events assigned to these control elements at the software side (at least via MIDI learn). This option will give you the advantage, that only a single core module will be required (-> easy MIDI setup), and that you will get all features of the MBCV firmware (like different output curves, polyphony, storable setups) which are probably not provided by Numerology itself. I can give you the appr. code snippets, and/or could even release precompiled .hex file - but I would need more informations about the MIDI setup capabilities of Numerology. E.g., are buttons/LEDs supported? How many? Does Numerology allow to to send/receive MIDI events to the control surface over different MIDI channels to avoid conflicts with the channels used for CV/Gate? Best Regards, Thorsten.

Hallo, sehr wahrscheinlich ist eins der beiden Kabel zum DIN Modul nicht richtig angeschlossen, oder das DIN Modul selbst hat einen Wackelkontakt. Tritt das Problem denn nur bei einem Encoder, oder bei allen und/oder auch den Tastern auf? In diesem Fall muesstest Du die Verbindungen zwischen Core und DIN Modul ueberpruefen, siehe auch http://www.midibox.org/dokuwiki/doku.php?id=din_module Falls nur ein einziger Encoder betroffen ist, reicht es, die Spannung an den beiden DIN Eingaengen nachzumessen. Beide sollten zwischen 0V und 5V wechseln wenn Du den Encoder drehst. Falls an einem Eingang die Spannung permanent auf 5V steht, weisst Du, welches Kabel nicht angeschlossen ist. Gruss, Thorsten.

_BLM_PrepareCol ; (for C) BLM_PrepareCol ;; increment column SET_BSR blm_selected_column incf blm_selected_column, F, BANKED bcf blm_selected_column, 3, BANKED ; wrap at 8 ;; select next DOUT/DIN column movf blm_selected_column, W, BANKED call MIOS_HLP_GetBitANDMask ; (inverted 1 of 8 code) ;; finally apply inversion mask (required when sink drivers are connected to cathode lines) xorlw BLM_CATHODES_INV_MASK movwf MIOS_PARAMETER1 ;; output on CATHODES* registers #if BLM_DOUT_CATHODES1 movlw BLM_DOUT_CATHODES1 - 1 call MIOS_DOUT_SRSet #endif #if BLM_DOUT_CATHODES2 movlw BLM_DOUT_CATHODES2 - 1 call MIOS_DOUT_SRSet #endif ;; store row*2 offset in IRQ_TMP1 to simplify the addressing of blm_row_green and blm_row_red array SET_BSR blm_selected_column movf blm_selected_column, W, BANKED rlf WREG, W andlw 0x0e movwf IRQ_TMP1 [/code] You also have to adjust the array sizes: [code] #if _BLM_NO_DEBOUNCING == 0 _blm_button_debounce_delay res 1 blm_button_debounce_ctr res 128 #endif blm_selected_column res 1 blm_button_column_ctr res 1 blm_button_row_values res 16 blm_button_row_changed res 16 _blm_row_green res 16 _blm_row_red res 16 If assembler looks like voodoo for you, just have a look into the appr. MIOS32 implementations: BLM: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fblm%2F and a more generic BLM driver provided by This (it also supports your 16x8 configuration): http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fblm_x%2F The upcoming BLM_SCALAR firmware (for PIC and STM32) will provide 16x8 and 16x16 duo LEDs. So, if you don't manage to adapt the current BLM driver, just wait for the updates. Best Regards, Thorsten.

Hi, welcome to the forum! :) These topics are (partly) discussed in following threads: 1) 2) Addendum to 2) so long all LED rings should be dimmned from the same PWM signal, it will work. This is a simple programming example (for MIOS32) which demonstrates how to generate the PWM from a single timer IRQ: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F007_mios32_timer%2F there is another (somewhere...) which demonstrates how to generate independent PWM waveforms by using modulo operations (not recommented for PIC) Best Regards, Thorsten.

Why did you receive an upload request (F0 00 00 7E 40 00 01 F7) at the beginning, and additional upload requests (F0 00 00 7E 40 00 01 F7) at the end? Could it be, that you haven't installed MIOS yet? These are the expected messages sent by the core: 00000000011055 ms | SysEx: F0 00 00 7E 40 00 0F 1C F7 00000000011159 ms | SysEx: F0 00 00 7E 40 00 0F 60 F7 00000000011264 ms | SysEx: F0 00 00 7E 40 00 0F 40 F7 00000000011444 ms | SysEx: F0 00 00 7E 40 00 0F 24 F7 00000000011630 ms | SysEx: F0 00 00 7E 40 00 0F 19 F7 00000000013934 ms | SysEx: F0 00 00 7E 40 00 01 F7 00000000015831 ms | SysEx: F0 00 00 7E 40 02 01 F7 [/code] Best Regards, Thorsten.

Indeed this is strange. It seems that you are doing everything correctly. The only explanation I have is, that you are not using the original .hex files which I released under http://www.ucapps.de/mios_download.html but something else. Did you build the files yourself, or did you rename the files? Please download the change_id package again to be 100% sure that you are using "known working" binaries. And I also recomment to pull the other PICs out of the sockets so that you are 100% sure that only the first core receives/sends SysEx messages. Has anybody else successfully used the change_id application in the last weeks? Best Regards, Thorsten.

Thanks Simca, this is really a sufficient demonstration that you own the knobs! ;) Yes, we should move this thread to the bulk order section - done. Best Regards, Thorsten.

Could it be that you forgot to route the MIDI Out correctly, so that you always get the response of the first core? Best Regards, Thorsten.

If you've luck, it will work with the DEFAULT_SRM_* feature, which is described in the setup_*.asm file You have to assign a free DIN and DOUT register, buttons will be available with SR=16+1..16+8 in CS_MENU_DIN_TABLE thereafter. If this doesn't work, you will have to do some experiments with the sm_example1 application which is available at the MIOS download page (programming knowledge required). Once you found out, how to scan the buttons correctly, we could try to integrate the required changes into the MBSID firmware. Best Regards, Thorsten.

This isn't the first time you are asking these questions, and I already gave you the answers (no, it this isn't supported by the driver) Best Regards, Thorsten.