TK.

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.

Hi Thomas, debugging: just open the "main.lst" file and search for the error message there, it helps to understand, which line of code has caused this warning. With the normal MIOS version, you should always receive a checksum... did you ever notice problems with your MIDI interface before? Best Regards, Thorsten.

Yes, especially if IIC_SpeakJet_Init() hangs up - this means, that the IIC clock is stretched endless just because of the missing pull-up resistor. The jumpers should be closed for ID offset 0 Best Regards, Thorsten.

Hi Chris, to say it short: for such a project you won't run into problems. In the meantime I've programmed a completely assembly based USB firmware in order to get rid of the C18 compiler. As workaround for the EUSART bug I'm using the MBHP_IIC_MIDI module. Resp. I'm using 4 of them in order to get 4 MIDI IOs. The USB peripheral works ok, but I noticed a strange effect for which I don't have an explanation. I can only say, that it happens with the CDC example as well as with my own firmware: if the OUT pipe is not serviced immediately, and something should be sent through the IN pipe, the IN pipe can be blocked for more than 40 mS. I've described the details here: http://www.midibox.org/forum/index.php?topic=6413.0, but unfortunately only in german (babelfish.altavista.com helps to translate the text) However, so long you don't use the chip as a bridge, and USB streams are handled internally, you will propably never notice this issue. Even with my project (MIDI bridge) the problem can only happen under very special circumstances, which might be acceptable. I never tried to program the PIC18F4550 with a JDM programmer... Best Regards, Thorsten.

Ok, after a lot of experiments I can only say: there is no cure for the delay bug. Even a hardware reset doesn't reset the rate counter, and depending on the EG state the amplitude is at the wrong level for ca. 32 mS Best Regards, Thorsten.

I've tried the method described by Wilba some time ago, it works, but as already mentioned, only for an emulated decay or release phase, not for an attack phase, because once the sustain is increased, the envelope drops to 0. This leads to the problem, that for a correct envelope behaviour (e.g. gate cleared while decay phase not finished should lead to a longer release phase) the SID EG has to be emulated. This is so much effort, which I don't really want to spend. It's better to do this with a wavetable or an envelope. And with MBSID V2, you will get independent wavetables, more envelopes and a trigger matrix. You could use wavetables or envelopes for this purpose, and trigger it on Note Offs (works for all voices, or for each voice seperately) Some news about Jess' proposal for reseting the envelope properly: unfortunately it doesn't work, the delay still exists. I did some research in the source code of reSID (one of the most accurate SID emulators) and found following interesting hint: // Check for ADSR delay bug. // If the rate counter comparison value is set below the current value of the // rate counter, the counter will continue counting up until it wraps around // to zero at 2^15 = 0x8000, and then count rate_period - 1 before the // envelope can finally be stepped. [/code] So, we have a 15bit counter which is incremented on each SID clock cycle. Once the counter has reached the compare value (in the reSID source code, it's called rate_counter_period, it depends on the selected rate), the counter is reset, and the EG is stepped forward. Now the bug: once the EG changes the state (e.g. from sustain to release), the counter compare value will change, but the rate counter won't be reset. This results into an unpredictable delay (effect #1) until the EG will be stepped again. And if the compare value is lower than the one before, we have to wait for a counter overrun first, then the counter runs from 0 to the new compare value, thereafter the EG will be stepped (effect #2) So, in worst case, we get a delay of 32767 cycles, makes ca. 32.8 mS @ 1 MHz, and this delay cannot be controlled by software! Currently I'm doing some experiments with the reset input of the SID again. I must say, that I haven't understand all effects yet I'm seeing on my scope (I've some assumptions and a possible improvement of the SID reset feature, but better not to write them down before they are proven ;-) Best Regards, Thorsten.

Hi David, is this a deterministic failure? Means: are you able to reproduce this with a know sequence of MIDI events? Are you able to record and playback a scenario where Note Off fails (e.g. with a MIDI sequencer) Does it sometimes happen, that a Note On event (a Note) is skipped? So far I remember, the MIDIO128 application has so much "headroom" in the performance, that it is ensured, that an incoming MIDI event can never get lost, regardless of the MIDI traffic load rate. But something which could happen is, that for example the whole apparatus causes spikes on a bad shielded MIDI line - here it helps to improve the shielding. Best Regards, Thorsten.

You can really be sure that you can re-use the modules as well as the hardware case for MBSID V2, seems that I cannot highlight this often enough ;-) Something what could happen is, that the module matrix nodes could get another purpose. Currently the sources are statically E1/E2/L1-L6, and the targets are statically O123 Pitch/PW and Filter, but in future the sources and targets could be freely defineable. This could mean in other words, that the labeling of the mod matrix does only suit with the default assignments, and that they can be customized - but I cannot say more to this topic until now. Again: you can be sure, that the CS hardware won't be changed Jess: the hypotheses you are writing are making sense to me, I've had similar "impressions" about the envelope behaviour in the past. Especially I can confirm that commonly used 20 mS delay between release=0 and the next gate trigger is only related to the refresh rate normal used by SID trackers. It was just save enough to say, that it will perfectly work with 20 mS From my experiences with MBSID-D, the delay between setting Release=0, refreshing the Sustain/Release register and setting the gate can be much shorter. But I never tried different combinations of D (and R) values in order to prove the miminum delay. The assumption, that a delay much lower than 1 mS are enough make also sense, this corresponds with the obervations I made last sunday with the reset trigger. Here I have to repeat again: it seems that the reset input doesn't affect the flip flops of the EG. I had to add a delay between the reset deactivation and the refresh of the SID registers, otherwise the envelope works like without reset - means especially: if the envelope hasn't reached zero, a new gate trigger will start the attack phase - the volume hasn't reached zero. This means in other words (and this is my hypothesis): with a reset, ADSR will be set to 0, but the EG won't be affected. So, it doesn't make a difference if all SID registers are reset, or only the S/R registers (I'm not sure, but I think that A/D don't neet to be set to 0, since the gate bit is cleared anyhow when the workaround is used) Tomorrow evening (it's too late now for such experiments...) I will try out the following: I will replace the reset option by a function which sets the release rate to 0, waits for a specific delay, and then sets the gate flag. Biggest advantage: this can be done for each oscillator individually! Nice for polyphonic sounds :) Best Regards, Thorsten.