TK.

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.

Alright, so the first release candidate can be downloaded from here: http://www.ucapps.de/mios/midibox_sid_v1_7303b_rc1.zip The ENV2->Volume modulation path has to be enabled with the 4th flag of the sound engine option. This can be made from JSynthLib, from the control surface (SEO menu) or via CC (CC#111 = 0x08) For filter calibration you have to select the appr. type in .asm (e.g. in main.asm or setup_*.asm) ;; select the filter type here: ;; 0: if a 6581 is controlled from the core ;; 1: if a 8580 is controlled from the core ;; 2: 6581 + freely definable scaling (define MIN and MAX value below) ;; 3: 8580 + freely definable scaling (define MIN and MAX value below) #define DEFAULT_FILTER_TYPE 1 ;; only relevant if DEFAULT_FILTER_TYPE is 2 or 3, values between 0 and 2047 are allowed #define DEFAULT_FILTER_CALI_MIN 20 #define DEFAULT_FILTER_CALI_MAX 500 ;; set this if you want to switch between two different Min/Max values ;; (works only with DEFAULT_FILTER_TYPE 2 or 3) #define DEFAULT_FILTER_CALI_SWITCH 0 ;; and define the used pin here (default: pin RC.3) #define DEFAULT_FILTER_CALI_SWITCH_TRIS TRISC #define DEFAULT_FILTER_CALI_SWITCH_PORT PORTC #define DEFAULT_FILTER_CALI_SWITCH_PIN 3 ;; define the second set of Min/Max values here (0..2047) #define DEFAULT_FILTER_CALI_MIN2 0 #define DEFAULT_FILTER_CALI_MAX2 2047 [/code] Sidenote: the difference between 0/1 and 2/3 is, that the 8580 selection delinearizes the control curve of the filter by mapping the value through the frequency table - this was also a suggestion made by Jess some months ago... Best Regards, Thorsten.

Hi Jess, short info (I'm hacking the new features into the firmware in parallel ;-) -> CC#116 (Filter Key Tracking) :) Thanks! :) I not always have the time for trying things out immediately... however, in difference to others you are making feasible suggestions and don't demand for unsolvable things (or putting requests like "Synth A and B has this, why not MIDIbox SID?") Yes! Btw.: my current implementation requires static values defined in main.asm, you need to upload a new firmware built in order to try out the changes - it would be too difficult (as fast solution) to allow a calibration via SysEx or control surface. But I could consider this for MBSID V2 (I see the need) Best Regards, Thorsten. P.S.: just uploaded the change - it works. I'm writing the changelog now ;-)

yes! A second SID module just requires an additional "chip select" connection, J14 of the core module is reserved for this. this will also be possible, and in fact so long you can accept that both SIDs are controlled with the same parameters, you can already do this. Just connect both MBHP_SIDs in parallel. By enabling the CBM8580_FILTER_SWITCH in main.asm, you can dynamically switch between two filter scalings with a jumper (or switch) I'm just extending this for the new filter type #2: defined min/max values. After this change, you can calibrate both SIDs, and switch between the two min/max values. With MBSID V2, you only need to solder the CS line of the second SID to J14 of the core module in order to control the SIDs seperately MIDIbox FM provides up to 4 audio outputs. It won't be possible to run two different sound engines, this would load the system too much and it would also make the menu handling too complicated. My idea is to provide a second SID only as extension and stereo option. If different sound engines should be used at the same time (e.g. bassline and drum), one or more additional cores will be required. Everything else will blow up the complexity too much But if you mean with different sound engines, just a second modulation matrix for a lot of parameters - yes, this is planned. In MBSID V1 you can declare different keyboard split zones in order to control the oscillators independently over one MIDI channel over different keyboard ranges. It's also possible to define different channels, but this requires you to send SysEx strings for a reconfiguration (too complicated). So, even the ring oscillator effects can already be realized (the easiest way to define the zones is using the Control Surface, or JSYnthLib) MBSID V2 will provide a "Multi" engine for things exactly described above :) Best Regards, Thorsten.

I just have integrated the new sound engine option "E2V" (ENV2 to Volume) - works better than expected! I will try the filter calibration now (I noticed that I already did something similar for the 8580, but with a static scaling), and release a new built in ca. 1 hour :) Best Regards, Thorsten.

Wenn die 5V Spannungsquelle genuegend Strom liefert, dann kann man damit auch das Backlight eines LEDs betreiben. Gruss, Thorsten.

Hallo, die meisten Applikationen sollten damit zurecht kommen, die obere Haelfte der Baenke/Patches wird dann gespiegelt sein Gruss, Thorsten.

Yes have to set bit #7 in the Y2 and Y3 offset (-> MIOS_LCD_YAddressSet), otherwise the second LCD won't be initialised. I think that this makes your other question obsolete :) Best Regards, Thorsten.