TK.

midio128_v2_1d is now available Best Regards, Thorsten.

Great! A nice example, that bypass caps can help when you have no other explanation for such strange effects :) Best Regards, Thorsten.

I've fixed the typo. Yes, a tutorial in the wiki is always welcome! :) I would add a link from the MBHP_AIN to this tutorial thereafter Best Regards, Thorsten.

New features: - MIDI In->Out router for port IIC1/IIC2/IIC3/IIC4/AOUT/Int. Configuration has to be done in the MIDI configuration menu - Some more optional (!) buttons and LEDs - support for sequencer control via NRPN events I've also finished the schematic for the (optional!) Button/Duo-LED matrix: http://www.ucapps.de/mbhp/button_duoled_matrix.pdf

The missing or wrong PIC ID change is definitely the problem. -> PIC ID 00000000100000 According to the documentation: http://www.midibox.org/dokuwiki/doku.php?id=encoder_specifications, the ground has to be connected to pin C, not to the middle pin - so, thats the problem. When you upload the change_id application, the current ID will be displayed on screen. You can use it to ensure, that the ID has changed to 0000000000100000 Best Regards, Thorsten.

Great sounds! :) I've the impression, that the bass drum is a little bit out of sync to the bassline? Best Regards, Thorsten.

Good to know, that I'm not the only one who make such errors ;-) I don't really know, why MPASM still gets use of the END directive. It was useful in the early years (70s) to ensure data integrity (e.g. that the complete source code has been read from a tape), but today it doesn't make much sense anymore, and only causes trouble :-( Best Regards, Thorsten.

Hi Per, I made the change some time ago, but haven't released it yet. I will add the new version to my website this evening Best Regards, Thorsten.

Hi Ilmenator, are you sure, that TRISE isn't change back to another value somewhere else, e.g. within your SRAM driver? Because for me it sounds like the output driver of the pin is enabled (TRISE flag set to 0) You could use MIOS Studio to read out the SFR value, just open the debug window and start a read transaction from address 0xf96 Best Regards, Thorsten.

It could be that your core is running with the wrong baudrate - did you burn the bootloader into the PIC by yourself? Maybe the PIC ID header is not correct, it should be all-zero (0000000000000000) Best Regards, Thorsten.

Hi SD, it could be a power integrity issue, which happens, when too many modules (especially the ones which consume a lot of power like a DOUT fully stuffed with LEDs) are supplied from the core module. Bypass caps are a must here, did you add them to all modules? I would especially add a 100 uF cap between Vs/Vd of each DOUT module. I don't want to say that this is the problem, but there is a certain probability... Best Regards, Thorsten.

I think that under these circumstances, it makes sense to send the board to an expert for further analysis. Did you buy the core module from Mike or SmashTV? SmashTV would propably check the board by himself, in case you bought it from Mike, just send it to me Best Regards, Thorsten.

Hi, I think (but I might be wrong), that DEFAULT_ENCODER_GROUP_WIDTH has to be set to 4, and the not used shift registers to an invalid value (e.g. 0 or > 16) Best Regards, Thorsten.

It won't help you, xcircuit cannot transfer the netlist to eagle. Just edit the .brd file directly, thats they way how I've created the layout Best Regards, Thorsten.

It's implemented: press and hold the SID1..4 button and press the menu button in addition Best Regards, Thorsten.

Nice frontpanel design! :) It's now part of the MIDIbox gallery

Note that the planned internal MIDI router will only provide a very simple forwardning, it's not intended to replace the MIDI router project, since this would affect the overall sequencer performance too much. So, you will be able to define a MIDI In forwarding option for all outputs (Internal 4 IIC, Loopback, AOUT) individually, but thats all. It won't be possible to forward SysEx messages! It's very typical that MIDI software cannot synchronize exactly to external MIDI clocks, the same happens on my PC. The only computer which can do this very stable is my good old Atari ST ;-) Therefore, for synchronized MIDI recording, it's better to run the sequencer as MIDI slave, and to use the Mac/PC as clock master. You don't need to solder extra buttons, it's only an option if somebody creates a new frontpanel, but for guys like me, who are using the "normal" frontpanel, a ergonomical selection of the tracks is possible as well. First option: use F4 to cycle through the 4 track groups. Second option: press and hold the mute button: now you can select the track directly with the 16 GP buttons The AOUT options are completely implemented, they should work It is possible, but it could show some failures (wrong MIDI events) when something is received on the MIDI In at the same time (see FAQ) So, in general it can only be used in a reliable way, when there is nothing connected to the MIDI In As mentioned above: of course, you can select everything from the available buttons, just keep in mind, that I haven't changed my own frontpanel! Just set the DEFAULT_ENABLE_J5_GATES switch to 1, so that the 8 gates are available at the J5 port. The AOUT routing is explained at the buttom of the CHANGELOG.txt file. When you are using AOUT channel #1-#9, the CV Outs will send the note values, and the appr. gates will be triggered. The default port is the one you've configured in the PIC ID header. You can use the change_id application in order to select another port, e.g. upload iic_midi_10.hex to select the first IIC port Does the sequencer show you a "available" or "not available" message behind the port? Did you select individual device IDs for all IIC modules? now, it's just an information, that a new BankStick has been located The interconnections are straightforward, here it could help to compare the schematics, maybe you have swapped a pin? what happens, when you swap two encoder entries in the setup_mbseq_v3.asm file, e.g. the one of VPot #1 with the datawheel entry. Can VPot #1 control the datawheel function properly without jumps? From the video it looks like two encoder pins are swapped (there are 3 possible combinations...) it's related to the PIC ID header configuration -> use change_id in order to change the default port Best Regards, Thorsten.

I added this to the TODO list Best Regards, Thorsten.

yes! :) Each track will get its own Loopback channel, the NRPN address will be set accordingly, so that the value can be controlled with a normal CC For external parameter control, NRPN over a single MIDI channel will be the only option. Best Regards, Thorsten.

How about MIDIbox UC (Universal Control) Best Regards, Thorsten.

Thats still too much, it should be 25 mA w/ PIC Best Regards, Thorsten.,

Build #60 now supports the AOUT and AOUT_LC module, 8 Gate triggers at J5 and 48 additional drum triggers (which optionally send 1mS pulses) on the DOUTs The channel mapping is described in CHANGELOG.txt

I never heard before, that the EEPROMs will be killed in such a way (especially not, that this happens with Mike's board - most of my own boards are from him). The only answer I have is, that you either forgot to ground the CS pins of the EEPROM (pin 1-3), so that the written data is corrupt, or that you plugged the EEPROM the wrong way into the J4 jumper - note that V3 boards have a slightly different layout, see SmashTV's page for the differences please read this wiki page which gives you a basic understanding about the IIC modules in relation to the PIC18F4620: http://www.midibox.org/dokuwiki/doku.php?id=mios_pic18f4620 For MBSEQ, we are using the MIDI Outs only, the MIDI INs of the MBHP_IIC_MIDI modules are not used (and don't need to be stuffed) The MIDI In of the Core module is used as the only MIDI input No. In general you can still use the LTC module if you just want to duplicate MIDI OUTs, if you want to have a MIDI Thru, or if you want to have some flickering LEDs. Just have a look to the MBHP_IIC_MIDI module layout, it provides a MIDI Link port as well. You are allowed to connect for example the LTC::J1:MO pin to the MBHP_IIC_MIDI::J4:MO pin in order to duplicate this MIDI Out, it would have the same effect like in your current setup. But the usage of a second MBHP_IIC_MIDI module has the advantage, that you will get a seperate MIDI Output which works independent from the first. In other words this means: you will get 32 MIDI channels With 4 MBHP_IIC_MIDI module you will get 64 MIDI channels. It's clearly stated in the other post with repeating examples to be very exact, what is unclear? I will release a new build of MBSEQ V3 which will include the new AOUT handling, I've described the mapping of the AOUT channels and Gate triggers in the CHANGELOG.txt file Like to read this! You will be surprised about the new features of MBSEQ V3 - I for myself would not be happy with a V2 anymore ;) Best Regards, Thorsten.

Sounds like two PIC pins are connected together, one outputs 0V, the other 5V Potential candidates are: [tt] Name | Class | Core Port | Dir | additional informations ------+-------+-----------+-----+--------------------------------------------- RC0 | B | J6/J7:RC | O | used to address the AIN multiplexers or the | | | | MF module. In both cases driven by an | | | | interrupt service routine. | | | | RC1 | B | J6/J7:SC | O | used to address the AIN multiplexers or the | | | | MF module. In both cases driven by an | | | | interrupt service routine. | | | | RC2 | C | J6:SI | O | used to address the AIN multiplexers, driven | | | | by an interrupt service routine. | | | | This pin is stuffed with an external 10k | | | | pull-up which could be useful for an | | | | application which uses this pin as input | | | | RC3 | D | J7:SO | O | used as serial output to the MF module, driven | | | | by an interrupt service routine. | | | | RD0 | E | J8:SO | O | serial output to the DOUT chain, driven by an | | | | interrupt service routine if MIOS_SRIO active | | | | RD2 | F | J8/J9:RC | O | serial latch output, used by an interrupt | | | | service routine if MIOS_SRIO active | | | | RD3 | F | J8/J9:SC | O | serial clock output, used by an interrupt | | | | service routine if MIOS_SRIO active | | | | RC4 | G | J10:RC | O | free for applications without restrictions | | | | if second CLCD not used | | | | RC5 | G | J10:SO | O | free for applications without restrictions | | | | RD4 | E | J10:SO | O | touch sensor strobe signal, used by an | | | | interrupt service routine if MIOS_SRIO | | | | active and TS_Sensitivity > 0 | | | | RD5 | H | J10:MD | O | address signal to LCD, clock output to | | J15:RS | | BankStick | | | | RD6 | H | J10:MD | O | RW signal to LCD | | J15:RW | | | | | | RD7 | I | J15:E | O | enable signal to LCD (exclusive!) | | | | RB0 | J | J15:D0 | IO | LCD data line #0 RB1 | J | J15:D1 | IO | LCD data line #1 RB2 | J | J15:D2 | IO | LCD data line #2 RB3 | J | J15:D3 | IO | LCD data line #3 RB4 | J | J15:D4 | IO | LCD data line #4 RB5 | J | J15:D5 | IO | LCD data line #5 RB6 | J | J15:D6 | IO | LCD data line #6 RB7 | J | J15:D7 | IO | LCD data line #7 [/tt] The same could happen, if one of these pins is connected to ground or 5V Best Regards, Thorsten.

On some LCDs this can happen very quickly, others are more stable. I remember that I plugged J15 the wrong way on a noname device (from Conrad) some time ago - it destroyed the LCD immediately. Just one week ago the same happened again with another LCD, I already was swearing because of my silliness, but what a luck: the LCD still works! Best Regards, Thorsten.