TK.

Alright - hope that this doesn't happen again when I release v3.4f this weekend ;) (it will contain the latest improvement requests) Best Regards, Thorsten.

Wasn't this issue fixed in v3.4e? I tested it myself, and futureman probably as well? If there is still an issue with this function, I need to know more details how to reproduce it. Best Regards, Thorsten.

Oh, what a great design, Allesandro! :) Sounds like the MIDI merger has been activated, and your software forwards incoming MIDI events to the output as well. This will result into a feedback loop which can quickly result into a MIDI buffer overrun either at the MIDIbox, and/or at your computer side. So - just disable the Merger (MB64E: can be done in the MIDI configuration page), and at your computer side disable the option which activates MIDI forwarding. Best Regards, Thorsten.

You forgot to initialize the SRIO driver, see also the Init() function of this example: http://www.ucapps.de/mios_c_set_dout.html Best Regards, Thorsten.

No feature, but a known issue: http://www.midibox.org/forum/index.php/topic,9457.msg117957.html#msg117957 The bugfix is already in the SVN repository. Best Regards, Thorsten.

Yes... see also http://www.midibox.org/forum/index.php/topic,13488.msg116060.html#msg116060 Best Regards, Thorsten.

No, this isn't required for MIOS8, as there is only a single interrupt level (for MIOS32 it's a completely different story...) Disabling interrupts is sufficient for "atomic operations" Best Regards, Thorsten.

Wow, thats an interesting input! This could explain, why people sometimes report a problem with their MIDI IN port, or why sometimes optocouplers got fried. Therefore I added TEST IN1B to the troubleshooting page, but I fear that I've to change the labels in all schematics to be sure that nobody interprets them incorrectly. TEST IN1B: Check that the 6N138 optocoupler is put with the correct pin orientation into the socket! Pin #1 (marked with a notch) shows into the direction of J11! Note that the optocoupler could be damaged if you are trying the wrong pin orientation! [/code] Best Regards, Thorsten. P.S.: LyleHaze: as always great tips!

I'm patentially waiting :) Best Regards, Thorsten.

No, samples are not supported. See also http://www.midibox.org/forum/index.php/topic,10421.msg78752.html#msg78752 You should go for HardSID if you are finding sample playback so important. Best Regards, Thorsten.

Ok, I added a record button and LED Problems: confusing handling if not consistently provided for most parameters in all menu pages, and there are more than 8 MIDI Output ports (currently: 20 different ports like USB1-4, UART1-2, IIC1-8, OSC1-4, AOUT1-4, Bus1-4, etc...) and more than 8 AOUT channels. I already spent some thoughts on providing a "quickselection page" of up to 16 "most important values" when pressing the SELECT button. But by thinking a step further I came to the conclusion, that this would only result into a lot of additional effort and many complains from users who think that they found a bug if a certain parameter isn't selectable or not visible on the page (e.g. MIDI Channel Selection in MIDI page: 1-16 could be selected, but what about "All" and "None" - a user could overlook such important options if he only uses the quickselection but never turns the encoder below the value) Best Regards, Thorsten.

Thank you - this bug exists since 224 days! Shame on the guy, who requested a bugfix for "character artifacts" but hasn't tested all menu pages! ;) (*) The fix is already in the repository and will be available with the next release. Best Regards, Thorsten. (*) just kidding - I knew that such dramatical changes will cause new issues w/o intensive tests

Yes, good hint LyleHaze - it makes sense to check a precompiled application after MIOS has been repaired If there is an issue with your LCD: there are a lot of troubleshooting infos in the forum and in the Wiki! Best Regards, Thorsten.

Probably you corrupted MIOS during your first experiments. I would propose to upload it again (-> mios_v1_9f.hex of the MIOS update package), thereafter upload the application. Note that once you've repaired the MIOS installation, you don't need to upload it again. Just ensure, that your application never overwrites the range between 0x0000..0x2fff (this range is excluded automatically by the linker script if you are using the original MIOS toolchain setup, and not your private .lkr file) Best Regards, Thorsten.

MIDI-Ox: uncheck the "Automatically attach Inputs to Outputs during selection" Option. It causes a SW loopback. Thereafter, deselect the MIDI Ports, select them again - this will activate the IOs without creating the loopback. Could it be, that you are running MIDI-Ox and MIOS Studio in parallel? THis would explain, why MIOS Studio behaves so strange as well. Best Regards, Thorsten.

Check the MIDI port routing in MIDI-Ox, it seems that you've configured a loopback there which can cause such random effects. Also the "internal MIDI routing" in MIOS Studio can be easily messed up - have you ever changed it? (it can be displayed with Options->Show Internal Routing, and restored with Options->Restore Default Internal Routing) Best Regards, Thorsten.

Some PIC programmers don't erase the ID field correctly. A workaround is explained at the MIDI Troubleshooting Page (requires to use the PIC programmer) Something is wrong with your toolchain setup, because a MIOS application should start at 0x3000 (at 0x0000 the bootloader is located). But don't worry, there is a overwrite protection for the bootloader. It's still there and you haven't destroyed it (I'm writing this before you are assuming that the PIC has to be reprogrammed - this won't help in your case) For further analysis it would be interesting if the loopback works for other MIDI events. E.g., you could send a MIDI Note event with the virtual keyboard of MIDI-Ox and check if it is received back. Best Regards, Thorsten.

Thank you for the nice comments! Here is the .mp3 of the song. It isn't 100% perfectly played, especially the drums could be better, but I think that by doing corrections it would loose the live feel: http://www.ucapps.de/mp3/midibox_seq/mbseqv4_demo2.mp3 Best Regards, Thorsten.

Link to video MIDIbox SEQ V4 has reached beta state, let's celebrate this with a new demo! 0:00: The electronic harp is played by Sculpture (part of Logic Audio) - a Physical Modelling Synth which I really like! 0:00: MBSEQV4 plays the 16-step sequence with a new "step progression" feature: on each 4 step interval, the step is triggered twice. In addition, a customized groove template is applied on the velocity to accent the notes based on the master measure. This results into a more complex sequence which varies on each beat, but still sounds nice and not too random! 0:01: to understand the "step progression" feature watch the GP LEDs - they are stopping each 4th step 0:11: an Echo Fx is added with 64T delay. Note value is increased by +3 and forced to scale 0:17: an additional VST synth is added which gets use of the new "step progression" feature as well 0:21: Echo Fx: temporary increased to 6 repeats with +3 Note Value and +150% delay on each echo - let's scrub the harp! 0:31: adding drums 0:41: adding more synth lines, again with "step progression" to vary the sequence 1:04: adding a chord sequence played by MIDIbox SID V2 (a typical arpeggio patch is used) 1:48: probably you haven't noticed it due to the bad video quality, but I switched to another pattern which plays the electronic harp at C-3 on each step - the groove template is still enabled (boring?) 2:05: now something completely different: a LFO is applied on the harp sequence with sine waveform and an interval of 4 steps. Force-to-Scale is enabled 2:07: the LFO also sends a CC to Sculpture to vary the timbre. 2:13: adding Echo Fx (1 repeat, 64ppqn delay, +150% tick) to this "modulated sequence" 2:19: changing LFO waveform to Triangle 2:31: changing LFO waveform to Sawtooth 2:36: changing Echo Fx to 6 repeats 2:46: slowly changing LFO the period to 16 steps (enjoy the change-over effects!) 2:52: slowly changing LFO reset to 16 steps (enjoy the change-over effects!) 3:00: changing LFO waveform to Sine, play drums again 3:14: changing LFO waveform to Triangle 3:21: changing CC offset of LFO 3:33: unmuting the other instr uments 3:56: switching back to original sequence (my favourite moment ;-) 4:16: muting/unmuting the toms... 4:30: slowly muting the tracks 4:40: thanks for listening! :-) Best Regards, Thorsten.

I'm using a dedicated t.mix 1202 mixer for my MBSID. I modified it, so that beside of the 4 stereo inputs, the remaining microphone inputs can be used as mono channels. Whenever I want to use one or more SIDs in Bassline/Drum/Multi mode, I just plug the audio cables into different input sockets. And I'm using the Aux outputs for routing SIDs to alternative (Fx) channels. Best Regards, Thorsten.

It seems that your MIDI interface sends some additional MIDI bytes while the EEPROM is programmed. Since interrupts have to be disabled during this time, it could cause a MIDI buffer overrun. I never saw such a strange interface behaviour before, but it's the only explanation I have for such an error message. Possible workaround: you could split the .hex file into multiple pieces and download them separately. Each file contains an EEPROM block. I guess that these files would work fine for the latest MBSID release (this is quick copy&paste, I haven't tried this...) eeprom_1.hex :0200000400F00A :100000004C656164205061746368202020202020AA :10001000000000000000000000008000FF000080E1 :1000200000FF00008000FF00008000FF0000800053 :10003000FF00008000FF50008000FF00008000FFF4 :1000400000800080008000800080008000800080B0 :1000500000007F00100002000000100002000000FD :10006000000400F00008000040800200001F0500AE :10007000001400F00008000040800200001F05008E :10008000001400F00008000040800200001F05007E :10009000000400F00008000040800200001F05007E :1000A000001400F00008000040800200001F05005E :1000B000001400F00008000040800200001F05004E :1000C00001800000000180000000018000000001AC :1000D000800000000180000000018000000000009E :1000E00000C00030FF0000FF304020000080808012 :1000F00000400050FF0000FF501030000080808062 :00000001FF [/code] eeprom_2.hex [code] :0200000400F00A 10010000010003C000000000020003C00000000066 :10011000030003C000000000040003C00000000052 :10012000050003C000000000060003C0000000003E :10013000070003C000000000080003C0000000002A :10014000FF000F3F0300000000000000000000005F :10015000000000000000000000000000000000009F :10016000F00000000000000000000000CB00001FB5 :1001700080CB00203FA0CB00405FC0CB00607FE081 :10018000404040404040404040404040404040406F :10019000404040404040404040404040404040405F :1001A000404040404040404040404040404040404F :1001B000404040404040404040404040404040403F :1001C000404040404040404040404040404040402F :1001D000404040404040404040404040404040401F :1001E000404040404040404040404040404040400F :1001F00040404040404040404040404040404040FF :00000001FF eeprom_3.hex :0200000400F00A :1002000000000200027800000000006000000060B2 :1002100000007F400000000010007F400000000050 :1002200010007F400000000010007F400000000030 :1002300010007F400000000010007F400000000020 :100240000000000002780000000000600000006074 :1002500001007F400000000010007F40000000000F :1002600010007F400000000010007F4000000000F0 :1002700010007F400000000010007F4000000000E0 :100280000000000002780000000000600000006034 :1002900002007F400000000010007F4000000000CE :1002A00010007F400000000010007F4000000000B0 :1002B00010007F400000000010007F4000000000A0 :1002C00000000000027800000000006000000060F4 :1002D00003007F400000000010007F40000000008D :1002E00010007F400000000010007F400000000070 :1002F00010007F400000000010007F400000000060 :00000001FF [/code] eeprom_4.hex [code] :0200000400F00A :020300000100FA :00000001FF In MIOS Studio, please enable Smart mode again! Best Regards, Thorsten.

The schematic was already on the BankStick page as directly visible .gif file... However, I added a link to the .pdf and Wilba's explanation (slightly changed... Wilba: if you want to change the wording, just modify the file in the repository) Best Regards, Thorsten.

Thats a great idea, thanks for your help to improve documentation! :) But as Ilmenator already wrote: it makes sense to use the Wiki. Advantage: everybody can help to keep the pages up-to-date whenever details are changing. E.g., if I should ever release a mios_v1_9g.hex file (no need yet as there are no known bugs), I will probably ommit the update_*.hex variants, as nobody uses the old bootloader anymore, accordingly there is no need to check if an update is required. Refering to a update_without_installed_mios.hex file would only lead to unnecessary confusion. Best Regards, Thorsten.

update_without_installed_mios.hex or mios_v1_9f_pic18f452.hex will work in your case. (I guess that the most recent bootloader version is already installed, therefore you could also upload MIOS directly) Best Regards, Thorsten.

Hi, Great to see, that you already got so much working before you wrote your first posting! :) Could you please attach your modified .asm file to this article? This should give me a complete overview. It's in the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=home:mbhp:module:din_dout_pin_list Best Regards, Thorsten.