TK.

The firmware is already complicated enough, from MBSID V1 and MBFM I learned, that such extra BankStick partitionation options only causes a lot of additional effort at my side. Initially I planned not to support 24LC256 at all - search in the forum to find out, how many times people missed the info about the different number of patches, and the resulting side effects (e.g. during a bank upload). I really don't know, where to put this information so that people are aware of this. :-( But there is also a practical reason why two BankSticks cannot be combined: because the first patch slot is always used as storage for internal informations (Magic bytes, and future extensions) - so, in fact a 24LC512 only stores 127, and a 24LC256 63 patches - the remaining patch (Patch #1) is always stored in internal EEPROM, and it's the same for all banks (A001, B001, C001, ...). So, combining two 24LC256 to a single bank would result into 126 patches - don't want to know, how many times I would have to answer questions about such strange side effects again and again to clarify, that this wouldn't be a bug? So, please believe me: it's easier to use seperate banks for each BankStick than combining two BankSticks to a single bank. Once the SysEx editor and patch manager is available, it will be possible for you to split the presets over different banks Best Regards, Thorsten.

See http://www.ucapps.de/midibox_sid_manual_hw.html search for "banksticks" or "24LC256" Best Regards, Thorsten.

You could use Special Function buttons to switch between different MIDI event setups located in different banks (see -> http://www.ucapps.de/midibox64e/midibox64e_sfb_table.txt) - but the big issue is, that informations which have been received before (e.g. absolute encoder positions or LED states) will get lost during a bank switch. Your host needs to support a "controller snapshot" function in order to update the encoder/LED settings. On the other hand: are you sure, that banking isn't natively supported by your host software? So far I remember, it isn't a problem to setup this with Cubase or Nuendo (but I'm a Logic user and cannot help you here - different movie ;-)) The advantage of host based bank switching: always consistent, especially when you are changing parameters with the mouse or load a new song. Today the MIDI controller support of DAWs is mostly so powerful, that only a really stupid hardware is required to communicate with the host. Thats one of the reasons why I haven't spent much more effort into the MB64/MB64E firmware implementation anymore. Best Regards, Thorsten.

Es handelt sich hier sehr wahrscheinlich um ein Problem mit Deinem MIDI Interface. Welches hast Du Dir denn gekauft? Vielleicht hat der Treiber einen Bug, und eine aktuelle Version muss installiert werden (das hatten wir in letzter Zeit schon des oefteren) Gruss, Thorsten.

There is no encoder mode which would cause an event sent over different MIDI channels while the encoder is moved. Could it be, that it is connected to wrong pins? Encoders can only be connected to D0/D1, D2/D3, D4/D5 or D6/D7 of a 74HC165 If you would connect it to (for example) D1 and D2, you would notice exactly this effect. Best Regards, Thorsten.

Did you change the LED_MAP, so that it is only controlled by the received MIDI status? See also this posting http://www.midibox.org/forum/index.php/topic,6039.0.html Best Regards, Thorsten.

The voltage inputs have to be connected together with two isolated cables at the bottom of the PCB. I just noticed, that this isn't documented on the MBHP_AOUT page. I will take a photo and add it to the soldering guide. Best Regards, Thorsten.

Hi Steve, if your variant still doesn't differ so much from the MIDINator code, it doesn't make much sense to test it on my site yet. I guess that it will also fail under MacOS. My own (assembly-based) firmware is mainly based on the Microchip framework as well, the class handler is completely rewritten (however, nothing spectacular) therefore the bytecount is read before releasing the semaphore to SIE. Last saturday I incorporated all the framework errata which are documented here http://forum.microchip.com/tm.aspx?m=275422, but they don't solve the problem. I also found a bug in my own code (risk that wrong byte counter used in the OUT ringbuffer), unfortunately it wasn't related to the issue. I feel that I'm not able to continue debugging without a hardware based USB analyser. But they are too expensive, especially for a sparetime project. For next weekend I'm planning to write down all the findings, put the documentation and unstable firmware on the website, and to freeze the project again - in the hope that sooner or later somebody else will find the bug, or can give me a fully working firmware for further analysation. Best Regards, Thorsten.

Have you ever read the "readme.txt" file? Best Regards, Thorsten.

See this article: http://www.midibox.org/forum/index.php/topic,10135.0.html MBSID V2: NRPNs aren't easy to manage, it's better to assign the sound parameter to knob functions. Thats the way I'm normaly doing, especially because it's possible to assign multiple parameters to the knob, and to define the range. Best Regards, Thorsten.

See this article: http://www.midibox.org/forum/index.php/topic,9767.0.html Current state: Linux version is running fine, I'm planning a port to MacOS X once I find the time to dig through the docs. Wilba started a Windows variant, but encountered issues with the MIDI API of Windows (so far I remember) Best Regards, Thorsten.

no, MBSID V2 is just a fake to sell more MBHP modules - nothing but the version number has changed. ;-) Best Regards, Thorsten. P.S.: IO functions are now defined in setup_*.asm

The current behaviour is important for first-time users to get an understanding, what an encoder is doing. Or why you don't hear a change - because you don't see the value. In distance to an analog pot, this is the only way to give "visual feedback". However, I would find a special button function more useful, which jumps back to the previous page which was visible before you started to move encoders. This would give you the advantage, that you will always get visual feedback, but don't miss the page which was previously edited. Such a function could be integrated into the SHIFT menu page. Best Regards, Thorsten.

Actually it's a program change event which select the patch. CC#0 is used to select the bank Best Regards, Thorsten.

In MBSID V1, wavetables were only stored in EEPROM due to limited RAM of PIC18F452. And writing into an EEPROM takes a lot of time - you can calculate ca. 2 mS per byte. For 128 bytes this makes 256 mS! However, there is a simple solution which has been integrated for this purpose: use CC#12 to change to another Wavetable which is already stored in BankStick. This CC gives you --> ZERO LATENCY <-- access to up to 128 wavetables per bank! :-) Best Regards, Thorsten.

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 ;-))