TK.

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.

Great! :) you can use the change_id application in order to switch to the to-COM port permanently (see main.asm header) But take care! Once the baudrate has been changed, you will only be able to switch back with a proper COM connection. If you are not able to get the Yamaha or Roland driver running, then you are lost Alternatively you could switch temporary to the to-COM baudrate with MIOS Studio: open the debug window, select the "MIOS_MIDI_InterfaceSet" function and send a 1 (WREG=1) - now the MIDI interface will run with 38400 baud until the core is powered-off Best Regards, Thorsten.

Hi Knas, maybe it's related to the buffer size of your endpoints? Here the descriptors that I used for the PIC18F4550 (it's written for the C18 compiler) /* Device Descriptor */ rom USB_DEV_DSC device_dsc= { sizeof(USB_DEV_DSC), // Size of this descriptor in bytes DSC_DEV, // DEVICE descriptor type 0x0200, // USB Spec Release Number in BCD format CDC_DEVICE, // Class Code 0x00, // Subclass code 0x00, // Protocol code EP0_BUFF_SIZE, // Max packet size for EP0, see usbcfg.h 0x16C0, // Vendor ID --- sponsored by voti.nl! see http://www.voti.nl/pids 1020, // Product ID: CDC RS-232 Emulation Demo 0x0000, // Device release number in BCD format 0x01, // Manufacturer string index 0x02, // Product string index 0x00, // Device serial number string index 0x01 // Number of possible configurations }; /* Configuration 1 Descriptor */ CFG01= { /* Configuration Descriptor */ 9, // Size of this descriptor in bytes 0x02, // CONFIGURATION descriptor type 9+ 9+9 +9+7+ 6+6+ 9+9+ 9+5+9+5, 0x00, // Total length of data for this cfg 0x02, // Number of interfaces in this cfg 0x01, // Interface number 0x00, // Configuration string index 0x80, // Attributes, see usbdefs_std_dsc.h 50, // Max power consumption (2X mA) /* Descriptor of Audio Control Interface */ 9, // Size of this descriptor in bytes 0x04, // INTERFACE descriptor type 0x00, // Interface Number 0x00, // Alternate Setting Number 0x00, // Number of endpoints in this intf 0x01, // Class code (AUDIO) 0x01, // Sub Class (AUDIO_CONTROL) 0x00, // Sub Sub Class 0x00, // Interface string index /* Class Specific Audio Control Interface Descriptor */ 9, // Size of this descriptor in bytes 0x24, // descriptor type 0x01, // Header subtype 0x00, 0x01, // Revision of class specification - 1.0 9, 0x00, // total size of class-specific descriptors 0x01, // number of streaming interfaces 0x01, // MIDI Streaming Interface 1 belongs to this AudioControl Interface /* Descriptor of MIDI Stream Interface */ 9, // Size of this descriptor in bytes 0x04, // INTERFACE descriptor type 0x01, // Interface Number 0x00, // Alternate Setting Number 0x02, // Number of endpoints in this intf 0x01, // Class code (AUDIO) 0x03, // Sub Class (MIDISTREAMING) 0x00, // Sub Sub Class 0x00, // Interface string index /* Class Specific MIDI Stream Interface Descriptor */ 7, // Size of this descriptor in bytes 0x24, // descriptor type 0x01, // Header subtype 0x00, 0x01, // Revision of class specification - 1.0 7+ 6+6+ 9+9+ 9+5+9+5,0x00, // total size of class-specific descriptors /* MIDI In Descriptor (Embedded) */ 6, // Size of this descriptor in bytes 0x24, // descriptor type 0x02, // MIDI_IN_JACK subtype 0x01, // EMBEDDED 0x01, // ID of this jack 0x00, // unused /* MIDI In Descriptor (External) */ 6, // Size of this descriptor in bytes 0x24, // descriptor type 0x02, // MIDI_IN_JACK subtype 0x02, // EXTERNAL 0x02, // ID of this jack 0x00, // unused /* MIDI Out Descriptor (Embedded) */ 9, // Size of this descriptor in bytes 0x24, // descriptor type 0x03, // MIDI_OUT_JACK subtype 0x01, // EMBEDDED 0x03, // ID of this jack 0x01, // number of input pins of this jack 0x02, // ID of the entity to which this pin is connected 0x01, // Output Pin number of the entity to which this input pin is connected 0x00, // unused /* MIDI Out Descriptor (External) */ 9, // Size of this descriptor in bytes 0x24, // descriptor type 0x03, // MIDI_OUT_JACK subtype 0x02, // EXTERNAL 0x04, // ID of this jack 0x01, // number of input pins of this jack 0x01, // ID of the entity to which this pin is connected 0x01, // Output Pin number of the entity to which this input pin is connected 0x00, // unused /* EP2 Out */ 9, // Size of this descriptor in bytes 0x05, // descriptor type (ENDPOINT) 0x01, // Out Endpoint 1 0x02, // Bulk, not shared 0x40, 0x00, // 64 bytes per packet 0x00, // ignore for bulk 0x00, // unused 0x00, // unused 5, // Size of this descriptor in bytes 0x25, // descriptor type (CS_ENDPOINT) 0x01, // MS_GENERAL 0x01, // number of embedded MIDI INs 0x01, // ID of embedded MIDI In Jack /* EP2 In */ 9, // Size of this descriptor in bytes 0x05, // descriptor type (ENDPOINT) 0x81, // In Endpoint 1 0x02, // Bulk, not shared 0x40, 0x00, // 64 bytes per packet 0x00, // ignore for bulk 0x00, // unused 0x00, // unused 5, // Size of this descriptor in bytes 0x25, // descriptor type (CS_ENDPOINT) 0x01, // MS_GENERAL 0x01, // number of embedded MIDI OUTs 0x03, // ID of embedded MIDI Out Jack }; rom struct{byte bLength;byte bDscType;word string[1];}sd000={ sizeof(sd000),DSC_STR,0x0409}; rom struct{byte bLength;byte bDscType;word string[25];}sd001={ sizeof(sd001),DSC_STR, 'T','h','o','r','s','t','e','n',' ','K','l','o','s','e', ' ',' ',' ',' ',' ',' ',' ',' ',' ',' '}; rom struct{byte bLength;byte bDscType;word string[25];}sd002={ sizeof(sd002),DSC_STR, 'M','B','H','P',' ','U','S','B',' ','P','I','C', 'E','m','u','l','a','t','i','o','n',' ','D',' '}; [/code] Best Regards, Thorsten.

A (very) short demo with a high-pitched BD, snare and hihats: http://www.midibox.org/midibox_sid/mbsid-d_demo1.mp3 Best Regards, Thorsten.

thanks for your input! :) definitely yes! I think the best handling is to change the behaviour of the buttons within the WT menu. In this menu, Note/Accent/Slide could select the wavetable track, and with the 16 step buttons + the 1-16/17-32 buttons you could select the step which should be edited. With the rotary encoder the value could be changed In TB303 mode, two tracks are allocated by the TB303 sequencer, the third is free for use. I think that it's ok when the user changes to the WT menu if this track should be edited. Or I could add another LED at the left side. Not sure... I think it's enough when this can be done directly at the menu interface. Because I don't know, which key combination would be easier to define a jump point, instead of selecting it directly in the WT menu The control handling will be optimized for usage with an encoder. If a "+++" should be played, then just move the encoder to the left until you reach the lowest value ("---"). Then one up - thats the "+++" I've implemented a step-edit mode in MBSEQ, but I must say that I never really used it. I'm not sure, if it is my personal preference for fast editing with the rotary encoder, or if I'm doing anything different... *grin* good idea ;-) Best Regards, Thorsten.

These messages are the upload requests of the bootstrap loader, which are sent with the wrong baudrate, and therefore result into different MIDI events. If no MIDI interface is available, you could try it with a gameport (see MIDI Troubleshooting guide for schematic) Best Regards, Thorsten.

Have you ever tried the WT examples in the preset library? Eg, "WT Synth Drum 11" is a pretty nice snare drum - I'm especially searching for improved versions of these WT sounds, and for additional C64 typical special sounds LFO frequency: see bottom of http://www.ucapps.de/midibox_sid/sid_cc_implementation_chart.txt Wt frequency goes up to 1.2 kHz (rate=127) Filter: see CC#44 in the table above! It doesn't pop so long you are playing the sound which gets use of the filter very often. Thats difficult to describe for somebody who isn't that much into the MBFM voice allocation algorithm, let's try it: first the algorithm searches for a voice which was assigned to the same instrument like the new one. If such a voice/instrument combination is available, the appr. voice will be taken -> no filter crackle. If it was not found, it takes the first voice slot of the "voice queue", normaly the voice which wasn't used the longest time. If this voice was also assigned to a filter -> evtl. filter crackle. If all three voices are allocated, the this "longest" note will be dropped... replaced by the new one. -> evtl. filter crackle. So, it depends on type of drum patches which are combined, on the frequency of use, and on the style which should be played (maybe the sounds are so loud, that the popping filter is not regognized?) I already thought about instrument groups (especially for HiHats, see above), maybe an additional feature could be the possibility to assign the group to a special voice in order to avoid that the filter is switched on/off. The implementation is a piece of cake, but I fear that the usage gets too complicated for most people... :-/ Do you know a more simple solution? Best Regards, Thorsten. P.S.: to avoid that somebody gets it wrong: this algorithm works great with MBFM, no crackling sounds can be regognized when voices are assigned to different instruments. The "crackle" problem is a SID specific problem, since it only provides one filter for all three oscillators. In other words: this is a resource which has to be shared.

The application is ready, but I haven't received any drum sounds so far - come on, guys! ;-) Best Regards, Thorsten.