TK.

No, digital outputs should never be grounded, this could destroy the chip. The missing MF module is not the reason for jitter. Only unusued analog inputs have to be grounded, as shown in this schematic: http://www.ucapps.de/mbhp/auaimbctg.pdf So: if you haven't connected all 8 faders yet, and the appr. analog inputs are not grounded, you would receive a lot of random Pitch Bender Events as well. Best Regards, Thorsten.

Great that it is working now :) Again: the open pins should not be grounded (as I said earlier)! Best Regards, Thorsten.

Hi Kevin, it looks like a jitter issue. This could be related to the power wiring; a good ground connection between faders and the core module is the most important thing, and the 5V connection is not less important. Use thick cables (2mm...3mm), and make them as short as possible. If there is a special soldering lug for the fader metal case, connect it to ground as well. It could also be a PSU issue, but let's assume first that the problem is related to the connections... There is a Jitter Monitor application in the MIOS download section, which helps you to determine the quality of the connections. Best Regards, Thorsten.

MIOS has been uploaded correctly, and it was also running before the update, otherwise the SysEx response messages would look different. This can be doublechecked by uploading the LCD interconnection test - if MIOS wouldn't run, the LCD pins wouldn't be controlable via MIDI. The unusued data pins should be left open! Don't connect them to ground! Best Regards, Thorsten.

The answer is misleading... according to the datasheet, your LCD supports 4bit mode, therefore it is already connected correctly. For the PIC18F4685 version of MIOS the data pins DB0..DB3 should not be connected (they won't be used anyhow). Did you already try the lcd_interconnection_test_v1? (usage is explained in the main.asm file) It helps you to check, if all LCD pins are accessible (correct order, no shorts, no broken wires) Best Regards, Thorsten.

Hallo Movin, ja, die Emulation ID muss sehr wahrscheinlich angepasst werden. Das convert.bat Script ist obsolet, du kannst das neue .hex File direkt mit MIOS Studio aufladen. Die Details stehen hier: http://www.ucapps.de/howto_tools_mpasm.html Gruss, Thorsten.

I've the same problem: I definitely would like to improve the user interface of JSynthLib, as I also find that the patch management and general workflow requires a lot of improvements. But there are too many other interesting projects I'm doing in parallel... So, I can only say: count me in as beta tester. I would also give you the required informations for MBSID V2 patch structure and handling of course. Best Regards, Thorsten.

Hi, a snapshot of this project can be found here: http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip For your "simple" interface, NUMBER_MIDI_INTERFACES should be set from 5 to 1 in usbdsc.c (by default, it is assumed that 4 MBHP_IIC_MIDI module are connected in addition, resulting into 5 MIDI In and 5 MIDI Out ports). IIC_MIDI_MAX_NUMBER should be set from 4 to 0 in iic_midi.asm, otherwise you need to add some additional pull-up resistors to the core (I guess the RA0..RA3 pin + RD5) in order to avoid random effects. Best Regards, Thorsten.

This thread is some days old, I'm not sure if you already solved the problem? If not - we are here to help you! :) Which effects do you currently observe? "MIOS Skeleton Small.mcp" can only be loaded with an expired MPLAB version. It's required to create a new project, or better: to use the assembler (MPASM) directly as described under http://www.ucapps.de/howto_tools_mpasm.html Best Regards, Thorsten.

http://www.midibox.org/dokuwiki/coresound Best Regards, Thorsten.

8 BankSticks + 4 MBHP_IIC_MIDI modules connected to the same IIC bus are working fine Best Regards, Thorsten.

NRPNs are not implemented yet. But the 5 knobs are accessible via CC (Knob 1: CC#1, Knob 2..5: CC#16..CC#19) Best Regards, Thorsten.

Yes, MBUC is the best choice here! :) Best Regards, Thorsten.

BC337 (one part is already stuffed on your core module) Best Regards, Thorsten.

Design related issues which you could discuss without my attention (they can be propably solved during a long weekend...) - how to realize CAN transfers with so that they don't block the MIDI engine to avoid risk for buffer overflow at MIDI receiver and/or CAN receiver side (possible solution: rearrange the message buffers, use special ID mask, so that some of them can be used for queuing incoming broadcast messages - don't use handshaking here - needs complete firmware before it can be evaluated) - how to organize the note stack at the master side, so that it can handle all the different modes (than more ideas from your side, than more difficult to find an universal method - possible free memory depends on RAM allocation of final v2.0) - how to handle portamento (don't know how to transfer frequency variables fast enough from one to another core before the next SE update cycle) - how to handle arpeggios and arp events (wavetable) (no idea) - where to store the different modes in the ensemble structure so that future extensions are not blocked - how to configure them exactly at the CS w/o consuming too much memory, so that other nice features would have to be cancled (no idea, always very time consuming definition task) Best Regards, Thorsten.

thats ok, I guess that they will also sound cool with SID filters, and if not, slight changes should help. I've CEMs, Moog and soon SSM (dontated by Seppoman :)) Best Regards, Thorsten.

P.S.: you can help me by creating a *lot* of new patches for the user library - I need such patches as "testpatterns", so that I'm able to check if all engine functions are still working when I'm doing changes. Other things which are missing: - a Java based bank manager - a Java based SysEx editor (for people who don't build the CS) - improvements in the user manual whenever something is not clearly described from my side Best Regards, Thorsten.

the firmware keeps track of notes which are still pressed, and notes which were pressed before sustain was enabled, and are not pressed anymore after sustain has been released. This issue is probably related an unexpected corner case in the patch configuration. Which play mode are you using (mono/legato?) - and what is your trigger matrix configuration. Or are you using a preset patch? Which one? Poly mode: I can understand your impatience, as I can understand why so many people frequently ask me via mail, when I will finally implement feature A, B or A&B, and why A before B, and why not D and E in addition, as I'm coding so quickly? I don't want to start discussion here, why your thoughts are not working completely (e.g. why it doesn't make a difference, if Note events are transfered via CAN, or enable/disable events). I also don't want to discuss, why your ideas for different configurations won't work as you currently think, etc... Such discussions are just too time consuming for me. I don't want to repeat myself, but maybe I wasn't clear enough last time: PLEASE let us discuss the requirements for suply poly after the v2.0 release, when I have a clear view about the possibilities. Be happy, that I haven't already cancled this idea - it will cost me an immense coding, debugging and support effort. Best Regards, Thorsten.

Hi Gyrurek, the second core sends "0b" status core, which means: MIDI overrun. It seems that the MBFM firmware loads the CPU already so much, that merging cannot be done this way :-( If you've luck, it will work better when a "primitive patch" (which doesn't use the modulation features) is selcted. Best Regards, Thorsten.

Hi Tom, which voltage do you measure on the positive inputs of the OP amp, is it between 0V and 5V (depending on note or CC value?) IIC modules: the resistors are required so long the pins are not directly tied to Vs or Vd in order to ensure a stable logic level. Otherwise random things can happen (like you've probably noticed) Best Regards, Thorsten.

Did you notice the pin count? :-/ Best Regards, Thorsten.

You can also send the PICs to me (Munich/Germany) - this will only cost you the return postage- Best Regards, Thorsten.

Yes, clever! Great woodwork - thanks for sharing the pictures with us! :) Best Regards, Thorsten.

Beta9 is now available - it contains three new button functions for the MB6582 hardware, which have been added by Wilba (Play, LR, Matrix/Meter button), a bugfix for meter display, and an "Up2 Octave Transpose" option for bassline mode Best Regards, Thorsten.

Ok, I've added the hold pedal function, please try it out - hope that it works in real life :) -> http://www.midibox.org/forum/index.php?topic=9457.msg67779#msg67779 Note that it currently only works with Lead patches, and I'm not happy how it behaves with WT sequences. So... it still needs some improvements. Best Regards, Thorsten.