TK.

No, it isn't possible to group buttons with encoders in the firmware, and using meta events will make it even more complicated (especially because there isn't enough memory free to add such functions) It's better to write a new application dedicated for your purposes. In principle it's very easy to realize for somebody with programming skills. I've seen many requests in the last years for such an organisation of a MIDI controller, only question is: who would like to do the implementation? Best Regards, Thorsten.

Today I got the possibility to check the new CV options with the rsf Kobol expanders of Francois (username "Polykobol"): The MBSID controlled filter cutoff and oscillator frequency of only two expanders via Seppoman's AOUT_NG module. The gates are directly connected to J5 of the core. We only used two expanders, as it already was a lot of fun (ok, and I had no MPASM ready to recompile the firmware for different routings ;-)) And here the results of the session: Experiments with Stereo Modulation (8 MB!) Only for synth freaks with some endurance! LP Filter and Pitch of two Kobols are modulated through the mod matrix with multiple LFOs, combined with different operators. LFO settings are tweaked during the sound is playing. Only a single note is played! The random-like "tunes" are result of the modulation (in fact, the gate was not connected this time) I especially like the brass-like sound at 4:22 :) Stereo Bass (1.4 MB) Just to check the detune function and simple stereo effects :) Arpeggiator (1.2 MB) Nice arpeggiator sequence (just push the button and play a single note) Bassline Fun (3.6 MB) Bassline sequences. Note the killer bass of the lower bassline! :) I would like to highlight, that the AOUT_NG module works great with this gear! No need to be worried about the slightly worse specs compared to MAX525, I haven't noticed anything negative - in distance, I was surprised that there is absolutely ZERO zipper noise and perfectly matching VCO frequencies! :) Best Regards, Thorsten.

Yes, thats correct. It's the PICstart issue, the programmer doesn't write the correct ID (all-zero in normal case) The workaround is described under the TEST_SW2 topic of this page: http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

Hi Lee, see this page: http://www.ucapps.de/midibox_sid_manual_up.html The stereo option is strongly recommented - you will love it! :) Not only that you can play stereo sounds, it also allows you to play two basslines per core, or 6 drum instruments the same time, or 6 voice polyphonic sounds Best Regards, Thorsten.

I will give you a general answer in the hope that it helps to improve the understanding, how Meta events are working. Whenever you define an event which starts with F (F0, F1, F2, ... FF) - regardless if you are using mk_syx or vmidibox, the button and pot movement will cause the MB64_META_Handler for beeing called. This handler gets following parameters: ;; on pot events (entry point: MB64_META_Handler_Pot): ;; o Pot number in MB64_CURRENT_POT (BANKED access required!) ;; o first MIDI byte in MIDI_EVNT0 (no BANKED access required) ;; o second MIDI byte in MIDI_EVNT1 (no BANKED access required) ;; o pot value in MIDI_EVNT_VALUE (no BANKED access required) ;; ;; on button events (entry point: MB64_META_Handler_Button): ;; o Pot number in MB64_CURRENT_BUTTON (BANKED access required!) ;; o first MIDI byte in MIDI_EVNT0 (no BANKED access required) ;; o second MIDI byte in MIDI_EVNT1 (no BANKED access required) ;; o button value in MIDI_EVNT_VALUE (no BANKED access required) [/code] MIDI_EVNT0 and MIDI_EVNT1 are the values which have been defined in vmidibox/mk_syx MIDI_EVNT_VALUE is the variable pot value, or the button state (depressed: 0, pressed: third byte of button event) So, now you can do with these values whatever you want :) For example, if it is sufficient to differ a single byte within the SysEx string, just add the sending routine directly below "MB64_META_Handler_Pot", and replace a "movlw 0x.." by "movf MIDI_EVNT1, W" at the position which requires a variable value. Now you can control this "placeholder" value from your your mk_syx/vmidibox setup It's very similar for the pot value - replace a "movlw 0x.." by "movf MIDI_EVNT_VALUE, W" to send it. Differing between different strings (e.g. 9 and 10 byte string): you could select it with the rightmost digit of MIDI_EVNT0, so that "F0" sends a 9-byte string, and "F1" a 10-byte string. Example for a simple two-way branch: [code] MB64_META_Handler movf MIDI_EVNT0, W xorlw 0xf1 ; F1 received? bz MB64_META_Handler_F1 MB64_META_Handler_F0 ;; send 9 bytes... call MIOS_MIDI_BeginStream ; begin stream movlw 0xf0 ; send 0xf0 call MIOS_MIDI_TxBufferPut movlw 0x43 ; send 0x43 call MIOS_MIDI_TxBufferPut movlw 0x10 ; send 0x10 call MIOS_MIDI_TxBufferPut movlw 0x4c ; send 0x4c changed to my Instrument (PSR 3000) call MIOS_MIDI_TxBufferPut movlw 0x10 ; send 0x10 call MIOS_MIDI_TxBufferPut movlw 0x00 ; send 0x00 movf MIDI_EVNT1, W ; send 2nd byte of pot event call MIOS_MIDI_TxBufferPut movf MIDI_EVNT_VALUE, W ; send pot/button value call MIOS_MIDI_TxBufferPut call MIOS_MIDI_EndStream ; end stream ;; ...and exit return MB64_META_Handler_F1 ;; send 10 bytes... ;; ... ;; ...and exit return Btw.: remove the jumptable stuff below the handler label, I guess that it only confuses you. Best Regards, Thorsten.

Hi Steve, thanks for this useful tip! :) Would it be possible to get a copy of your firmware (binary is sufficient) - as I wrote in this posting http://www.midibox.org/forum/index.php?topic=10447.msg79114#msg79114 I noticed a new issue - three different firmwares are failing under Mac OS. The strange thing: the Cypress based MBHP_USB firmware is running fine, so that a Mac specific driver issue can be excluded. Best Regards, Thorsten.

This topic pops up regulary, but I can only say: in distance to other people, I'm not willing to release a buggy solution. MIDI-Nator: was affected by the EUSART bug as well, this has been confirmed by Robert. Meanwhile the silicon issue has been fixed by Microchip, and if you've luck, you will be able to purchase a working chip (rev5) and won't receive an old stock part. But there are additional issues, e.g. instable SysEx transfers under Windows, which has been solved by commercial companies by developing their own MIDI driver. Such drivers are protected, so that it isn't possible to adapt the PIC firmware. For my own interest I tested the firmware with a shiny new PIC18F4550 rev.5 under Mac OS today. Unfortunately it doesn't work better as under Windows - in distance: just send some MIDI notes, thereafter a SysEx string - this will hang up the MIDI Out port (to USB experts: the OUT endpoint doesn't receive any message anymore, BDn_STAT_UOWN is permanently set, no USB error is reported). Reconnect the interface, start with some SysEx messages: works. Send some notes: no MIDI out data anymore! MIDI In port is working better, but not perfectly (data loss on higher data rates) Thereafter I tried Mac OS with Cypress based MBHP_USB instead: works perfectly! Even better than under Windows (multiclient capability! :-)) Thereafter I tried Robert's MIDI-nator firmware: same effect as with MBHP_USB_PIC Thereafter I searched in the internet for other firmwares and found Synthex's firmware for the Megadrum project: same effect as with MBHP_USB_PIC Frustrating! RS232 solution: yes, some guys already tried this and know how to set it up - google for "ftdi usb midi" Best Regards, Thorsten.

Ok, I checked it with EP1 but the driver still fails - I guess because ESI has integrated some kind of protection. However, if anybody ever hears about a free USB-MIDI driver for windows, please let me know. Thats fine! It's the standard driver which comes with Windows. I should work fine with the ESI driver Best Regards, Thorsten.

PICstart is very reliable, I burned some PIC17C44 successfully in the past Best Regards, Thorsten.

[table][tr] [td][/td] [td][br]Ha-Ha![br]Nils, Stryd and Bugfight moving pots so slowly, that recording software gets and integer overrun while timestamping the events![/td][/tr][/table] (don't worry, just kidding - I will consider a soft-option ;-))

[table][tr] [td][/td] [td][br]Ha-Ha![br]Nils and Stryd are Slow-Pot-Movers![/td][/tr][/table]

Yes, the new behaviour is better for live performance. Best Regards, Thorsten.

Thank you! The device will be detected now by the installation software after I changed the product ID (so that it matches with the .inf file), but the driver fails, probably because the I'm using different endpoints. Therfore I need more informations (which are given by usbview - Sasha: if you find the time... :)) Cimo: under Linux you can request the complete descriptors the following way. First type "lsusb" to display connected USB devices - example: # lsusb Bus 001 Device 003: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse Bus 001 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 002: ID 0a92:1001 EGO SYStems, Inc. Bus 002 Device 001: ID 0000:0000 [/code] Thereafter request the descriptors of the "EGO SYStems" device the following way: [code] # lsusb -v -d 0a92: Bus 002 Device 002: ID 0a92:1001 EGO SYStems, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0a92 EGO SYStems, Inc. idProduct 0x1001 bcdDevice 1.01 iManufacturer 1 iProduct 2 iSerial 4 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 101 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 3 bmAttributes 0x80 MaxPower 32mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 2 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 9 bInCollection 1 baInterfaceNr( 0) 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 1 Audio bInterfaceSubClass 3 MIDI Streaming bInterfaceProtocol 0 iInterface 2 MIDIStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 65 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 1 Embedded bJackID 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 2 External bJackID 2 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 1 Embedded bJackID 3 bNrInputPins 1 baSourceID( 0) 2 BaSourcePin( 0) 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 2 External bJackID 4 bNrInputPins 1 baSourceID( 0) 1 BaSourcePin( 0) 1 iJack 0 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 1 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 3 Best Regards, Thorsten.

VID and PID are not sufficient - the driver doesn't find the device. I need to know more details - they can be determined with USBview (a Microsoft utility) which can be downloaded from here http://www.ftdichip.com/Resources/Utilities/usbview.zip (and various other locations) Important: enable Options->Config Descriptors and Options->Location IDs Thereafter File->Refresh (or press F5) Search the MIDI device in the USB tree, and post the content of the information window as in this example: Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 (64) idVendor: 0x0A92 idProduct: 0x1000 bcdDevice: 0x0001 iManufacturer: 0x01 0x0409: "Thorsten Klose" iProduct: 0x02 0x0409: "MBHP USB" 0x0409: "MBHP USB" iSerialNumber: 0x00 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x03 Open Pipes: 2 Endpoint Descriptor: bEndpointAddress: 0x02 Transfer Type: Bulk wMaxPacketSize: 0x0008 (8) wInterval: 0x0000 bSyncAddress: 0x00 Endpoint Descriptor: bEndpointAddress: 0x82 Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) wInterval: 0x0000 bSyncAddress: 0x00 Configuration Descriptor: wTotalLength: 0x0053 bNumInterfaces: 0x01 bConfigurationValue: 0x01 iConfiguration: 0x03 0x0409: "T.Klose MBHP USB" bmAttributes: 0x80 (Bus Powered ) MaxPower: 0x10 (32 Ma) Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting: 0x00 bNumEndpoints: 0x02 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x03 (MIDI Streaming) bInterfaceProtocol: 0x00 iInterface: 0x02 0x0409: "MBHP USB" 0x0409: "MBHP USB" Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x07 07 24 00 00 01 41 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x06 06 24 02 01 01 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x06 06 24 02 02 02 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x09 09 24 03 01 03 01 02 01 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x09 09 24 03 02 04 01 01 01 00 Endpoint Descriptor: bEndpointAddress: 0x02 Transfer Type: Bulk wMaxPacketSize: 0x0008 (8) wInterval: 0x0000 bSyncAddress: 0x00 Unknown Descriptor: bDescriptorType: 0x25 bLength: 0x05 05 25 01 01 01 Endpoint Descriptor: bEndpointAddress: 0x82 Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) wInterval: 0x0000 bSyncAddress: 0x00 Unknown Descriptor: bDescriptorType: 0x25 bLength: 0x05 05 25 01 01 03 [/code] Best Regards, Thorsten.

Great! :) Please inform me once the dummy guide is avalable, so that I can add a link from the MIDIO128 page - It will be really helpful :) Best Regards, Thorsten.

A prepared IDE is the perfect choice for doing the first steps. Especially for people who just want to customize a header file, rebuild and upload the .hex file. To remind you: thats 99% of all MIDIbox users, and we should focus on them instead of a minority of programmers who will find their way anyhow. It could be part of MIOS Studio, or (which would go into another direction) a completely prepared Eclipse setup, which seems to be popular these days. Of course, files can always be edited outside the IDE, thats normaly the way I'm doing, even when I'm using IDEs for other microcontrollers. But whenever I explore a new micro family (and I did this often in the past), I prefer to setup a project with a simple frontend tool before going deeper into the topic - just because it's much faster and less error-prone (especially when you get direct access to help pages for each particular parameter and option). The HiTOP IDE (which I mentioned before) doesn't install a complete Cygwin environment, instead it uses the cygwin1.dll (POSIX emulation library, 1.2 MB). I'm not sure about the licensing here, but it seems to be a way to call unix commands within a unix-style file system. Best Regards, Thorsten.

Thanks for voting! I changed the encoder speed handling in RC16 - it works much better now! :) Best Regards, Thorsten.

Unfortunately it isn't possible to hold the notes like in non-superpolyphonic mode, since the voice handler needs to be reseted on any patch change. Thereafore notes are now always released in superpoly mode (changed in RC16) Best Regards, Thorsten.

RC16 is now available - beside of bugfixes for minor issues, you get: o "ENV Misc" layer added for MB6582 Control Surface o SIDPlayer: lower line now always cleared when new LCD message is sent by host o changed encoder speed behaviour: values incremented fast by default now. Incrementer is slowed down by pressing the SHIFT button (previously it was the opposite behaviour) [/code] Best Regards, Thorsten.

I find this project very attractive, it could be used as MBSEQ extension, as MBLC motorfader replacement, MB64E encoder/LEDring replacement etc... I guess that it will be a lot of fun working with it, therefore I would like to purchase two kits (without Arduino hardware) once you are starting the order. :) Best Regards, Thorsten.

Sidenote: here an example for a quite successful development platform for hobbyists. Arduino provides a single package which contains everything: IDE with editor and code upload tool, compiler, code library, a lot of templates: http://www.arduino.cc/en/Main/Software. Check also, how other users release new code modules. Everything is open source, so nobody needs to re-invent the wheel, an adaption of the IDE to MIOS could be possible. I must say that this is the direction I would prefer for MIOS: within an extremely short learning period you are able to do modifications in existing templates and upload the code. Ah - even they are also using their own makefile generator, such an environment could hide the autoconf process very easily (the user wouldn't regognize it ;-)) Best Regards, Thorsten.

Sasha, could you please determine the vendor and product ID of your cable? (called VID and PID in device manager) I would like to check, if the same driver is working with MBHP_USB_PIC Best Regards, Thorsten.

Hi Steve, please keep me informed about the progress Best Regards, Thorsten.

I've the feeling, that it would be better to change the encoder handling, so that they are in "fast mode" by default, and slow down while the SHIFT button is pressed. Especially for high resolution values like CutOff this would mean, that the whole value range can be sweeped with a single move w/o using the SHIFT button. Nobody has complained about the current behaviour yet, therefore it would be interesting for me if you agree (-> use the poll function of this article) Best Regards, Thorsten.

yes, this is the right one. Page is mirrored now Best Regards, Thorsten.