TK.

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.

fine! :) You should consider to use read-modify-write instructions (sbi/cbi on Atmel AVR) to control the pins, otherwise you will have to disable all interrupts which access the same port while reading/changing/writing the port output value. Another advantage: this results into a step wise approach, which is required anyhow to avoid race conditions (like setting the serial output and SCLK at the same moment) And it's faster (a single instruction to set/clear a pin) :) 8 MHz is quite slow, so that no "nops" (delays) are required. By unrolling the loop, you should be able to write a single SID register in ca. 11..12 uS Best Regards, Thorsten.

Thats fine. I assume that one of the following issues leads to instable register writes: setup or hold violations while loading the serial registers. I don't know, if you are using the SPI peripheral, or if you are using a SW based bitbanging method. For testing purposes, just reduce the frequency (bitbanging: insert some NOPs between shifts) - especially ensure, that there is a delay between setting the serial input of 74HC595, and setting SCLK=1 CS# active (=0) while updating the address/data values - ensure, that CS# is 1 there should be a delay between the rising RCLK edge (74HC595 take over address/data values) and the falling CS# edge to ensure, that the data/addresses are stable during CS#=0 Could it be, that mega8535 is clocked at a higher frequency? Then such IO timing issues would be obvious. If this doesn't help, just show your code - it says more than 1000 words ;) Best Regards, Thorsten.

Yes - and it's an intented "effect" to simplify the handling at application side. Simple example: MIOS_DOUT_SRSet(0, MIOS_DIN_SRGet(0)); works without reversing the pin positions. Please give me a phrasing which is good enough, so that nobody who creates an own PCB overlooks the reversed DOUT pin mapping. I will insert it into the schematics. Best Regards, Thorsten.

I accessed the SID totally asynchronously many years w/o such problems. It works, so long it is ensured that address/data is stable before CS# (and WE#) has been activated. The pulse width of the CS# line should be at least 1.2 uS at 1 MHz SID clock rate. There is only one issue which could happen on asynchronous control: the gate could be triggered twice. But you will notice this effect only on very sophisticated drum sounds - I guess, that you are far away from such a step ;) Recently I rewrote the SID access routines in C. For the case it helps: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fsid%2Fsid.c Best Regards, Thorsten.

Are you using only one, or all 3 oscillators with the same pitch? Do you notice effects similar to this example? http://www.ucapps.de/mp3/midibox_sid/mbsidv2_osc_phaseoffset.mp3 Best Regards, Thorsten.

There is a DIN/DOUT table in the wiki - I would propose to improve it Best Regards, Thorsten.

There is no reason why the bootloader should affect the program execution. I'm also not aware about a compatibility issue with MIOS itself. Best Regards, Thorsten.

It already has been answered here: http://www.midibox.org/forum/index.php/topic,12379.msg103109.html#msg103109 For your own comfort: don't start double posts! Best Regards, Thorsten.

Thats normal - while DINs are scanned in backward direction (last bit received last), DOUTs are scanned in forward direction (last bit sent first). Therefore the bit correlation is swapped on DOUTs. If you would follow the programmers section, you would know, that I was close to decide to change the order in MIOS32: http://www.midibox.org/forum/index.php/topic,12141.msg100435.html#msg100435 But finally decided to keep it compatible with PIC based MIOS, as most application would have to reverse the pins anyhow - e.g. to transfer DIN register values to DOUT register values: http://www.midibox.org/forum/index.php/topic,12141.msg101954.html#msg101954 Best Regards, Thorsten.

I'm not able to reproduce this (as I don't have access to your hardware) - I did a quick check on a matrix keyboard, but without seeing the failure symptoms you described. Is anybody beside of jb using the "sm_fast" variant? However, one thing you could try is to insert some waitcycles after the SCLK 0->1 edge search for the SM_BUTTON_HANDLER_SHIFT_Cont label, and change the code below this label the following way: ;; toggle shift clock to 1 bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK nop nop nop [/code] If this doesn't help, I'm out of ideas... Best Regards, Thorsten.

Hi Phil, I'm planning to update the IIC_MIDI firmware soon to provide a "raw IO" mode. So long it isn't available, you could also use the MBHP_IIC_SPEAKJET firmware which already matches with your requirements. Best Regards, Thorsten.

From the Manual Best Regards, Thorsten.

MIOS32 is already ported to C for STM32F10x derivatives, which contain an ARM Cortex-M3 CPU :) http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2F&sc=0 Best Regards, Thorsten.