TK.

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.

The collection of problems reported in the last weeks, and the appr. solutions, can now be found here: http://www.ucapps.de/midibox_sid_walkthrough.html This is a living document which will be enhanced in future Please let me know, if an important hint is missing Best Regards, Thorsten.

Did you select the right baudrate for the MIDIbox-to-COM interface? (see http://www.ucapps.de/mios_bootstrap.html) Best Regards, Thorsten.

I just have written a walkthrough which should give you some hints how to get the box running: http://www.ucapps.de/midibox_sid_walkthrough.html My tip: start with the MIOS installation! Best Regards, Thorsten.

+ an integrated coffee machine? ;-) Best Regards, Thorsten.

I just have written a walkthrough which should give you some hints how to get the box running: http://www.ucapps.de/midibox_sid_walkthrough.html Best Regards, Thorsten.

Try the C wrapper, the programming effort will be much lower Best Regards, Thorsten.

thanks! :) to the sequencer ideas: I can only say that such a project is feasible with MIOS, but my focus is currently on other stuff :) Best Regards, Thorsten.

MBCV will support the AOUT_LC interface sooner or later. The hardware is final (PCB layout frozen, no changes planned) Best Regards, Thorsten.

Today I made some performance evaluations. It is not a good idea to load the drum sounds directly from BankStick at the time they should be played, because this leads to a latency of 5 mS. Thats the time which passes to load 42 bytes from a BankStick when other tasks are running in background (the software engine which handles the LFOs and ENVs takes ca. 50% of this time) So, the only way to realize a latency much below 500 uS is to preload the whole Drumkit into RAM - thats the way I will go. The RAM data can be compressed, I hope that at least 20 drum sounds will be loadable at once - this should be enough This leads to the side effect, that a MBSID-D master has no RAM anymore to edit the parameters of a MBSID-D slave in realtime. However, this should also be acceptable. It will still be possible to prepare a drumkit on the master, and to dump it to the slave before the use. Maybe the use of MBSID-D as a CS master is a corner case anyhow - I will still use my common MBSID as master Another point which I noticed and which will affect the sound architecture is the damned SID envelope bug. The VCA envelope of the previous sound can affect the envelope of the new sound (hick ups). One measure to compensate this is to clear the envelope registers when the sound is finished (the required delay could be calculated from the ADSR settings). Another possibility is to clear the registers, to wait some time (I don't know how long), and to play the new sound thereafter... this would increase the latency... however, lets see Best Regards, Thorsten.

I explained you, how this can be realized why do you want to use the MIDI Out of these boxes? Just use the MIDI Out of the MBSEQ The MIDIbox Link port works with TTL level, therefore you can connect multiple MIDI Ins to a single MIDI Out, and in addition you can drive a "common" MIDI In with optocoupler. If more "common" MIDI Ins with optocoupler should be driven, then you need a LTC module in addition Best Regards, Thorsten.

Big Jacks, because my ADC (Hammerfall DSP Multiface) has the same ones Best Regards, Thorsten.

With the C wrapper this shouldn't be that much effort... especially, since you only want to control a host application, where MIDI events could be statically defined (I guess that you don't want to change MIDI events directly on the LCD, when you are also able to edit them in your host sequencer?) Best Regards, Thorsten.

This was nothing personal! I just thought, that a discussion about a feature, which is implemented in the MIOS based "normal" MBSID, but not in the old PIC16F "normal" MBSID, has nothing to do with the MBSID-D And the misleading assumption from your side (in short words: patches don't allow filter changes) could only lead to an even more confusing questions from people, who read this thread and could think, that this is a discussion about MBSID-D Best Regards, Thorsten.

Sidenote: the INs are a nice option, but not really useful. Best Regards, Thorsten.

For a 24LC512 you only need to do some small changes in mbsid_bank.inc - search for "SID_BANK_SetBankStickAddress, and replace this function by SID_BANK_SetBankStickAddress movff EEADR, MIOS_PARAMETER1 ; copy address to low-byte movff SID_PATCH, MIOS_PARAMETER2 ; copy patch to high-byte bcf MIOS_PARAMETER2, 7 btfsc SID_BANK, 0 bsf MIOS_PARAMETER2, 7 clrc rrf SID_BANK, W andlw 0x07 iorlw 0x80 ; (disable verify for faster write accesses) goto MIOS_BANKSTICK_CtrlSet [/code] (I never tried this out...) To the MBFM BankStick effect: this is really strange, I don't know how this can happen. A quick & dirty solution: insert a "return" below the SID_BANK_FormatStick function to prevent this action. Thereafter upload a complete sound bank, thereafter remove the return, so that the BankStick will be formated again, but this time with proper background data Best Regards, Thorsten.

Do you have programming skills to implenent this into the application? I mean: MIOS provides the basics to control multiple displays, but the application itself has to send some useful data to the additional displays... unfortunately, the MB64/MB64E is written in assembler, therefore it's not so easy to extend them if you never programmed PIC assembler before. Alternatively you could implement something similar in C - this isn't so difficult, but examples are rare Best Regards, Thorsten.

Thanks guys! :) Well, I wasn't able to eat that much during my birthday, each time I tried I got a phone call ;-) Best Regards, Thorsten.

Hi, yes, you can use the MIDI Link port, but only in one direction. The MIDI Out of the Sequencer (J11:MO) has to be connected to the MIDI In of MBSID and MBFM (J11:MI) - a proper ground connection is also required of course, and the optocouplers of the MBSID and MBFM core modules have to be removed. This setup will still allow you to access MBSID and MBFM thru the MBSEQ MIDI In (you have to enable the Merger in the MIDI menu) Best Regards, Thorsten.