TK.

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.

Hi Jess, beside of the new chip, no additional hardware changes are planned. Just only extensions (like controlling a second MBHP_SID board from a single core). I've read your proposals, they are good and I have to think about how to combine them with the other ideas and requirements. Once I've a clear picture, I will enhance the wishlist To point 5: this is already possible by enabling the "E2P" sound engine option (CC#111 = 0x04), and by synchronising envelopes to the MIDI clock (CC#125 = 0x04) The sound engine option is an immediate solution to keep the MBSID V1 engine compatible, with the overworked MBSID V2 engine(s) such special features should be considered from the beginning, and therefore it will be easier to find them Best Regards, Thorsten.

Hi Jess, welcome aboard, I'm very glad to hear from you after so long time! Just two weeks ago I highlighted again the importance of the curve parameter (with an explicit hint of the originator of this algorithm -> http://www.ucapps.de/howto_sid_bassline.html) :-) Current situation: MBSID V1 will only get minor changes in future due to various reasons, e.g. code and patch memory allocation. But with MBSID V2 all concepts will be overworked (see MBSID Wishlist posting, which you've already discovered - more about this topic there) - which means: than more ideas are discussed now, than better the chance to get this into the next major redesign. So, you are joining this forum just in time! :) My thoughts on your proposals: yes, a dedicated envelope with analog output would be the best solution for MBSID V2. Currently it would only be possible to introduce a new "sound engine option" (4 bits are still free) in order to enable a path from a selected envelope (e.g. ENV2) to the volume register, or to an analog output (-> MBHP_AOUT_LC module). Modulation of the volume register could already be tried out with a small number of lines. I will try it this evening just to get a feeling about the benefit and post the required code here. Note that the resolution is 4 and not 8 bit, however, we will see.. But as you already mentioned, an external VCA would be the best solution - especially if it has a log characteristic (to match with the dB damping and to decrease the required resolution). Here you can find a schematic for this concept http://www.midibox.org/users/kd/kd_fmsid.pdf but nobody tried it out so far. To the filter calibration: so far I understand your suggestion, this would only require a linear scaling routine, and not a table (which would consume too much memory). Thanks to the hardware multiplier, it shouldn't consume so much execution cycles (see math_mul16_16.inc), I will give it a try, but would need the help from some people who own different SIDs Best Regards, Thorsten.