TK.

It's a nice idea to add the pin numbers directly to the schematic. But could you please do this on the original .ps files? Otherwise your changes will get lost whenever I'm adding updates by myself. Original location: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fschematics%2Fmidibox_seq%2F The .ps files have to be edited with xcircuit - the program is available for windows/mac/linux Best Regards, Thorsten. P.S.: the pin numeration you are using is wrong, the correct one: 1.0 - 1.7 corresponds to first shift register, pin D0..D7 2.0 - 2.7 corresponds to second shift register, D0..D7 etc It seems that you counted Vs/Vd (Ground, +5V) as digital inputs I guess that it would be better to improve the descriptions in the setup_*.asm files? But how?

This isn't a MIDI or application issue, since the upload works stable. Unfortunately my MBFM resists at the bottom of my 19" stack, therefore I'm not able to quickly do some scope measurements on my MBHP_OPL3 module for comparison with your waveforms. All I can say for now: noise below 10 mV can be safely ignored! With a scope you could check the digital interface first. Use the midibox_fm application instead of testtone for such checks, as testtone configures OPL3 registers only once after startup - so no periodic repetition, hard to measure... Send some >>different<< MIDI notes, so that the frequency registers will be changed. Check with your scope: that D0..D7/A0..A1 are toggling depending on note number that WR is toggling mutiple times whenever a note is played that RS is permanently 1 (so far I remember...) - it's the low active reset line No detailed descriptions required from your side for further analysis - it's only interesting if you see the signals toggling... yes? Then you can safely assume that the core is perfectly working. Btw.: did you already search for older postings where OPL3 modules were debugged. I remember a case where somebody soldered the chips with wrong pin orientation - the pinning can be confusing when you compare schematic with PCB layout, as the SMT chips have to be soldered upside down (-> mirrored pinning) Best Regards, Thorsten.

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.