TK.

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.

Alright, so maybe you forgot to configure the Y offsets in the application? -> http://www.ucapps.de/cmios_fun.html#MIOS_LCD_YAddressSet Best Regards, Thorsten.

FFs are Flip Flops... Seems that I mixed the RGB idea with the LED touch detection. However, here you can use shift registers as well, so long they can be switched into high impedance state (e.g. 74HC595: OE# pin). This will require a second chain of input registers (e.g. 74HC165) - a lot of hardware, but still less expensive than multiple microcontrollers. Also speed is no issue, since the LED capacitance is discharged very slowly (according to the basic example > 1 mS) Best Regards, Thorsten.

Hi Steve, yes, this is a bad idea, because it will add some more digital noise to the 12V voltage domain. Therefore it's better to handle these two domains strictly seperated like you can see in the optimized PSU schematics (there are also some hints in the .pdfs which are worth to read). However, so long no LCD backlight is connected, I guess that the 7805 won't get that hot Best Regards, Thorsten.

The biggest problem is the high power consumption - too much for the Micro, therefore a 4051 (transmission gate) won't help, some FF or SR would be better, and I guess that you can easily service 200 or more multicolour LEDs from a single core with an update rate of less than 1 mS (and I guess that such a high update rate is not really required) Best Regards, Thorsten.

Hi Thomas, yes, everything is correct. You could upload the MBSEQ V2 firmware just to check if you didn't made any error during the software reconfiguration. Best Regards, Thorsten.

There is a hardware reset at MCLR# (PIC Pin 1) which you could try - just tip it to ground. Maybe it would already help to enlarge the reset time by adding a cap (100 nF or higher) against ground, and to increase the resistor value from 100 to 10k Best Regards, Thorsten.

Ikea? Just kidding ;-) Have you already searched in the local Praktiker or Obi store? Best Regards, Thorsten.

From my side it's ok when you open new threads for ebay findings, or when you are discussing about things in this forum which are not related to MIDIbox topics so long it's done in this Misc. section - it can be easily masked out in the search function of this forum, so that the postings don't appear in the result list. Moebius: ok, now we know your oppinion, but please avoid this offensive articulation in future. This should stay a friendly forum, and I guess that you know the netiquette very well, so that I don't need to repeat it! Best Regards, Thorsten.

You can find a circuit in the troubleshooting section which allows you to test the 6N138 without MIDI: http://www.ucapps.de/howto_debug_midi.html (search for mbhp_core_opto_test) The used resistor values of the core circuit are working, you don't need to try other values Best Regards, Thorsten.

MIOS itself only provides a redirection to the IIC MIDI Out, for MIDI In the changes have to be made at the application side, since the MIDI streams have to be merged properly (see MIDI router project). I don't plan to integrate merging of IIC_MIDI streams into MIOS, since depending on the use case different strategies are required - all the variants would unnecessarily blow up the code. This doesn't make much sense: First of all, this would increase the code size of the 1st level bootloader, so that it wouldn't fit into the 1k range anymore. Second: the IIC MIDI In is not so performant like the internal EUSART, the optimized polling method would require an additional IO connection which is not possible with most (main) applications (or I would have to reduce features) Third: there is no (known) bug for the internal EUSART Rx input, therefore it can be used without problems. So: the MIDI Input of the MBHP_IIC_MIDI module will only be used by special applications like the MIDI router project. Best Regards, Thorsten.

It will work without problems, you don't need to change the software settings Best Regards, Thorsten.

in main.asm ; define the display size you are using: ; 0: 2x16 ; 1: 2x20 ; 2: 4x16 ; 3: 4x20 #define DEFAULT_LCD_SIZE 3 [/code] und wahrscheinlich: [code]#if DEFAULT_LCD_SIZE == 3 ; 4x20 #define DEFAULT_YOFFSET_LINE0 0x02 #define DEFAULT_YOFFSET_LINE1 0x42 #define DEFAULT_YOFFSET_LINE2 0x82 #define DEFAULT_YOFFSET_LINE3 0xc2 #define CSMD_YOFFSET_LINE0 0x00 #define CSMD_YOFFSET_LINE1 0x40 #define CSMD_YOFFSET_LINE2 0x80 #define CSMD_YOFFSET_LINE3 0xc0 #endif falls das nicht funktioniert, muesstest Du selbst weitertuefteln (try&error) Gruss, Thorsten.

Hi Michael, yes, there is a better method: don't use a lookup table, but just calculate the address directly, it's: (unsigned int)patch << 6 In addition, you could organize the data structure in RAM in the same way like it should be stored in BankStick. By doing so, you can use the MIOS_BANKSTICK_WritePage function in order to store the whole patch at once (a page consists of 64/0x40 bytes). The advantage of a page write operation is, that it takes appr. the same time like writing a single byte (see 24LC256 datasheet for the timings, so far I remember it was appr. 4 mS) - so, at the end a page write works 64 times faster! Best Regards, Thorsten.

tippe in der Suchfunktion "kx driver update" - mehr Details sind nicht bekannt. Gruss, Thorsten.

Fein :) Koenntest Du bitte Michael ueber dieses Problem informieren? Es besteht die Gefahr, dass noch mehr fehlerhafte Boards rausgehen (wenn es nicht bereits geschehen ist... :-/) Gruss, Thorsten.

How did you connect the PSU? Best Regards, Thorsten.