TK.

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.

Hi, this is the typical screen of a non-initialized display. Maybe MIOS isn't uploaded yet? See also the bottom of thi spage: http://www.midibox.org/dokuwiki/doku.php?id=what_is_a_midibox Best Regards, Thorsten.

There must still something wrong, maybe the ground is not connected to the core, or the multimeter is not in the right mode. You could try this out by measuring the current through the power LED, it should be about 10 mA Best Regards, Thorsten.

And this is the MIDIbox SEQ built by dcer10 in a nice shining "acid green" case, it's really good work! :) More pictures are available here: http://www.dcerecords.dnsalias.com/gallery.html

This is the MIDIbox SID of dcer10 - the front panel fits nice to the mouse pad, no? :) http://www.dcerecords.dnsalias.com/gallery.html

So, you are using the optimized C64 PSU circuit? Did you connect the 5V at J2 or J1 (J2 would be the right one here, and note that the 7805 has to be removed in this case!) Current drain of 0 doesn't sound correct. To measure it, you have to remove one supply cable (e.g. the 5V connection), and you have to place the multimeter in between the break. You should measure ca. 7.5 mA w/o the PIC, and ca. 25 mA with the PIC. During code upload, you will measure short peaks of ca. 30 mA Best Regards, Thorsten.

Hallo, der PIC18F452 muss durch einen PIC18F4620 ausgetauscht werden. Bootloader und eine angepasste MIOS Version befinden sich im MIOS Update Package - falls Du den PIC nicht selber programmieren kannst, einfach bescheid geben, hier gibt es Leute, die das kostenlos tun (vielleicht auch in der Schweiz) Danach kannst Du auch schon die V3 aufladen - ein Link auf die Beta Version findest Du in der MBSEQ Sektion (neue builds gibt es fast alle 2..3 tage) Wegen des EUSART Bugs (Hintergrundinformationen und FAQ hier: http://www.midibox.org/dokuwiki/doku.php?id=mios_pic18f4620) benoetigst Du dann auch noch mindestens ein MBHP_IIC_MIDI Modul Die beiden Prozessoren (PIC18F4620 und PIC16F88) kannst Du bspw. bei farnell.ch bestellen Gruss, Thorsten.

Hi Robin, programming a BankStick takes a little bit more time than programming the internat flash. If acknowledges are missing, it could be, that MIOS Studio already sends the next block before the current block has been programmed. Increasing the delay between SysEx messages, e.g. to 750 mS or more, should help Best Regards, Thorsten.

I also think that this is a power problem - we had the same case some time ago. Chris: what are the specs of your Power Supply unit? (Voltage/Ampere) Best Regards, Thorsten.

Very nice! Sooner or later I will build a footcontroller as well, because it can become very handy, when one hand is tweaking on MBSEQ, the other on MBSID knobs :) Time to hunt for a case @ ebay Best Regards, Thorsten.

There is no special application available to test the memory (you mean: the BankStick), because it's normaly not required. If MBSEQ detects it, the connections are ok, if it doesn't detect it, you can be sure that there is a hardware problem. Maybe you missed to solder the connection between J4:SC and Pin #28 of the PIC? Best Regards, Thorsten.

Yes, I tested the sync feature on a friend's drum machine many months ago. I don't remember which one it was (he as many vintage machines), I only know, that it automatically started once the first clock arrived, and it stopped when MBSEQ was stopped, which was cool - it worked very stable (for my own surprise ;-)) Start/Stop/Continue signals are not implemented Best Regards, Thorsten.

The OPL3 itself doesn't include a filter, they have to be added externally, and controlled from an AOUT or AOUT_LC module. Up to 4 filters are possible (since there are 4 Audio Outputs) The WT sequencer of MBFM cannot send MIDI data, a drum demo can be found on my webpage, in the last YouTube video I used them as well. Don't expect too much - they sound cheap (but I think that this is the special attraction ;-)) Best Regards, Thorsten.

Great! I added the link to the Wiki :) Best Regards, Thorsten.

Sorry, maybe I misunderstood the term "Lead package" - I noticed via findchips.com, that the chip is not available in such a high quantity like the other ones, therefore it looks like it is discontinued. But I could also be wrong... Also S&H is very bad for the performance. Especially for MBSID and MBFM, where I want to control multiple external filters without loading the CPU that much. Under these circumstances I would prefer the TLV5630 before the others, since a LSB error doesn't matter so much here. Really difficult decition! Can't understand, why manufacturers don't use such a perfect interface/protocol like the MAX525 Best Regards, Thorsten.

Within the "pbrenner" documentation all supported PICs are explicitely mentioned Best Regards, Thorsten.

Hm, this sounds really bad, it could be that you've already destroyed the chips! (I don't hope so!) Especially the sizzling sound... hm :-/ It wasn't a good idea to connect both modules together before doing the first voltage checks as proposed in the walkthrough (http://www.ucapps.de/midibox_sid_walkthrough.html), now it will be really difficult and time intensive. I haven't so much time this evening to give you support, but maybe somebody else? I can only say: it makes sense to remove the SID module and to check the core stand-alone. Check it visually, try to find out, which tracks have the expected voltage, which not (then you know where a short could be located), check your PCB against the schematic... If you have luck, the SID is not affected and will still work. Read also the other articles in this forum, there are guys who had similar problems and got an intensive amount of tips - such "stories" could help you to understand the effects better (unfortunately nobody ever wrote a summary about this, but it would be worth a wiki page) Best Regards, Thorsten.