TK.

A "running LED feature" is already available, the step position will just be XORed with the LED information which is currently displayed (e.g. gates, mutes, selected pattern, etc...). The code can be found in seq_led.inc, SEQ_LED_UpdateIRQ It looks complicated because of the possible variations (e.g. 4 LED lines instead of 1), but when you are searching for "if sequencer is running XOR position to GP pattern" you will find the code which is doing this job. For multicolour LEDs, you just need to replace this XOR operation by code which outputs the position on two alternative DOUT shift registers instead. Best Regards, Thorsten.

The arpeggiator runs slower when you synchronize it to an external MIDI clock. Just enable this synchronisation (via CFG menu, JSynthLib or CC), and try out following arpeggiator rates: If the arpeggiator is synched to MIDI clock, use following rate settings: - 64th note: 124 - 32th note: 118 - 16th note: 106 - 8th note: 82 - 4th note: 34 [/code] MBSID V2 will provide an alternative internal BPM generator, but if you synchronize your gear from a host sequencer anyhow, you will be happy with external clock synch (which is already available) Best Regards, Thorsten. P.S.: nice demos, Jess :)

You can implement different button values with meta events (-> mb64_meta.inc, mb64e_meta.inc) Best Regards, Thorsten.

Hallo, leider gibt es keine komfortablere Loesung, da musst Du jetzt durch! ;-) Im Grunde musst Du Dich nur nach dieser Anleitung richten http://www.ucapps.de/howto_tools_mpasm.html Falls mpasmwin sich mittlerweile nicht mehr im MCHIP_Tools Verzeichnis befindet, so klicke im File Explorer auf den "Suchen" Button, und tippe das Schluesselwort "mpasm" ein Die Suchen-Funktion kann man auch mit Windowstaste-F direkt aufrufen Und den Hund kann man wegklicken! ;-) Gruss, Thorsten. P.S.: bin diese Woche nicht zuhause, kann erst ab Samstag weiterhelfen

To 1) yes, to 2) you don't need to stuff them for the "DINX1 functionality" (compare with the mbhp_dinx1 schematic) Best Regards, Thorsten.

I don't want to misuse the V2 thread for introducing new V1 release candidates anymore, therefore this new topic. Razmo requested two changes in the arpeggiator handling to improve the usability. I found both very useful, and have build this into the application as default option (the old handling has been replaced by the new one!). Here the description in Jess' words (he can explain this better than me :): The same from the ChangeLog: Link to application: http://www.ucapps.de/mios/midibox_sid_v1_7303b_rc6.zip Best Regards, Thorsten.

John mentioned a latency of 1..1,5 seconds, this is not caused by the MIDI interface - the midisport 2x2 has a latency and jitter of about 5..10 mS +/- 1.5 mS (see also http://www.midibox.org/forum/index.php?topic=2342.0) So, it's more likely that the software causes the high latency - another MIDI interface won't help in this case! Best Regards, Thorsten.

Hi, the pull-up resistors are also required for rotary encoders. For the last DINX4 module, you don't need to stuff the unused 74HC165, so long R33 is connected Best Regards, Thorsten.

The search function works in the board context you are currently in. E.g., if you view the "Part Questions" board, the search function will only search there, and nowhere else. So - either change to the global context (e.g. click the home button), or use "advanced search" Best Regards, Thorsten.

Hi Robin, under normal circumstances it doesn't really matter, but if you have the choice: the core which sends the most events should be at the end of the chain Best Regards, Thorsten.

Hi Rick, midio128_v2_1c is the application which handles the serial DIN/DOUT chains. The MIDI setup can either be changed directly in the application source code, or it can be changed on-the-fly without reprogramming by uploading new configuration data in form of a special .syx format. The mk_midio128_syx package contains a script which allows you to generate this data from a .ini file (readable format) Nobody has programmed a user friendly GUI for this configuration possibility yet. If you want to change the configuration without the .syx approach, you can edit it in midio_presets.inc E.g., for the merger function, search for MIDIO_Presets_CFG0 db 0x00, 0x00 ; disable merger by default and replace it by: MIDIO_Presets_CFG0 db 0x01, 0x00 ; enable merger by default note that this setting will be overwritten once you upload a new .syx again If the merger works thereafter, I would assume that something has gone wrong during the .syx upload via MIDI-Ox. Did you follow this hint? # Use i.e. MIDI-OX to send the .syx file to your MIDIbox. Don't forget to set a # delay of appr. 750 ms between every SysEx block (after F7) under SysEx->Configure! [/code] Best Regards, Thorsten.

Hallo Chris, am besten kontaktierst Du Thomas (Anyware), der hat den besten Ueberblick ueber die verschiedenen Boardversionen, und ist sehr hilfsbereit -> http://www.anyware-instruments.de/navi_new/kontakt.html Gruss, Thorsten.

Hi Robin, actually it's very easy in your case - just create a MIDI chain: remove the optocoupler of the second core, connect J11:Vs (ground) of both modules together, and connect the MIDI Out of the first core (J11:MO) to the MIDI In of the second core (J11:MI) In the application software of the second core, you have to enable the MIDI merger within Init(): MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_ENABLED); Best Regards, Thorsten.

Here an extraordinary B4 controller made by Mark - he wrote:

Perfekt! Alles bestens :) Gruss, Thorsten.

Zunaechst einmal muesstest Du die MIOS IDs anpassen, damit jeder core eindeutig zu adressieren ist. Dies macht man entweder bereits beim Programmieren des Bootloaders (diese Moeglichkeit scheidet bei Dir aus), oder man macht es nachtraeglich mit der change_id Applikation. Die kann man auf der MIOS Download Seite herunterladen, die Anweisungen zum Aendern der ID findest Du im README.txt File. Kurzanleitung: die Device ID in main.asm aendern, neues .hex file bauen, die Device ID in MIOS Studio zunaechst auf 00 einstellen, das .hex File senden. Danach antwortet der Core mit der geaenderten Device ID (also bspw. 01), und kann auch nur noch so angesprochen werden. Bedeutet: die darauf folgenden Code Uploads muessen mit der geaenderten ID erfolgen. Beim Master Core bleibt die ID auf 00, die Slaves erhalten die IDs 01, 02 und 03 Zum Programmieren steckst Du die Slave PICs am besten in das Core Modul des Masters, so gehts am einfachsten. Es gibt zwar auch bequemere Methoden, doch die sind bei einem Anfaenger fehlertraechtig (deshalb nicht von anderen Artikeln im Forum verwirren lassen). Die Files, die Du oben aufgelistet hast, sind richtig. Rein interessehalber wuerde ich gerne wissen, welches .hex File Du beim Bootloader/MIOS Update aufgeladen hast (ich moechte ausschliessen, dass hierbei etwas falsch gelaufen ist) Gruss, Thorsten.

From the MIOS application side this is very easy to realize, it's similar to the Motormix emulation. But it will be difficult to get those 2x72 LCDs in small quantities - not to say: it's nearly impossible! In addition, you will have to develop a program which communicates with the MIDIbox, e.g. which handles the parameter names and values. This is not trivial, since nearly each host system requires a special adaption (or a different approach...). Some informations how to handle this are only provided under NDA from the vendors - no chance to get an open source implementation. Best Regards, Thorsten.

Hi Wilba, I've already tried this method (e.g. after gate off: D/S=0, S=15, wait 33 mS), it doesn't help, there is still some randomness. Only adding an additional delay of 33 mS between D/S=0 and S=15 helps, but 66 mS latency is not acceptable IMHO Funny, I also considered this - but this would lead to compatibility problems (not every SID can be clocked at higher rates), and an uncontrolable delay would still exist. Best Regards, Thorsten.

No, using J14 as input cannot cause such problems. Have you ever checked that your DOUTX4 module is working? E.g., with MIDIO128 or the DOUT test application? Best Regards, Thorsten.

http://www.midibox.org/midibox_sj/speakjet_test.mp3 Best Regards, Thorsten.

I've already considered the re-use of the ADSR registers, 3 bytes are required for a 16bit envelope rate counter and a mode variable which holds the ENV state. There are also other things which prevent me from implementing this into MBSID V1, one thing is, that the ADSR settings are directly written into the 4bit SID register shadow space, there is no register which holds the 7bit value received via CC/SysEx. So, not only resolution is a problem, but also the refresh of SID registers Please believe me: it's more effort than implementing a new engine from scratch, therefore I don't want to spend so much time on the MBSID V1 engine anymore. Currently the wavetable sequencer can be used, so it's not impossible to modulate the sustain level, it's just not so comfortable. You can use the wavetable rate as a "decay rate" And before I'm starting with MBSID V2, I want to create the SpeakJet synth and MBSEQ V3... just to explain, why I don't start immediately ;-) Best Regards, Thorsten.

Wilba: in the meantime I know, that even the drastic measure to cut off the 5V supply for a short moment doesn't really help. The biggest problem is, that a write to the ADSR registers cannot be synchronized with the envelope rate counter. Jess: I did a lot of checks with the Delay parameter in conjunction with a controlled ADSR reset The last algorithm I tried was: o on Note On clear the gate and clear ADSR, start the delay counter o after the delay has passed (e.g. 33 mS or more), refresh ADS, R remains 0, set gate o before the gate is cleared, refresh R as well In general this allows to reset the EG, but the delay bug still can happen. Not so frequently anymore, but sometimes. And I've also an explanation for this: if the EG is still in decay phase (sustain level not reached), and we switch into the release phase by clearing the gate bit, the new compare value for the rate counter can be lower than the compare value used during decay phase -> a counter overrun will happen -> 33 mS additional delay In the meantime I think it's easier to find good working ADSR settings than using a ADSR reset workaround which doesn't solve the problem under all conditions, and has some additional unwanted side effects. To the additional EGs: as mentioned above, this will be considered for the MBSID V2 engine. For MBSID V1 the integration is not possible due to RAM limitations (3 EGs require at least 9 bytes, SID engine registers must be located within 0x100-0x1ff, and this address space is full, a major-rewrite of the V1 engine would cost me more effort than programming the V2 subsystems) However, with MBSID V1 you can already modulate the sustain parameter with the wavetable sequencer - it allows you to generate any waveform with up to 32 steps :) Sustain is CC#57/58/59 (all voices seperately) or CC#56 (all voices together) Best Regards, Thorsten.

If an error happens for any reason, the SysEx uploader has to retry, otherwise the old code block in combination with the new ones which have been uploaded successfully can lead to a random behaviour (!) once the invalid code will be executed. Worst case: flash write with bypassed protection MIDI-Ox doesn't know about error responses, and cannot retry. Only MIOS Studio can handle this, but the current release not under all circumstances. This is a know issue, and partly fixed in the unreleased version. A complete fix would contain an additional upload procedure which ensures that code will never be executed so long all blocks have been uploaded successfully, but due to lack of Java knowledge (and time) I haven't implemented this. (Discussion can be found in the MIOS Studio section) I don't know what happened before, therefore this general statement. Maybe something has gone wrong 10 uploads before? You are writing that you've tried an upload via MIDI-Ox. This is very critical in your case Do I see it correctly, that other MIDI messages than the SysEx streams by MIOS Studio are sent to the core? This cannot work under all circumstances, here a buffer overrun is very likely, since during a flash write USART cannot receive MIDI data. So - if this is the case, the problem is not your program, but your system. It must be avoided, that any other MIDI sender is doing MIDI transfers during a code upload Best Regards, Thorsten.

Hi Thomas, Why haven't you mentioned this before? ;-) 0B means MIDI buffer overrun. This can only happen on a programming error at the application side. The current official release of MIOS Studio cannot handle such error messages correctly, therefore the confusion. I will ask Adam for a new beta release. Potential programming problems which could cause this: - wrong use of MIOS_MIDI_* functions - overloaded interrupts - delays I think that your .c file could be interesting Best Regards, Thorsten.

Hi Jess, I'm sure that this sequence would work. I think the best is to replace the SID reset feature by a function which sets ADSR=0 immediately on a gate set request. This would allow to use the Delay parameter of MBSID to shift the gate trigger Best Regards, Thorsten.