TK.

Hallo Lemonhorse, ein 2x16 LCD ist nach wie vor erlaubt, Du musst jedoch in main.asm (bzw. im setup_* File, welches Du verwendest), den Eintrag: #define CS_MENU_DISPLAYED_ITEMS 5 auf 4 setzen Gruss, Thorsten.

Really great frontpanel work! :) Is this ready for the MIDIbox of the Week section? :) To 3): you have to select the encoder type "MIOS_ENC_MODE_DETENTED2" in setup_mbseq_v2.asm In MBSEQ V3 I will make this as the default encoder type, since this is the right one for Voti's and SmashTV's encoders To 2): it makes sense to debug the DINX4 modules, I wrote down some informations about this here: http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

Hi, normaly I avoid the use of special chips for MBHP, because they increase the complexity and the support effort. In addition, everything which can only be purchased from a small number of distributors should be avoided, since this increases the shipping costs and ordering effort. Best example is the MAX525 - many people suggested this chip years ago, finally I put this into the MBHP, but at the end there is only a small number of people who really built the module (due to the high costs), and we still have no "cheap&simple" solution for a CV converter (assumed that the MBHP_AOUT_LC is only for freaks with enough endurance for soldering so many resistors). To the MAX7221: it's a nice chip, but temporary not available at Reichelt, which could mean, that Maxim is going to discontinue it. Unfortunately this happens very often... :-/ Best Regards, Thorsten.

For a filter example, see this posting: http://www.midibox.org/forum/index.php?topic=6542.0 Can your TX81Z do the same? ;-) Yes, the outputs are noisy! Best Regards, Thorsten.

So far I remember, the current bandwith is about 20GB/month, it increases non-linear (we had about 15GB/month last year) However, there is no need to move server, I'm very happy with the current solution, it runs much more stable and really fast compared to the servers we had ca. 3 years ago! Can't thank Twin-X often enough! :) Best Regards, Thorsten.

I thought that the informations in the FAQ are sufficient for deciding, if a MBHP_IIC_MIDI module is required or not. If you want to have an easy answer: yes, under normal circumstances it's required for MBSEQ V3 - and since MBSEQ V3 supports up to 4 IIC_MIDI modules for 4 seperate MIDI outs, this approach also brings some advantages. Best Regards, Thorsten.

Hi, could it be that you've mounted the MAX232, but want to use the "normal" MIDI In/Out ports? Best Regards, Thorsten.

Hi intellijel, yes, MBSEQ V3 doesn't require more buttons/LEDs than MBSEQ V2. But if you design a new frontpanel, please consider the following: - you could add 4 additional buttons and LEDs for switching between the 4 track groups (track 1-4, 5-8, 9-12, 13-16). Without these buttons/LEDs, you have to cycle between the groups with F4. The group number will be display at the LCD (most menu pages) - you could add 3 additional buttons/LEDs for switching between the assignable trigger layers. Without these buttons/LEds, you have to use F3 in order to cycle between the layers, the selected layer will only be displayed within the EDIT screen 64 button/Duo-LED matrix: sorry, there are no schematics yet (lack of time... :-( ) - I will try to draw them next week. It uses 2 x 74HC165 and 4 x 74HC595, no special chips Best Regards, Thorsten.

Thats really worth to be moved to the "MIDIbox of the Week" section! Great Work, Xavier! :) Although I really have to warn other people: a 4x20 LCD is not the optimal solution for a MIDIbox FM Best Regards, Thorsten.

Thanks Volker, Jacob, Ilmenator! This isn't the first time where the MIDIbox platform was used in an school or university project, but it's the first time where such an excellent documentation was written! Not to say that the idea behind this project is innovative when you compare it with today's MIDI controllers. The user interface seems to be very ergonomically designed - if I wouldn't have so many own projects in the queue, I would build one and help on the adaption to various synths, and maybe also on display screen improvements :) I think that the source code, the editor and the documentation is a big step towards a completely community maintained family of new MIDI controllers - you have some software and DIY skills, and don't want to spent the money for the two 2 GLCDs, or you prefer more buttons for several synth functions? Then just create a derivative and publish your changes! :) Best Regards, Thorsten. P.S.: you could omit the MIDI merger by using the MIDI In of the MBHP_IIC_MIDI module. Performance shouldn't be a problem here (a MIDI Controller works event driven), you only need to poll for incoming packages and forward them to the MIDI Out

within the assembly file, you should add an underscore to the labels which should be visible from C, and make them global (search for "global" in the sm_simple.asm file) Then you need a special header file with extern statements, which will be included into the C program in order to import the lables (see sm_simple.h) I cannot recomment any book which describes such methods sufficiently, I just know them since years from different magazines. Best Regards, Thorsten.

So, it is working now? Best Regards, Thorsten.

Under such unstable conditions, always upload code with the "feedback from core" option. Where the bootloader doesn't continue until a successfull response has been received. Without this mechanism, it can happen that invalid code will be executed, which can do a lot of random, but also dangerous stuff (e.g. erasing the flash) Best Regards, Thorsten.

I just realized that this is a brilliant test to get a feeling, if the bootloader is started or not (again: it doesn't mean if the bootloader is flashed or not). Note that you don't need to take a resistor if your multimeter provides an ampere measuring mode (which is mostly the case). So, here some values: without PIC: ca. 7.5 mA with PIC, bootloader running: 25 mA, a short peak of ca. 30 mA after two seconds (MIOS init phase) with PIC, MCLR# reset permanently active (connected with ground): more than 50 mA ! with PIC, but without crystal: 9 mA with "virgin" PIC (not flashed) - the same as without crystal: 9 mA, propably because the oscillator mode is not configured I found it very interesting, that your results are matching with mine. But at the end it doesn't help you so much, because they just confirm that it's very likely the crystal (or the 33 pF caps), or maybe (with a very low propability) a missing bootloader. Has Smash already contacted you? Best Regards, Thorsten.

2007 is the year of MBSID V2... "zero-latency" can never be achieved, I took this term just to highlight, that a sequencer can be easily created on a FPGA with a response time of a small number of clock cycles instead of tenthousands... it depends on the complexity of the logic, and the pipeline stages. Assumed that the FPGA is clocked at maybe 20 MHz (to reduce the number of required pipeline stages), the whole update of 16 tracks would maybe take 50..100 cycles, with the result that all new MIDI events are ready to output just after 1 or 2 uS after the clock has been received. This would be 1000 times faster than the PIC implementation, and latency could be reduced even more by spending more by splitting the engine into 16 units and processing the sequences in parallel (however, this would cause new problems, e.g. arbitration and loopbacks...) Hope that you now don't think that a PIC would be too slow. For comparison: - the latency of a common USB MIDI interface is 4..10 mS you are using such MIDI interfaces when controlling synths e.g. from Cubase, Logic, Live or whatever - the latency of MBSEQ V3 (and V2) on a received MIDI clock event is ca. 200 uS..3 mS - the latency of a FPGA based solution would be constantly the required update time, so let's say: 1 uS Maybe it's better to call it "least-latency, zero-jitter" instead of "zero-latency" Best Regards, Thorsten.

Ok, the only discrepancy I found is, that you haven't mentioned, that pin RC3 should have 5V although it's not mentioned explicitely in the troubleshooting guide. But I guess that all IO pins are in high impedance state, which proves again: the PIC is not running. Do you know how to measure the current drain? I don't have a special schematic for this, but maybe it's already clear to you... it could be measured at J1 (split one wire if required). Which value do you measure with and without the PIC? I don't know the exact value by myself, but if the current drain is much higher than 1 mA, I would say the PIC is running, but no code is started (this still doesn't mean that the bootloader doesn't exist in flash). If it is less than 1 mA, the propability is high that there is an issue with the crystal or the 33 pF caps Best Regards, Thorsten.

Of course, it could, but the propability is very low, because this never happened in the last 4 years. Nethertheless, just 10 minutes before your last posting I asked him via PM to doublecheck this, since somebody else had a similar issue. Hope that this tell you, that we don't ignore such issues (we would even not ignore them if you would avoid to WRITE IN THOSE AGGRESSIVE CAPITAL LETTERS!) However, please measure the voltages of all PIC pins, maybe it allows me to determine a possible error immediately, maybe not... but it's worth the effort (especially because I've not so much time for supporting people in the next week until next monday - somebody else must help) Best Regards, Thorsten.

I really don't know, my only hope is that you find out a detail sooner or later which really helps somebody to determine the reason. Just remind, that some of us guys are sitting 1000tes of miles away and cannot look over your shoulder. Or would you prefer that I say "the PIC is damaged, buy a new one", although the reason is just that there is a small invisible soldering clump between MCLR# and Vss which resets the PIC permanently? (just read this troubleshooting section and you will know what I mean) Which voltages do you measure on the other pins of the PIC (measured against ground). Maybe this gives a hint... Best Regards, Thorsten.

So, the first option seems to be true: the PIC is not running... Best Regards, Thorsten.

And here again a very original idea for a case, which our beloved SID has really deserved :) This MIDIbox SID has been built by reboot:

Take care when handling with FSR pointers - the fix2asm.pl script swaps all FSR1 related registers by FSR0 (which means: also POSTINCx, POSTDECx, ... see tools/fixasm.pl) and vice versa to avoid a conflict with register resources. These addresses are directly defined by SDCC within the generated assembly code (unfortunately!!!) and therefore don't need an underscore. Sometimes, if the compiler doesn't need these pointer access registers, it doesn't define them, therefore you won't see the names. I think the only proper solution how to handle this is not to use inline assembly code here, but to define the functions in a seperate .asm file. Examples are available at mios download page (C based sm_examples, or midi_router project) they don't need additional code, because they expect none or a single parameter in WREG and/or return a single parameter in WREG Maybe I should just drop the SRAM assembler code snippets and do it all from scratch in pure C? My proposal: always try C first, and if the generated code doesn't look performant enough, then you can think about an assembly based version. Best Regards, Thorsten.

What is the resistance to other tracks which are routed close to the Tx signal? Best Regards, Thorsten.

press the "compare PIC with Hex File" button Best Regards, Thorsten.

Hi Ilmenator, so long you've included the pic18f452.h header file into the >> C << code: #include "pic18f452.h" you have access to the SFRs in this simple way: ADCON = 0x07; TRISAbits.TRISA0 = 0; TRISAbits.TRISA1 = 0; TRISAbits.TRISA2 = 0; ... The structures are described in pic18f452.h - note that they are also valid for pic18f4620, no special header file is required here So far I remember, once you include it, the SFRs will also be accessible within inline assembly code, when you add the underscore Best Regards, Thorsten.

Thats great! :) Maybe this hint should be added to the wiki as well Best Regards, Thorsten.