TK.

Hi, I cannot recomment the use of touch sensors for a Sequencer. In theory it works, but in practice you won't be happy if functions are unintentionally triggered when you go with your fingers fast over the sensors. Just think about, how it would be, if your computer keyboard would consist of touch sensors! Best Regards, Thorsten.

yes, there is a way to provide Inc/Dec MIDI Events instead of absolute MIDI events, only a small number of changes have to be made in the CC handler of sid_midi.inc - but it would only be a "poor" solution, and would work completely with already available stuff. E.g., the VST plugIn wouldn't work anymore, the master/slave system (if SID slaves are connected to the master), etc... But does this really make sense to use Inc/Dec events, when you don't know, which value the CC has reached? I would propose to build a complete Control Surface instead searching for a tinkering solution to get the Doepfer controller properly running. The CS is cheaper, but much more powerful anyhow. And remember, that the CS provides a controller function as well, so that you could sell your Doepfer controller thereafter ;-) Best Regards, Thorsten.

To 1) 15V is specified to be at the secure side if somebody with no electronic background knowledge orders a PSU 14 V PSUs are very rarely available, 15 V are much easier to get and mostly much cheaper. I wouldn't use a PC PSU, too noisy... To 2) so long a voltage source is connected to the Audio In, you won't hear that much additional background noise. General rule: Use the Audio In whenever you want, put the jumper on it when you are not using it in order to achive best results. You can also let the audio In open of course, the jumper measure is just to achieve the optimum! I think that you will quickly notice this, when you are doing the first experiments on your own MIDIbox SID. Maybe you won't hear any change regardless if the Audio In is shortened or not (like most people...) Best Regards, Thorsten.

Warum? Der PIC wird im HS Modus betrieben, somit ist der interne Oszillator aktiv. Der Quarz und die beiden Kondensatoren sind Teil des Schwingkreises (-> analoge Schaltung). Es ist nicht moeglich, die XTAL Pins zweier Oszillatoren einfach zusammengeschalten. Man koennte jedoch einen externen, integrierten Oszillator hernehmen, und diesen an Pin 13 von allen PICs anschliessen. Ich sehe hier jedoch keinen Vorteil - weder technisch, noch preislich. Gruss, Thorsten.

Did you include sm_simple.inc before or after mios_tables.inc? Normaly it should be added at the end of main.asm (e.g. below the "reusable utility functions" comment) to avoid address conflicts Best Regards, Thorsten.

Maybe you've added something to mios_tables.inc, so that the tables don't match into the small address space between 0x3082 and 0x327f anymore. However, thanks to MIOS V1.9, these tables could now be located outside mios_tables.inc again (it was the only trick I found out to add some more code) Especially with the PIC18F4620 there is no memory issue anymore, so ... just put the DIN and DOUT tables into a new .inc file :) Best Regards, Thorsten.

Maybe you need to select the right PIC in the mios.h file? Best Regards, Thorsten.

this is only possible within the application. If it overwrites a DOUT register, then you have to find, where, and you have to disable the appr. code. Maybe the LED ring handler overwrites the DOUT registers? You can disable it in the main.asm file (one of those #define's) yes, they overrule button events forwarded to the MIDI out handler. Best Regards, Thorsten.

Hi Marc, the Device ID can be specified when you are burning the bootloader into the PIC (see bootloader page). For people who don't own a PIC burner and forgot to specify it when buying a preburned PIC at SmashTV or Mikes shop, change_id can be used as alternative solution - this application reprogramms the ID field. This ID field is not touched by MIOS itself, and also not by the application. This has the advantage, that you can later update MIOS (if there should ever be a new version) or a application without doing this complicated way to specify the ID again. This is also the reason, why the device ID is not defined in MIOS - it's defined outside MIOS, because the 1st level bootloader needs to know it as well. So, just follow the instructions which are described in the change_id application, thereafter you are fine. 1st level bootloader, MIOS and the MIDIbox SID application will find this ID and handle with it. Best Regards, Thorsten.

I am little shocked and disappointed. You propably solved the problem by yourself, but you don't inform the community that you don't need help for the configuration anymore? Maybe this is the reason, why some of us are not sure, if they should spend some minutes to help you, when we don't know, if you still need the help... Best Regards, Thorsten.

Are you using the LTC with another MIDIbox, and this one doesn't send jittering values? Only your MB64E based MIDIbox sends "unwanted" MIDI events? Or did you upload the MIDIbox64 application on your MIDIbox64E, and this one doesn't send jittering values? Are these values which are beeing sent completely random? Do they change when you touch with your fingers over the analog pins of CORE:J5 and the analog inputs of your AIN module? Or do these values toggle between two numbers. For example, a CC value is changing between 1 and 2, but you never see random jumps like 16...34..2....98...23...4 Have you assigned MIDI events to all pot inputs (regardless if they are connected to ground or not), or are some slots "empty" (no MIDI events defined) - in this case, the empty parameter wouldn't sent anything via MIDI Out, but the LCD would display, that the value has changed. There could be a ground loop between the PC and the PSU you are using for your MIDIbox64E. When you disconnect the RS232 cable, the loop won't exist, and therefore no jittering values will be sent. Have you already tried the PSU of your MIDIbox64? Please answer all my questions, they are important for us to get an overview about the issue Best Regards, Thorsten.

Hi, did you check the pin orientation? Maybe you've swapped the pins? Best Regards, Thorsten.

this is possible since ca. 4 years ;-) -> http://www.ucapps.de/midibox64e/midibox64e_sfb_table.txt Best Regards, Thorsten.

Hi Lall, Miss Parker with I2C interface would be superb, and for me a reason to build the project and to support Fx parameter control from the MIDIbox SID :) Best Regards, Thorsten.

You wrote that you did the MIDI troubleshooting, but you are not writing about the results of each test. E.g., it would be interesting, if the IO loopback without PIC is working: Best Regards, Thorsten.

Hi Rowan, no, it's not required to add new hardware. I've written a tutorial for the 303 mode which can be found here: http://www.ucapps.de/howto_sid_bassline.html Best Regards, Thorsten.

The three voices can be assigned to different channels via SysEx (see SysEx implementation table), but the usage is too difficult. It's better to assign them to different keyboard zones, this can be done from the CS or with JSynthLib Best Regards, Thorsten.

An impressing assembly code in respect of the comments is Jarek's AVR Synth (-> http://www.jarek.synth.net/AVRSYN.asm) - note especially the aesthetic ASCII art ;-) However, not everbody has the talent to document his code in an understandable way... Yes!!! Especially the button reconfiguration for the 2x40 LCD options is a FAQ, it would be great if a step-by-step guide would be available Best Regards, Thorsten.

There are only three possible combinations, keep trying! ;-) Best Regards, Thorsten.

Since MIOS V1.8, FSR2 is saved as well, and FSR0 is saved by the C wrapper Most of the older docs are inconsistent in the meantime, I know... biggest problem is, that all ISR related comments in the main.asm file are not correct anymore... just ignore it Best Regards, Thorsten.

Looks like the ones I got from d2k some time ago - they are (still) working nice! Best Regards, Thorsten.

Are you really using the optimized PSU circuit? (http://www.ucapps.de/mbhp/mbhp_4xsid_c64_psu_optimized.pdf) - there is no connection to J1 of the core module... Best Regards, Thorsten.

See mm_leddigits.c of the MIDIbox MM application (non multiplexed) Best Regards, Thorsten.

Hi Simone, you could create Meta Events in mb64e_meta.inc, which set the global MIDI channel, e.g.: MB64E_META_Handler_00 ;; set global channel to the second byte of a F0 xx meta event movff MB64E_GLOBAL_CHANNEL, MIDI_EVNT1 return Meta Event F0 01 assigned to a button will set the channel to #1 Meta Event F0 02 assigned to a button will set the channel to #2 Meta Event F0 03 assigned to a button will set the channel to #3 etc... F0 00 will disable the global channel feature (MIDI events are sent via the programmed channel) Best Regards, Thorsten.

no, but you could just change the pinning at the DOUT module (connect the LEDs to the right pins) Best Regards, Thorsten.