TK.

Yes, under certain circumstances the core MIDI out can be used as additional MIDI port. It will work stable so long no bytes are received on the core MIDI In. So, it's ok, so long no keyboard is connected to the sequencer, and/or no MIDI clock is received from external. Best Regards, Thorsten.

Yes, both chips are not applicable for MIOS/MBHP_IIC_* Best Regards, Thorsten.

Hi Matoz, thats a good sign. It means, that the core can control the OPL3 module, that the YMF262 is running, and that the connections between YMF262 and YAC512 are (probably) ok. Do you hear the sounds on the OP amp inputs I1+/I2+/I3+/I4+ of IC6 (the output buffer)? If not, visually check (extensively) the connections between the two YAC512 and IC3/IC5 - due to the small pin size of the SMD parts, a open (not soldered) or shortened junction is very likely. Best Regards, Thorsten.

A balanced voltage is required for the OP amp TL072, therefore +/- 12V is recommented. 2: yes Best Regards, Thorsten.

Second Teaser: http://www.midibox.org/forum/index.php?topic=9938.0 There are 16 instruments per patch, which can be played by 2 SIDs (-> 6 voices which can play in parallel) With a full stuffed MBSID V2, you could play up to 64 instruments with 8 SIDs (-> 24 voices) Best Regards, Thorsten.

So, here the second part: a quickly recorded a session where I'm using Drum and Bassline sequencer in parallel - sequences and bassline parameters are selected/controlled live from a MIDI keyboard. The drum sequencer provides 8 patterns with 8 tracks. Since there are 16 drum instruments available per patch, each track can trigger two of them in a special way: (edit screen of track #4 of sequence #7) .: no instrument is played *: default instrument will be played A: the default instrument will be played w/ accent S: the secondary instrument will be played (w/o accent) Track 1 Controls Instrument #1 (default) and #2 (secondary) Track 2 Controls Instrument #3 (default) and #4 (secondary) etc... The advantage of this method: it saves memory (8 sequences available instead of 4), and it allows to realize the typical Open/Close HH or High/Low Tom scheme from a single track. Here the demo (I just have noticed, that the BD is really low tuned... you won't hear it with cheap speakers): http://www.ucapps.de/mp3/midibox_sid/mbsidv2_drums_demo1.mp3 During the session I noticed a lot of imperfections, which need to be solved :-/ Best Regards, Thorsten.

I've worked on the drum engine in the last days. The concept is frozen, most of the code is implemented, and now it needs a lot of testing (from my side) in order to check, if the engine is doing what I initially planned. So, it was time to work on some teasers! ;D Some words to the concept: each patch contains 16 drum patches, which either can be played directly from a MIDI keyboard/sequencer, or from the internal sequencer, which works similar to the bassline seq - means: you can select the sequence via MIDI notes, so that they can be controlled interactively. More words to the sequencer in the next teaser ;-) Since the memory of a patch is limited, a drum only consists of 8 parameters. But only might be the wrong word, because each parameter changes the drum timbre dramatically! Instead of editing wavetables, or tweaking on ENVs/LFOs (which can be very time consuming and is not the intuitive workflow you would expect from a drum synth), there are prepared "drum models", which are hardcoded in the firmware. In theory up to 256 drum models can be implemented. Drum models currently only exist of waveform/note tables. Within the patch It's possible to change the tuning, the ADSR parameters, the gatelength, the WT speed and a special "WT parameter", which modifies a variable part of the wavetable. Ok, enough details, just listen to the examples: Bass Drum Model #1 and #2, some parameters tweaked while sound is playing: http://www.ucapps.de/mp3/midibox_sid/mbsidv2_drums_bd_examples.mp3 Snare Drum Model #1 and #2, some parameters tweaked while sound is playing: http://www.ucapps.de/mp3/midibox_sid/mbsidv2_drums_sd_examples.mp3 Fx Model #1 and #4, some parameters tweaked while sound is playing: http://www.ucapps.de/mp3/midibox_sid/mbsidv2_drums_fx_examples.mp3 Now it's time to check, how drum and bassline sequencer are working together. :) Best Regards, Thorsten.

First of all, please keep in mind that there is a FAQ which answers such questions clearly http://www.ucapps.de/midibox_sid_manual_ki.html In 4bit mode, D7..D4 are connected to the core. D3..D0 should not be connected. Neither the PIC pins, nor the LCD pins should be grounded to avoid a possible chance for a short circuit for the case that the 4bit mode is not initialized correctly (for whatever reason, e.g. RW and RS are swapped), and LCD is read out (accordingly the output drivers of LCD D3..D0 will be actived) There were always trouble with LCD connections in the past, independent from 8bit or 4bit mode, and the flow how to determine the reason is always the same: use the LCD interconnection test. Not at least, this helps you to check if MIOS is running, and it helps you to sort out the LCD connections seperately. Best Regards, Thorsten.

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.