TK.

Hi Benedict, the modules are correct, and for the power supply circuit I would suggest the original C64 PSU, a schematic can be found at the MBHP_SID page. The audio outputs of my SID modules are directly connected to the soundcard (Hammerfall DSP Multiface) which gives me the freedom to apply different effects to the channels and to mixdown them seperatly. For other usecases I cannot provide schematics, but I guess that good working VCA (voltage controlled amplifier) and mixing circuits can be found somewhere in the web. Controlling pan: thats possible if you add a MBHP_AOUT modules, which gives you 8 analog (CV) outputs. They are part of the modulation matrix, so you cannot only control them with all 6 LFOs, but also with the 2 envelope generators. One of the CV output can control two VCAs which balance the output between two audio channels. Schematics -> search in the web 12 part polyphony: currently possible with a little effort if you assign the SIDs to different keyzones. However, a real polyphony will maybe be provided sooner or later, but from my experience this will be just a "nice-to-have", but no real useful feature, since each SID only provides one filter channel (which means: complex sounds with filters are not made for polyphony). I myself never needed something like this, so: "low priority" Best Regards, Thorsten.

Hi Twin-X, don't panic! We can help you via remote, you only need to explain more details about your observations so that it's easier for us to give you more explicit tips. So, your SIDs are working, you are able to play sounds, but there is no response from the control surface, right? Best Regards, Thorsten.

Pro Tools doesn't support the LC/MC protocol, therefore the Motormix emulation is better - the hardware is similar, but you have to left out the second display (only one 2x40 LCD required), the LEDrings and the meters See also http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1086542547 Best Regards, Thorsten.

to give you some more technical backgrounds: in mios_bankstick.inc of the MIOS source code you will find the MIOS_BANKSTICK_Write_Poll loop with the note "memo: time out counter should be inserted here!" This is the only point where a BankStick transaction can hang, and the reason for this is either a damaged EEPROM, or an unstable connection. So, definitely a hardware failure (which is not handled by MIOS yet, but for which I don't see a strong requirement) Another point of interest: mb64e_bank.inc, search for "MB64E_BANK_WriteBankStick" you will find following comment "reset core if bankstick not available anymore (just for debugging)" This case can happen if the BankStick is disconnected during a write operation, or when you've a bad junction. So - both cases explain what you've noticed, therefore no bug, but a deterministic behaviour (from the software point of view) Best Regards, Thorsten.

Yes, each button can be reassigned. Only restriction: the general purpose group (2 shiftregisters/16 buttons to select the step/pattern/menu) has a fixed direction. In other words: if you connect it in an alternative direction, the step buttons are not aligned to the step LEDs (and with the step events of course...) Best Regards, Thorsten.

You can upload SysEx data, otherwise the LCD wouldn't show the dummy message of MIOS (READY) which appears only when no application has been uploaded thereafter. So, it seems that you were able to upload mios_v1_7.syx, and you should also be able to upload any other SysEx dump once you found out what is wrong with your configuration. Reg SysEx ID: at power-on the core sends an upload request which contains the device ID of the core. Which device ID do you see, still 1, or 0? You never wrote how you are trying to upload code, are you using MIDI-Ox? Have you regenerated the .syx file with hex2syx.pl? Or are you using vsysexbox? In this case it's easier, you only have to select the correct device ID in the selector box Best Regards, Thorsten.

yes - but you need to select the PIC16F877A type in IC-Prog (and not the PIC16F877) because of the different programming algorithm Best Regards, Thorsten.

Just to point up that this is no software problem: every MIDIbox SID user who has connected one or more MBSID slaves uses the MIDIbox Link Best Regards, Thorsten.

is this really a question concerning MIOS programming?` However, I think that you've some kind of ground loop in your circuit which provokes the additional jitter. A better power wiring with a central ground point (prevent long chains) can help. You can still work with two PSUs if you want... In thie case don't connect the grounds of J11 connectors together... if this still doesn't help, and you are not able to find the reason, then try it with optocouplers and ensure that there is no ground connection between the boxes. Best Regards, Thorsten.

however, seems that it makes sense to integrate the same AUTO_ID feature like in the MIDIbox SID, because it seems that this seperation (which sometimes makes sense) is too confusing for users Best Regards, Thorsten.

There must still something be wrong with your hardware. As PayC wrote, he noticed similar obscurities with his 24AA256... maybe you should try different cable lengths or so... thats all what I can say to this topic. Have you also tried a "MIOS BankStick 32k" Request and Send with SysExBox? Best Regards, Thorsten.

Zum MIDIfilter: die PIC18F Loesung sieht ganz einfach aus, denn MIOS hat ja alles an Bord. Du benoetigst lediglich das Small Skeleton, und muss dann halt im USER_MPROC_NotifyReceivedEvent Hook den Code zum weiterleiten der MIDI Events reinschreiben. Natuerlich laeuft das dann auch mit einem voll bestueckten Core Modul... es ist halt eine ganz normale MIOS Applikation. Gruss, Thorsten.

yes, but totally unsupported, since it's unfinished and I don't plan to add more into this direction since the implementation is very hardware specific (in other words: I don't want to program individual solutions for you guys which I would never use by myself...) Check the MIDIbox64 SysEx Implementation doc, search for MIDI remote, and think about the possibility to send these sysex commands via meta events... Best Regards, Thorsten.

yes, but totally unsupported, since it's unfinished and I don't plan to add more into this direction since the implementation is very hardware specific (in other words: I don't want to program individual solutions for you guys which I would never use by myself...) Check the MIDIbox64 SysEx Implementation doc, search for MIDI remote, and think about the possibility to send these sysex commands via meta events... Best Regards, Thorsten.

if you've enabled "Send Program Change on Bank Changes", yes At the receiver site "Receive Program Change for Bank Change" should be enabled. no, you can do this change in your .ini file, or with Serge's Editor the diagram above shows a concept which can be used by other programmers if they want to control multiple midiboxes from a single control surface. This is not implemented in MIDIbox64. If you need this, then you have to program this by yourself. Best Regards, Thorsten.

if you've enabled "Send Program Change on Bank Changes", yes At the receiver site "Receive Program Change for Bank Change" should be enabled. no, you can do this change in your .ini file, or with Serge's Editor the diagram above shows a concept which can be used by other programmers if they want to control multiple midiboxes from a single control surface. This is not implemented in MIDIbox64. If you need this, then you have to program this by yourself. Best Regards, Thorsten.

Hi Kapser, in order to disable the menu navigation buttons, you have to modify the numbers behind "#define DEFAULT_DIN_MENU_*" to > 64, e.g. #if DEFAULT_ENC_DATAWHEEL == -1 #define DEFAULT_DIN_MENU_EXEC 64 #define DEFAULT_DIN_MENU_RIGHT 65 #define DEFAULT_DIN_MENU_LEFT 66 #define DEFAULT_DIN_MENU_SNAPSHOT 67 #else For your special functions you need to program some additional code (and it isn't that easy if you haven't worked with PIC assembler yet) Best Regards, Thorsten.

strange. in IFGEQ I would replace W by ACCESS, but this isn't the reason (both constants are 0) You could add following code: movlw 0xf0 ;; for debugging call MIOS_MIDI_TxBufferPut movf MB_BANK, W andlw 0x7f call MIOS_MIDI_TxBufferPut movff MIDI_EVNT_VALUE, WREG andlw 0x7f call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut before the last block, and movlw 0xf0 ;; for debugging call MIOS_MIDI_TxBufferPut movf MB_BANK, W andlw 0x7f call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut before the return for debugging Best Regards, Thorsten.

Hi, very nice solution! It doesn't take care for the LEDs, but if this doesn't matter I think you are happy :) Filtering the shift button - you could add: ;; exit on event from button ID = 0x10 movf MIOS_PARAMETER1, W xorlw 0x10 skpnz return at the beginning of the MB64E_BUTTON_GP function Best Regards, Thorsten.

Hi Wonder, it looks strange, really strange. Following test would be interesting: don't write out the characters on LCD, but send them to the MIDI interface. Write: movlw 0xf0 call MIOS_MIDI_TxBufferPut at the top, replace all calls to MIOS_LCD_PrintChar by MIOS_MIDI_TxBufferPut, and Add: movlw 0xf7 call MIOS_MIDI_TxBufferPut at the end. Start MIDI-Ox and check the SysEx messages which are sent by your core. They should contain exactly the character codes which are in your BankStick. If not, the problem could be your LCD, but just try it first. Sending MIDI messages for debugging is a really useful - I'm doing this very often for logging and analyzing data :) the checksum is missing, therefore the error code The core doesn't hang, but it will be reset after a 02 upload request, thats the normal behaviour. Best Regards, Thorsten.

Hi, finally all applications of Serge are ported to the MIOS versions of MIDIbox64 and MIDIbox64E. The SysEx tool got also some minor updates: http://www.midibox.org/mios_tools/sysexbox_18f_v1_1c.zip http://www.midibox.org/mios_tools/vmidibox64_18f_v1_0b.zip http://www.midibox.org/mios_tools/vmidibox64e_18f_v1_0c.zip Note: there is a known imperfection when requesting a configuration bank from MB64/MB64E - if the merger mode is toggled (e.g. from "Merger On" to "Merger Off"), the MIDI protocol will violated during the download, and vmidibox will report an invalid sysex block.I will fix this in the firmware, so that the protocol won't be violated anymore in this corner case. Best Regards, Thorsten.

I hope so! :-) I must admit that I haven't worked on the C wrapper anymore after the night I wrote it ;-) So your error reports are really welcome :) Currently I'm working on vmidibox64 and vmidibox64e (C++ fun under windows), hope that I will find some time thereafter to finalize the wrapper BestRegards, Thorsten.

When I find the time... Best Regards, Thorsten.

Hi Alex, thats only a small routine in USER_DIN_NotifyToggle is required which forwards the toggle events of your buttons to the MIDI processor of MIDIbox SID. But: are you sure that you've a dedicated line for each button of your piano, or are the buttons organiced in a matrix? Best Regards, Thorsten.

Hi Pilo, thanks for the input. I cannot explain while your variant should work better (since MIOS_PARAMETER1 is overwritten), but I will try this out with my MBLC hardware and bring the fixed code into the first official release. Best Regards, Thorsten.