TK.

Unfortunately I'm not able to release a complete MBSID-D yet, since the reprogramming of the control surface is much more effort than expected - the whole engine is programmed on a different way now, and this requires conceptional changes in the CS handling. However, on the other hand the engine itself works pretty well, therefore I've uploaded a prebuilt alpha version (binary only) which should give you the chance to optimize your drum patches, and to combine them to complete drumkits: http://www.ucapps.de/mios/mbsid-d_alpha1.zip This package also includes the drumpatches which I've received so far from Kokoon, Rio and Illogik. Plus my own drumkit which contains some Hubbard-like drums Here a short preview: http://www.midibox.org/midibox_sid/mbsid-d_demo2.mp3 As "alpha1" should indicate, the firmware is definietly not final. Editing patches is currently a little bit tricky: you can play the currently edited patch with MIDI Note C-2 of Drumkit 1. Once the patch is finished, you can upload it to the final patch location with Right Click->Store The patches are assigned to Note C-2 ... G#3 (21 drum patches) Each bank contains 6 drumkits, they can be selected with CC#0 (and not with Program Change yet, since this interfes with the JSynthLib "Play Patch" function) - as a final solution, I propably have to create a Drum specific JSynthLib module... However, hope that you have the same fun with this release like me - I'm going to create much more drum sounds today :) Best Regards, Thorsten.

Hm.... which voltages do you read exactly? I mean, sometimes people measure 13.9V, and then they think that this could be a problem... but it's just within the allowed tolerance. If the core gets a voltage much lower than 5V if the SID module is connected as well (lets say 4V or even lower), then there must be a short circuit on the SID board. Check it visually, sometimes small solder clumbs can cause such an effect. Remove also ALL ICs when doing such checks, thats very important! First try to get the Core module running like described in the SID Walkthrough. Once it works, you know, that the problem cannot be located at there. Best Regards, Thorsten.

Are you using the PSU of an "old" C64 (which contains the 6581), or of a C64II (which contains the 8580)? Best Regards, Thorsten.

Hi Robin, you could save the last pin number in an additional global variable (just call it 'unsigned char last_pin;') Alternatively you could declare the variable within the function, and make it static ('static unsigned char last_pin;') - static variables don't loose their value when the function is called again, and the variable name is only in the scope of this function, which means, that you can use simple names without the danger for conflicts with other global variables. Thats perfect, I wouldn't do it on a different way This leads only to additional execution time (due to the if condition), and to larger code. Something that isn't clear to me is the relation between the XOR toggle and the subject "Radio group button behaviour". So long you only want to set a certain pin, and clear the others, then I would suggest following solution: unsigned char group1_selected; void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { unsigned char i; // DIN 16..31 is one "radio group" if( pin >= 16 && pin <= 31 ) { // save the selected button function of the group group1_selected = pin - 16; // the LEDs of this group are connected to DOUT Pin 0..15, clear them for(i=0; i<=15; ++i) MIOS_DOUT_PinSet0(i); // set the LED which is related to the selected function MIOS_DOUT_PinSet1(group1_selected); } else { // this branch handles DIN 0..15 and DIN 32..127 } } [/code] So, as you can see, for a group of LEDs, where only one lits, you don't need to store the information in an array, you only need to store a reference to the selected function Best Regards, Thorsten.

Hi Robin, no, you don't need an "int" for a for statement, "char" or "unsigned char" will work ok, and they are much faster anyhow (16bit always produces additional code, which is mostly not required) So, I guess that your main question is, how to store the last state of a button or LED. You can do this in the same way like described here: http://www.midibox.org/forum/index.php?topic=5662.0 Only difference is, that you don't toggle the array entry, but just set or clear it Best Regards, Thorsten.

mainly it's intented for MIDIbox users, but of course, you can also ask general questions. In this case it's just useful to know, that you are not using a MIDIbox (in this case I would at least know, that it wouldn't be a software problem ;-)) So, I guess that you are having two main issues. Software issue: you have to eliminate the 1/2 bit LSB error of the ADC. The easiest way is to propagate value changes only, when the difference between the last, and the new sample is higher than a certain value. By doing so, you will create some kind of deadband, in between changes are not sent (in MIOS this feature is configured with MIOS_AIN_DeadbandSet). Then higher the jitter, then higher the required deadband. A deadband will reduce the resolution, but for common MIDI values (which are 7bit) this doesn't matter anyhow. Hardware issue: do you have a schematic of your circuit? Best Regards, Thorsten.

By using SID_CCIn you are sending the parameter change directly to the sound engine of the master core, but not to the control surface (which runs in parallel to the sound engine). Therefore this method doesn't allow you to forward changes to the slaves. This could be realized in different ways, but all solutions lead to side effects, which are propably not wanted. Solution 1: send the same CC#s over the MIDI interface (-> MIOS_MIDI_TxBufferPut). Disadvantage: if slaves are assigned to the same channel, they will update the parameters at the same time Solution 2: send parameter changes via SysEx (see the SysEx implementation chart) Solution 3: don't use SID_CCIn, but forward joystick movements to the CS_MENU_MS_SendParameter function (not selfexplaining usage, bad documented). In this case, the SID has to be selected in the CS_MENU_SID variable Solution 4: use the same approach like CS_MENU_ENC_CS_Change_Menu, so that a joystick is handled in the same way like an encoder Best Regards, Thorsten.

Btw.: I will update the MBHP_SID page soon - references to the onboard-oscillator will be removed (especially in the schematic), interconnection diagrams will be changed, SmashTV will create a new PCB But to say it clearly: there is no reason for throwing away an old PCB, if you already own one (or more) - just don't stuff the oscillator, and clock the SID from the core module instead like already described at the MBHP_SID page. Best Regards, Thorsten.

The overload flag is parsed in lc_mproc.inc, function LC_MPROC_Received_D0 (read the comments there) This routine copies the flag to METER_LEVEL_BEGIN + (meter number), bit number 7 The LC_METERS_PatternSet routine in lc_meters.inc checks for this flag and copies it to the bit position of the 12th LED 16 bits, because the application allows you to control up to 16 LEDs per meter. However, since the host application only transfers 13 levels, and since my own MBLC has only 11 meter leds + one overload LED (when the meter values are displayed with the V-Pot LED-Rings), the remaining bits are 0. 16 entries: this is directly related to the maximum number of LEDs and levels. The intention was, that this allows other people to change the patterns easily without asking me, how do do this exactly. ;-) Hint: change the pattern temporary and watch for the effect. I think that this explains more than 1000 words! Best Regards, Thorsten.

ACCEPTED

Hi, are you really talking about a MIDIbox based project? Best Regards, Thorsten.

It's possible with the hardware, MIOS and parts of the existing MBSEQ application, but such a usecase has never been considered, therefore a lot of code modifications will be required. Best Regards, Thorsten.

there are eight inputs - when you are using the last two inputs, the first 6 can still be used for the LFOs. Best Regards, Thorsten.

thats exactly the intention (only a small number of people don't like this ;-) no, the slave doesn't need this change. Best Regards, Thorsten.

Just look at the end of the file, there is the pattern table (maybe it's so simple, that you've overseen this ;-) Best Regards, Thorsten.

I just have created the board http://www.midibox.org/forum/index.php?board=32.0 and will lock this thread to avoid those endless discussions Best Regards, Thorsten.

This board has been created for official "sale requests". Here you can ask for an official permission, if you are planning to produce and sell a project which gets use of the MIDIbox Hardware Platform and/or MIOS. NOTE: you don't need to ask for permission for one-time sales, because this is covered by the TAPR license http://www.ucapps.de/TAPR_Noncommercial_Hardware_License_v1.0.pdf - which allows to sell up to 10 devices per year without a special arrangement. -> just offer your MIDIbox directly at the Fleamarket in such cases. Regardless of the legal position concerning copyrights in your country, only with my permission you can have a good feeling about what you are doing, and only with a published request in this forum you can be sure that the MIDIbox community will accept your intention. I will accept or deny your request without mentioning the reasons to avoid endless discussions, which steal my time even more than just providing this solution! Possible states of your request are: ACCEPTED (you have my permission) DENIED (you don't have my permission) PENDING <reason> (you have to clarify something due to given reason) Projects which I want to support are: innovative projects good documented projects, which allow other people to do the same major improvements of the MBHP solutions, which really help the community (e.g. PCB manufacturing) Projects which I will deny are: [*]1:1 copies of www.uCApps.de projects with no benefit for the community [*]bad or not documented projects [*]overpriced projects [*]projects which have been detected by the community as MBHP-based, but which never got my permission Best Regards, Thorsten.

The LED meters are directly controlled from your host application, therefore "calibration" must be done there. Also the latency is an issue at the host side, MBLC controls the meters once the appr. MIDI events arive, normaly within less than 1 mS (especially USB interfaces have mostly a latency of more than 3..10 mS + an additional jitter) The meter levels are decremented according to the Logic Control Spec (300 mS each LED). You can tune this value by changing the delay counter in lc_leds.inc, search for "15", replace it by a higher number (up to 255) Best Regards, Thorsten.

Kokoon: these are great news! :) Illogik: the intention behind the on-board oscillator was to have a backup solution for the case that pin RC2 of the PIC has to be used for something else. Another advantage is (or better was...), that the SID module could be accessed by other micros (or PCs) without the need for a clock generator (which is not easy to realize, especially with a PC) So, the oscillator was never really required... Today I made some experiments with SID bus transfer synchronization - since I'm not sure if the proposed solution works properly in all cases (e.g. independent from cable impedance and ambient temperatur), I've modified the SID bus driver in sid_sr.inc, so that it takes care for the falling clock edge, at which the data will be taken. Here a diagram (for people who are still interested...) This old code in sid_sr.inc: ;; initiate a write and wait for 1.4 us (> one clock cycle) bcf SID_SR_LAT_WR, SID_SR_PIN_WR movlw 0x03 clrf MIOS_PARAMETER3 SID_SR_WriteLoop3 incf MIOS_PARAMETER3, F IFNEQ MIOS_PARAMETER3, ACCESS, rgoto SID_SR_WriteLoop3 bsf SID_SR_LAT_WR, SID_SR_PIN_WR [/code] has been replaced by: [code] ;; synchronize with rising edge of SID clock to avoid setup or hold violation ;; note: due to pipeline effects, the "bcf" will be executed 3 instruction cycles after ;; the polling loop. Therefore we are waiting for the falling edge IFCLR PORTC, 2, bra $-2 ; wait for falling clock edge IFSET PORTC, 2, bra $-2 bcf SID_SR_LAT_WR, SID_SR_PIN_WR ; enable write (MBHP_SID: chip select) bra $+2 ; to ensure compatibility with on-board oscillator, bra $+2 ; wait for 1.2 uS (> one SID clock cycle) bra $+2 bra $+2 bra $+2 bra $+2 bsf SID_SR_LAT_WR, SID_SR_PIN_WR ; disable write (MBHP_SID: chip select) Now it looks perfectly at the scope! Now the practice test starts - if I don't notice failures anymore, I will publish the required changes (and the updated firmwares) at my website Best Regards, Thorsten.

fingers crossed! Best Regards, Thorsten.

yes, please! Yes, I'm doing this very often. It has the advantage is, that it doesn't matter, how long the note is played, and that the sound stops with a specific tone. Don't think so much about the integration of filters. Just do the sounds - if the combination of specific sounds results into strange effects, people are always able to use them on a second SID, or to record them seperately. Focus should be to have a large variety of sounds (therefore I'm asking for help) Btw.: Rio has also sent me some patches in the meantime Thats the normal behaviour of the sustain level. Once it has been lowered, you can only make it higher by retriggering the gate. So, the SID VCA has (unfortunately) not the same behaviour like the software implemented EG. And it especially has a bug (the famous SID ADSR bug) - the attack is sometimes delayed and "hicks up", especially on high release values. Best Regards, Thorsten.

Hallo, nachdem ich auf das leidige EUSART Problem gestossen bin, habe ich die Weiterentwicklung der Firmware nicht mehr weiterverfolgt. Der Code befindet sich also in einem ziemlich wuesten Status - im Wesentlichen setzt er auf das CDC Beispiel auf, welches sich nur mit dem C18 kompilieren laesst (bin zunaechst davon ausgegangen, dass ich das Limit von drei Monaten locker einhalten kann, im Endeffekt haette das Modul nach einem Tag laufen koennen...). Ausserdem enthaelt er den MIDI Parser aus dem urspruenglichen MBHP_USB Projekt Ich koennte Dir die Files zuschicken, doch ich weiss nicht, was daran noch funktioniert, und was "kaputtgedebuged" wurde (zunaechst bin ich von einem Problem mit den Interrupts ausgegangen...) Gruss, Thorsten.

Hi Kokoon, thank you for the patches - there are really nice ones! :) To the random gate triggers: I just have splitted the topic, since this could become a large new thread ;-) http://www.midibox.org/forum/index.php?topic=5748.0 Best Regards, Thorsten.

Hi Kokoon, thank you for the patches - there are really nice ones! :) But to a more important topic: ARGH!!! I also noticed this with your patches, and to say it short: it's not a software, but a design bug! Fortunately it can be easily fixed. To make it short: the SID is clocked asynchronously to the PIC. Depending on the clock phase between the SID and the PIC, a setup or hold violation can happen at the chip select line if the bus access is done at the "wrong moment" (rising edge on both clocks at the same time). It seems that this effect can only be noticed with the voice control register, which sets the waveform, sync, ringmod and the gate. Statistically it happens very seldom, but if the voice control register is written with a very high frequency (e.g. 1.2kHz), it happens each 2..5 seconds (so after each 2500...6000th access) - and then it's really "noticable" But fortunately there is cure: clocking the SID synchronous to the PIC. And this can be easily done by removing the oscillator, and by connecting the CLK pin of the SID (pin #6), with the 1MHz clock output of the CORE module (RC2, Pin #17, available at J7:SO - the middle pin) Could you please try this? If you notice the same like me (no random gate triggers anymore), then you've uncovered one of the biggest bugs this year (even bigger than missing bypass caps ;-) Here also an explanation why I haven't noticed this yet - I'm sure that I made some tests with asynchronous bus accesses years ago with the PIC16F877 based MIDIbox SID. A very easy check is just to write to the SID registers permanently - it worked. Now I did the same test with the PIC18F452, and it fails very often! (Test can be done by removing the "rgoto SID_SR_Next" instruction in sid_sr.inc). The main difference between both chips which could lead to such effects is 1) that the PIC18F452 is clocked 2 times faster, and that 2) the PIC18F452 works with an internal PLL, which delivers a more unstable frequency. Therefore the propability that the violation happens is much higher. So, I hope that the proposed solution works in all cases. If not, the PIC clock could be delayed by a R-C pair. If this also doesn't help, then I'm in trouble ;-) Best Regards, Thorsten.

Great intro - thanks and *zapp* sticky! Best Regards, Thorsten.