TK.

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.

of course, the IIC connection won't work if this resistor is not available normaly, the selections should be done automatically, because they are stored in the .hex file If your programming tool doesn't handle it correctly, here the values: Oscillator: HS (!!!) I don't know what CCMPX means, but the values seem to be correct. Ignore the write protection WRT Best Regards, Thorsten.

I would propose to disconnect all modules to reduce the number of possible errors, use only the core module for the first upload test, even the LCD should not be connected (yes, the black bar is normal so long MIOS hasn't been uploaded) Pin 25=0.5V: sounds like the PIC is not running, or that there is a short between the Tx track and another track Best Regards, Thorsten.

I remember that I read about a similar issue short time ago somewhere else in the forum? Best Regards, Thorsten.

There is a lcd_interconnection test available at the MIOS download page which helps you to find out, if the cables between core and LCD are wired correctly. It doesn't ensure if the pinning is correct (thats not possible), but it might give you a hint Best Regards, Thorsten.

Not before you've done "TEST PC2" of the troubleshooting guide Best Regards, Thorsten.

A primitive octave quantisation is possible by forwarding the note or a whole chord (up to 4 keys or auto-chord - 16 predefined key combinations) to a track in arpeggiator mode, because the arpeggiator allows you to select the key number and the octave seperately. And since it is possible to split the transpose function from the arpeggiator function (transpose: left keyboard half or one "loopback" track, arpeggiator chord: right keyboard half or another "loopback" track), there are also some complex stuff possible here :) But I know, this again is not exactly for what you are searching for. I would say: I will try to combine one or two parameters in single bytes to free some space within the track memory, and after the first or second release of MBSEQ V3, I can decide for which purpose these reserved bytes are finally used. If there is no better idea, a max and min limit with wrapping function will be included (for myself it's a minor feature) For efficient handling a 16bit or 32bit controller would be required, so it can really only be considered in a future version (MBSEQ V4?). I don't want to say, that the PIC is not able to handle 14bit MIDI values, I only want to point out, that in the MBSEQ V3 application the data and task handling is already so complex, that such features will only reduce the overall performance, and this is what I definitely want to prevent. The communication between two cores will cost more performance than handling everything in a single core. One of my secret options, about which I already thought about, but for which I propably won't find the time (considered that I will start with MBSID V2 sooner or later) is the re-implementation of the sequencer engine in VHDL, so that it can run on a FPGA. This would result into the first true-zero-latency sequencer of the world ;-) It could still use the MBSEQ V3 control surface, but only as a "entry terminal" to the engine, coupled via a fast interface. But such a project would also increase the skill barrier for electronic newbies My experiences with the new PIC18Fxxxx derivatives are so bad, that the next platform won't be based on Microchip products anymore. Maybe in 2008 I will look for an alternative 16- or 32 bit controller which fits the needs for a DIY project (which especially means: low-cost toolchain, high reliability, good worldwide availability, low support effort from my side) It should be a microcontroller family for the next 10 years... No, the first note would be stopped immediately before (no glide) or after (glide flag set) the second note. This is required to fasten the note array handling. Since 16 tracks can play up to 4 notes, the note array has 64 entries. On each 96ppqn clock, the sequencer has to process all entries - it has to decrease the delay counter and it has to send a Note Off event once the counter reached zero. This simple handling speeds up the code at many places (e.g. it makes it easy to switch from one to another pattern without searching for "open notes" which relate to the old pattern), that I want to stick on this solution. I believe this, but negative delays are not so easy to handle by the engine. E.g., I don't know how to ensure that the track is still on-sync when you are quickly switching between different patterns with different groove settings without waiting until the track has reached the end. After I saw this desaster, by decition was: before spending some weekends in implementing and debugging new compensation and synchronisation routines, it's better to keep it simple at this place and to focus other features. Best Regards, Thorsten.

Hi Hazes, yes, it's perfect! Best Regards, Thorsten.