TK.

the baudrate mismatch was a wrong assumption from my side - since you've received an upload request, the baudrate is correct, otherwise you would receive some more or less random MIDI events (e.g. Pitch Bend events) So, I think it's related to the circuit around the optocoupler. Maybe a resistor is wrong, so that the edges are not "sharp" enough. This can cause a frame error. So, check the resistor values, check also the tracks around the optocoupler for soldering errors, etc... check the MIDI cables (hope you are using a reliable one), and do the loopback test with your soundcard and through the optocoupler. In other words: go through the MIDI troubleshooting guide http://www.ucapps.de/howto_debug_midi.html, and write down, which tests are passing, which are failing Best Regards, Thorsten.

Hi Ilmenator, it seems that the register definition in pic18f452.h is not correct: extern __sfr __at 0xf96 TRISE; typedef union { struct { unsigned :1; unsigned TRISE0:1; unsigned TRISE1:1; unsigned TRISE2:1; unsigned :1; unsigned IBOV:1; unsigned OBF:1; unsigned IBF:1; }; } __TRISEbits_t; [/code] I would expect: [code] extern __sfr __at 0xf96 TRISE; typedef union { struct { unsigned TRISE0:1; unsigned TRISE1:1; unsigned TRISE2:1; unsigned :1; unsigned PSPMODE:1; unsigned IBOV:1; unsigned OBF:1; unsigned IBF:1; }; } __TRISEbits_t; Could you please check, if it works with this change? This header file is not part of MIOS, but has been copied from an SDCC include directory. Maybe there is a newer version in the meantime. Best Regards, Thorsten.

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.