TK.

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.

AC: don't forget the bypass caps, when I made the first try it turned out that they are essential! Current state of my plans: I had a nice talk with Lorin, he will publish the analog circuit at the audio out of his board. I will take his firmware has inspiration, but will work on a different one (more focused on MIDI) Main features that I'm planning to do: an easy to use "learn mode" which allows to prepare speech sequences by pushing a button and recording the speach elements from a MIDI keyboard. Another mode, which allows to trigger these sequences from the keyboard, and another one, which allows to split the keyboard into four (or more) zones in order to play selected speech sequences with transponation I've also some modulation possibilities (LFO, ENV on pitch, sequencer?, etc) in mind, but haven't evaluated yet, if the SpeakJet can handle OSC parameter changes properly during a voice element is played. The implementation itself isn't so difficult, the challenge will be to develop an easy to use "human-machine interface" Best Regards, Thorsten.

So far I remember the JCH tracker used the following technique: 20 mS before the gate bit was set, it cleared the Sustain/Release register. This ensured, that the envelope reached the floor before the attack phase started again. Such a method is bad for MIDI, because it adds a latency of 20 mS - suboptimal for live playing, and a host sequencer must provide a timing compensation function. A modification of this method I have used for MBSID-D was the possibility to clear the Sustain/Release at the end of a wavetable sequence - this works quite well so long there are no overlapping notes - good for drums, bad for lead sounds. This technique could be enhanced by an automatic timer based clear, the required delay can be determined from the release rate. This is what I'm planning to implement for MBSID V2. It's not a complete solution, but it works good especially for short, punchy sounds. Best Regards, Thorsten.

You have to change the encoder type in mios_tables.inc Best Regards, Thorsten.

Alright, I've integrated an automatic SID reset on each new note as 6th sound engine option -> http://www.ucapps.de/mios/midibox_sid_v1_7303b_rc3.zip for the register refresh, it is important, that the ADSR registers are initialized before the gate flag is set. Fortunately I already wrote the appr. code for MBSID-D, so it was some quick copy&paste. An interesting effect that I noticed is, that the envelope won't be reset immediately with the RES input! The reset itself should be held for 10 SID CLK cycles (recommented in datasheet), but after the reset some additional cycles have to be inserted before the registers are written, otherwise the attack won't work, and with certain settings the release phase stays active. So, it seems, that some flip flops of the ENV logic are not directly connected to the RES input! Jess: could you please check, if the same sounds are possible like with your reset implementation? The reset routine can be found in sid_sr.inc, SID_SR_Reset Here the demo which Jess has made with his own engine - again: quite imressive :) -> http://www.midibox.org/users/razmo/8580HRDRST.mp3 Best Regards, Thorsten.

Hi Jess, yes, the reset line can be accessed from the shift registers, maybe this feature could be a new sound engine option? ;-) Best Regards, Thorsten.

now where you mention this - it could already be integrated as a sound engine option (2 bits are still free) - on the other hand: maybe there is a better usage for the remaining bits? The clock frequency can be changed in USER_Init (works only when the SID is clocked from the PIC, but this is recommented anyhow). Note: the frequency can also be changed from MIOS Studio on-the-fly without rebooting the PIC, the PR2/CPR1L SFRs can be written like SRAM cells (addresses: 0xfcb and 0xfbe) Best Regards, Thorsten.

Hi Jess, short answer (I'm currently a little bit busy with other nice stuff :-): my email address is tk _at_ midibox.org MBFM drum engine: it exists :) -> http://www.ucapps.de/midibox_fm/mbfm_drum_panel_pre1.gif There are also some samples on my website - especially the 2 operator bassdrum and hihat/cymbal are killer! The specs can be googled with the keywords "ymf262 datasheet" Best Regards, Thorsten.

Timer() would be a bad choice, because it interrupts the main task, and could therefore also interrupt a MIDI stream; this could result into sporadically sent invalid MIDI events. So, if timed transactions are required, the Timer should request a send, and Tick() should check for this request flag, clear it and send the events (similar to the approach used for DISPLAY_Tick()) Best Regards, Thorsten.

You could also email me the .mp3 files, so that I can put them on the midibox server Best Regards, Thorsten.

I considered this subsystem, but then I decided to put this all into the MBSID Lead engine - all the new possibilities (enhanced modulation matrix, trigger matrix, independent wavetables, Waldorf XT like modifiers/operators) will provide enough fun for the next year, and the rest will be implemented in MBSID V3 ;-) Here an example, that the slight enhancements of MIDIbox FM (crossconnections between LFOs, multistate envelope) can already lead to wonderful effects: http://www.midibox.org/forum/index.php?topic=6542.0 - hard to imagine, how the next generation will sound :) Best Regards, Thorsten.

Hi uclaros, you are right - the two functions are not correlating well together, this is a corner case which never has been considered But as you've already noticed, the usage of the C wrapper is so easy, that such dedicated functions should better be programmed directly. It gives everybody more freedom to do even more individual stuff. I'm glad that you were able to use it in such a short time! :) Best Regards, Thorsten.

Yeah!!! :) Btw for those who don't know RKO: check out http://remix.kwed.org, search for "Razmo" and download at least the Terra Cresta Remix - it's one of my favourite remixes, not at least because of the spectacular sounds :) Best Regards, Thorsten.

Both. I want to use the same drum sound engine, but with dedicated parameter sets for each drum sound. Target should be to preload as many different drum sounds as possible into the RAM in order to switch fast between the parameter sets when new keys are played. Maybe some background info you are missing: I've evaluated the requirements for a drum engine some time ago, and I wrote a special firmware dedicated for drums - see: http://www.midibox.org/forum/index.php?topic=5703.0 key feature: 21 instrument patches are hold in RAM at the same time, and you can play them with individual keys polyphonic (!) Free voices are determined automatically (same concept like MBFM), and you can group instruments, so that they allocate the same voice (e.g. for HiHat) The "final" firmware can be found in this thread as well ("mbsid-d_alpha3.zip") I never released it on my website, because I find that the usage is just too complicated for the world ;-) Therefore I came to the conclusion, that for MBSIDV2 I have to downstrip the parameters for individual drum sounds in order to allow more induitive use - most important: fast results without the background knowledge that you've explained here Thanks a lot for your descriptions on how to make these sounds, I've also some info about this in the book "Synthesizer" from Florian Anwander, but it's long time ago I read it, and I never found the time for searching the perfect drum patches Here you could really help me! :) Best Regards, Thorsten.

Wilba: thank you for this nice idea! I will try your patch this evening, and propably extend the wavetable tutorial, because this possibility shouldn't get lost in the deep grounds of this forum :) Jess: yes, the oscillators can be synched with a single write into each control register. But I'm doing two writes - one to trigger the reset (test bit set), another one to set the gate bit. The advantage is, that the envelope won't start before the oscillators have been synched, this avoids unintented "crackles" Your speculation about the volume sounds interesting. I will also do some tests with different SIDs in order to find out, if I can notice the same (I like such tests ;-) Btw.: have you ever checked some different caps on pin 1/2 and 3/4? I never had the endurance for finding out the best fitting values :-/ MIDI LED: if a DOUT shift register would be connected to the core, you could assign a Rx and Tx LED to the outputs by changing the DEFAULT_MIDI_RX_LED and DEFAULT_MIDI_TX_LED assignments in main.asm Alternatively, you could also trigger a free pin of the PIC instead, just modify the appr. code in midi_rxtx.inc :) Oscillator drop outs: it could be that this problem is related to the "unsynched register write issue" - more details about this can be found here: http://www.midibox.org/forum/index.php?topic=5748.0 I built a special clock synchronisation routine into the firmware, but it only works if the SID is clocked directly from the PIC, and not from a 1 MHz oscillator. So: could you please try if the problem disappears with a direct clock connection? Your patch: just great! I see, these two changes open a completely new field for sounds - Jess, when will you release your first preset Bank? :) I just have noticed that I forgot to disable the DEFAULT_FILTER_TYPE_SWITCH in main.asm, therefore: if somebody has uploaded the main.hex file, the filter settings for a 6581 will be propably selected. Best Regards, Thorsten.

Thats a strange effect, I never heard about this before. What happens, if you press a layer or the Edit button? (this would re-initialize the screen) Best Regards, Thorsten.

Hi Thomas, the type initialisation has to be done in Init(), before DISPLAY_Init() is called Sorry, I just have noticed, that this is a documentation gap Best Regards, Thorsten.

Hi Jess, the new build can now be found here: http://www.ucapps.de/mios/midibox_sid_v1_7303b_rc2.zip The "gate stays active" flag is the fith bit of the sound engine option I also redefined the filter type switch - now it allows to switch between all 4 types (6580/8580 with or without calibration) - hope that all 16 possible combinations (type 1=0..3, type 2=0..3) are working ;-) The reason why I wrote "don't be confused about the test flag" is, that actually this isn't really the test flag you know from the SID - it is a "sync request" instead and utilized within sid_sr.inc (the SID register access handler). There is the place where all SID registers are written as fast as possible (as the serial interface allows). It is ensured, that all three oscillators are synced within less than 20 uS, this delay is acceptable I guess - let's assume some bass tones are played around 200 Hz. (is this still bass? anyhow...) 200 Hz have a period time of 5 mS, and 20 uS are just only 0.4% of this period. I think that this small offset is ok :) sid_sr.inc also ensures, that the synchronisation is done *after* all other SID registers have been updated. Yes, the amplitude is much louder, this especially brings one of my (older) 6580 chips into a nice distortion when filter is active at the same time :) But I think that it makes sense that I check this synchronisation again on the scope (or sampler), it's long time ago I integrated it, and I only tested it by ears, and not visually. To the transformer of your cannibalized rack: I think it will also work flawlessly in future, so long no big consumer - like a backlit LCD - is connected to the core. The voltage regulators transform the unused wattage (U*I) into heat. Than higher the voltage difference between the input and output voltage and/or than higher the current, than higher the heat problems. The 8580 draws ca. 25..50 mA in the 9V domain, the voltage difference is in your case ca. 15V-9V = 6V (15V because of the voltage drop over the rectifier), makes ca. 150..300 mW - so, no issue :) Best Regards, Thorsten.

Hi Jess, I like this idea, and fortunately a change is very easy: open sid_sw.inc, search for "SIDSW_Note_GateClrReq" and replace: bcf INDF2, 0 ; SID_Vx_CTRL.0 is the gate bit [/code] by: [code] btfss SID_SE_OPTION, SE_OPTION_ENV2VOL, BANKED ; (don't clear gate bit if ENV2VOL option enabled) bcf INDF2, 0 ; SID_Vx_CTRL.0 is the gate bit (don't be confused about the operation on the test flag below this line, this will only taken into account if oscillator phase synchronisation is enabled) It works very well. Wouldn't it make sense to provide this modification as a seperate option? Because the oscillator outputs cannot only be damped by using the volume register, but also by using the lowpass filter (which has a higher resolution) Best Regards, Thorsten.