TK.

You will find postings about the details and progress in the programmer's lounge, just one board above this one. STM32 is not a PIC, it's an ARM Cortex-M based 32bit microcontroller - much more horsepower, much more memory, much easier to program, perfect choice for programming beginners due to less limitations for almost the same price. Only disadvantage: it's a SMT device, therefore hard to solder. Maybe pre-assembled boards could be provided later, but currently you've to solder the chip by yourself. Best Regards, Thorsten.

Hi Nsunier, it would be a nice addition to the platform :) The permanent clock requirement is tough for an application, which is doing a bit more than just outputing graphic icons. It wouldn't be a problem so long a dedicated SPI port would be available for these displays, but this would lead to too many restrictions for the 8bit platform. Therefore I propose to evaluate following approach: connect CLK input to J10:PWM (PIC pin RC2), and configure this pin to output 1 MHz (the MBSID application contains a configuration example) Use any other free pin as data line. It has to be 1 so long no data is transfered. In order to send data, disable interrupts, synchronize to the rising clock egde by polling RC2 input register (wait for the rising edge), set the data line, wait for the next rising edge, etc... until all bits are sent. Thereafter switch back the data line to 1 and enable interrupts again. At 1 MHz, the CPU can execute up to 10 instructions (note that a branch/goto will cost 2 cycles!) - this should be sufficient, considered that the driver is written in assembly. Future compatibility with MBHP_CORE_STM32: I've proven, that this clock synchronisation method also works with STM32F103, see sid.c driver. At 72 MHz, there are enough cycles free so that assembly language isn't really required. Even 4 MHz should be achievable. Alternatively, we could use one of two available SPI ports of the MBHP_CORE_STM32 module (J9 or J16) for full background control w/o bitbanging. This would restrict some usecases (e.g. DOUT SRIO or I2S normaly connected to J9, SD Card normaly connected to J16), but would unload the CPU almost completely, so that LCD transfers can be handled from a background task w/o disabling interrupts. As most application won't require a SD Card, J16 is really predestinated for such jobs. I hope that this information wasn't too confusing... Best Regards, Thorsten.

I like your music as well - great! Note that the "Cosaquitos en Globo" album is available at iTunes! :) Best Regards, Thorsten.

Thank you! I guess, that sooner or later I will like this layout as well! ;) There is one detail I don't like that much: my name under the midibox label. It's not because of the "perfume touch" (which Wilba mentioned), but because since some years MIDIbox turns into a project, where many people are adding their contributions. Accordingly, MIDIbox shouldn't be directly associated with my name, but with the community. E.g., my name under the logo would leave the impression, that only I'm allowed to call an application "MIDIbox xxx" - but in distance to this, I would like to see, that everybody who respects the community would use this name for his developments. Best Regards, Thorsten.

Thank you! Best birthday mail I got today: From: orders@goldphoenixpcb.biz Subject: Job shipped THKL01 11.10 mbhp_core_stm32_v1.zip [/code] :) Best Regards, Thorsten.

Jurbo: thank you! :) Puddingbrumsel: I could add a MIDI clock output, but there is a high danger that it will jitter, as the events have to be sent from a low priority task, while the internal synth is running on a high priority task (which isn't allowed to send MIDI...) So, under such circumstances, would it really be useful, or wouldn't it be better to use an external master for synching all your MIDI devices from the same source? Best Regards, Thorsten.

Ok, so the MIDI channel has been changed correctly. You should see the new channel at the main page? Best Regards, Thorsten.

Twin-X: don't worry, a delay will be available (therefore I've already prepared a "Fx" page, see GP button layout of the virtual MBSEQ V4) Moroe: duplicating the MIDI Outs will be sufficient for this usecase. Each additional MIDI Out will require 2 inverters of a 74HC00 (used as a buffer), accordingly 2 74HC00 are required to duplicate the 4 outputs of the MBHP_IIC_MIDI modules. As stated above: it isn't so difficult to provide access to more MBHP_IIC_MIDI modules (in fact it's already prepared for 8, and it could be extended to up to 128) - but IMHO it isn't worth the money, as there are cheaper solutions w/o real loss of functionality. Best Regards, Thorsten.

I just have tested it - works fine. Your MBSID should respond with: F0 00 00 7E 4B 00 0F 01 F7 after the SysEx string has been sent Best Regards, Thorsten.

MBSID V1 or V2? Best Regards, Thorsten.

It should be possible to write a driver for DOG GLCDs, but I don't own such a display, accordingly I cannot support it Best Regards, Thorsten.

Ok, I fried many (4?) LCDs this way in the last (20?) years - there is no way to fix it; it has to be replaced. Best Regards, Thorsten.

Very strange! Check the LCD connections and core module solderings, something seems to be wrong here. Especially the missing pixel line shows, that this isn't a software or configuration issue, as the HD44780 protocol doesn't allow to access the pixels directly (only characters can be sent). It cannot be excluded, that you damaged the LCD due to a wrong connection - did you change anything during build-up? Best Regards, Thorsten.

MBSEQ V3 supports up to 5 MIDI Out ports, which results into 80 (!) MIDI channels This is much more than supported by any commercial HW sequencer (they normaly provide only one or two MIDI Out ports) So, what prevents you from chaining your synths via MIDI Thru, or duplicating a MIDI Out port with the MBHP_LTC module and sending MIDI events over a different channel? I don't want to say that it is impossible to provide more MIDI Out ports by adding more MBHP_IIC_MIDI modules, but from my point it's only wasted money (not to say: such features can only be requested by dilettants ;)) Best Regards, Thorsten.

Nein - eine Uebersetzung lohnt sich momentan auch nicht, da es in ein paar Wochen dramatische Aenderungen geben wird ;) Gruss, Thorsten.

Yes, seems to be a connection issue. "READY." indicates, that you haven't uploaded an application yet, MIOS itself only writes READY a single time, thereafter no LCD transfer will take place anymore. But you reported, that you notice still changes (more black bars) - therefore a typical connection issue Best Regards, Thorsten.

Yes, as StrydOne already mentioned: chords are selected with a 4bit value, accordingly only 16 chords can be predefined. As a workaround, you could use chord mode #1 which allows you to take customized chords from a second track. Up to 32 chords can be stored this way, you can use the step record function for manual entry, or edit the notes directly with the encoders. Unfortunately this methods limits the number of notes to 3 (corresponds with the number of parameter layers). In MBSQ V4, there will be a 4th parameter layer to overcome this (and other) limitations. Best Regards, Thorsten.

I added this to the MBSEQ V3 Wishlist Best Regards, Thorsten.

Unfortunately button functions are not mappable in this application, but it should be easy to program a C based application which is fully customized to your requirements. We had many postings about this topic in the past, and probably some people already developed such applications? Best Regards, Thorsten.

Hi, the LCD font size is already reduced to the minimum, for 55 characters 220 pixels are required. But you could easily combine two 128x64 LCDs (data/control lines have to be connected in parallel, only chip select lines have to be separated) All button and LED functions are free assignable, and there are two layers which allow you to make two button functions selectable, see lc_io_tables.inc Best Regards, Thorsten.

This is so deja vu... Apparantely you forgot to solder D1 of the core module, which acts as a protection diode against illegal opcodes received from the MIDI interface. Take care that the diodes between J15:D2/3 are stuffed on all cores as well, otherwise the opcodes could be forwarded to the slaves via CAN bus, and they will be sent back on the next power-on cycle so that the master will be infected again after a fresh MIOS and MBSID installation. Best Regards, Thorsten. P.S.: FAQMARKER

Tascam US-122 steht auf der schwarzen Liste: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist Probiere es mal mit dem aktuellen Treiber: http://www.tascam.com/products/us-122l;9,15,69,19.html Gruss, Thorsten.

All PICs... ...have been programmed with Bootloader V1.2b, MIOS V1.9f and MIDIbox CV V1.2b (setup_j5_enabled.hex)... ...and are on the way to Sonicwarrior... ... have fun! :) Best Regards, Thorsten.

MIOS_Bankstick_WritePage is a blocking function, you can be sure that the programming process has finished when the function is exit. See also this programming example. You have to ensure, that no IRQ routine accesses the BankStick while it is accessed from the "main" program, of course... regardless if the content is read or written. "Verify" just reads and compares the written content. I used it in the early days to doublecheck if BankStick writes are reliable. They are - therefore I mostly disable it in my own application meanwhile. Best Regards, Thorsten.

There are 4 possible ways to handle the shifting (SR bit orientation, SR chain orientation), ca. 8 years ago I selected one which matches best with my own MIDIbox HW, meanwhile 1000s of MIDIboxes exist which are using correct DOUT wiring. Now you request a software flag for more flexibility as a workaround for incorrect wiring at your side. The software flag would affect the performance of all existing MIDIboxes. And it would lead to a higher memory consumption of MIOS, so that other features would have to be removed (as MIOS already allocates most of the "system" area in flash). Instead, I would propose one of following solutions: fix your DOUT wiring and help to improve documentation modify the bit order in mios_srio.inc and build your private MIOS version, so that no HW change is required add the flexibility inside your application - it's the most simple solution for both - programmers and users - and it doesn't waste memory at MIOS side (which is very very limited - I can't repeat this often enough. Fortunately it has been relaxed dramatically with the MIOS32 approach (-> modular kernel) - but please don't mix the new possibilities with the old PIC MIOS approach (-> static kernel)!) Best Regards, Thorsten. P.S.: the disadvantage of your idea: DOUT SR assignments have to be adapted whenever the number of SRs in the chain is changed via MIOS_SRIO_NumberSet() - this doesn't really make sense.