TK.

Hi Roger, better to add such an important information next time ;-) It's clear why it cannot work with a USB/serial converter, because ic-prog has to access the physical port directly to drive the current pump (the circuit around Q1) Best Regards, Thorsten.

the first idea is the better one. You could use a counter which selects the byte for which you are waiting for. Counter == 0 => F0 Counter == 1 => 15 Counter == 2 => 15 Counter == 3 => 00 etc. once a byte doesn't match, reset the counter to 0 once the counter is 5, you can switch on/off the LED depending on the received byte The F7 can be ignored (if you don't want to implement an error handler) the MIDI protocol allows to interrupt SysEx strings with realtime messages like MIDI clock, but such messages can be easily filtered out, just ignore all bytes which are >= 0xf8 There is always a start and stop bit at the begin/end of a byte SysEx parsing:

Oh great, why didn't you write this into your other posting, so that other people don't have to spend more time to help you on an issue which you already solved by yourself? This inconsiderated behaviour doesn't really motivate me to give you additional help... but maybe somebody else has the patience?

double posting... http://69.56.171.55/~midibox/forum/index.php?topic=4453.0

Is it really "01 00 F0 00 7E 40 00 F7"? Then it could be a general problem, because the request string is "F0 00 00 7E 40 00 01 F7" Which parts of the MIDI troubleshooting guide have you already tried out? Which tests are failing? -> http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

I think that such a cable should be ok: it's cheap and especially thin. You can use one wire for the wiper, another for +5V, and the shield for ground > do you think that mantaining the sub D port but using shielded cable I can fix the problem? not when you want to achieve lowest jitter, but so long your fader only send 7bit values, it could work Best Regards, Thorsten.

Some nice buttons can be found in the part archive: http://69.56.171.55/~midibox/forum/index.php?topic=4361.0 http://69.56.171.55/~midibox/forum/index.php?topic=2688.0 Best Regards, Thorsten.

Some weeks ago Karl Dalen (KD) pointed out that bypass capacitors are missing in most modules. Using these caps for each IC device is a general design rule, they improve the power integrity. Although you possibly never noticed problems without these caps, there is no reason why they shouldn't be added in the future. Therefore I've updated following schematics. There are also snapshots which help to find the right places at the bottom of the PCBs - don't try to place them exactly like me, just take care that one end of the cap has to be soldered as close to the +5V power input of the device as possible, and the other end to ground. Core Module: two additional 100 nF ceramic caps: http://www.ucapps.de/mbhp/mbhp_core.pdf AINX4 Module: four additional 100 nF ceramic caps for the PIC: (I've used a so called "shrink hose" (german: "Schrumpfschlauch") to isolate the cap leg which goes to ground) http://www.ucapps.de/mbhp/mbhp_ainx4.pdf DINX4 Module: four additional 100 nF ceramic caps for the 74HC165: http://www.ucapps.de/mbhp/mbhp_dinx4.pdf DOUTX4 Module: four additional 100 nF ceramic caps for the 74HC595, one additional 100 uF elcap at the power input of the module: http://www.ucapps.de/mbhp/mbhp_doutx4.pdf LTC Module: two additional 100 nF ceramic caps for the 74HC00: http://www.ucapps.de/mbhp/mbhp_ltc.pdf SID Module: two additional 100 nF ceramic caps for the 74HC595: http://www.ucapps.de/mbhp/mbhp_sid.pdf SHX8 Module: nine additional 100 nF ceramic caps for the 74HC595 and NJU7304: http://www.ucapps.de/mbhp/mbhp_shx8.pdf (no picture) Best Regards, Thorsten.

I've released a new JSynthLib version which includes an important bugfix for the SID editor: in the official version from http://www.jsynthlib.org sound patches are not editable due to one of those "late changes" (which was never tested by myself) So - please use this version instead: -> http://69.56.171.55/~midibox/jsynthlib/JSynthLib-0.20.0_midibox_mod1.jar.zip In addition, I've improved the wavetable sequencer so that it looks like a tracker when a CC is selected, which plays a note (CC#8..CC#11) Example: In this example, only the third track plays notes ("CC 9: Voice 1 Note" selected) Syntax: Note-Octave/Note#Octave for a common note, e.g. C-2, C#2, D-2, D#2, E-2, ... +++ to hold a note --- to play no note KEY1, KEY2, KEY3 or KEY4 to play an arpeggiated note which is controlled from an external keyboard Example for an arpggiator texture which is played on three tracks: This feature is also useful for beta testers who are already enjoying the TB303 option. It has to be enabled at the upper left corner ("Sound Engine Option", flag 0): Once selected, the first track controls Slide/Gate/Accent (Bit 3..0 are used for accent, bit 4 for gate, bit 5 for slide), the second track plays the notes of voice 1 the third is free for other CC (it can control any sound parameter or voice) Here the whole TB303 patch (works only with v1.7303beta4 or higher) http://www.ucapps.de/midibox_sid/jsynthlib/tb303_patch.gif Have fun! Best Regards, Thorsten.

Hi, I like the idea! :) Best Regards, Thorsten.

There is only one page which lists all MIOS programs: http://www.ucapps.de/mios_download.html Note that these packages also contain the source codes, the code is mostly commented and gives you a lot of informations, much more than you can find in the forum or at my website Best Regards, Thorsten.

from that what the P3 user manual says, these two functions are easy to integrate into the existing MBSEQ engine, and they don't consume much code space. But these are Colins inventions, and I don't want to steal his ideas Best Regards, Thorsten.

Hi, It could help to supply the faders directly from J2, to add 100 nF caps between the +5V/Ground pins of each fader, and in addition a 100nF cap between the wiper pin and ground. But in general, without shielded cables you won't have much luck - over such a distance they are really required. Also the sub-d port you are using is not the best choice for analog signals. Best Regards, Thorsten.

Hi, it shouldn't be too difficult to realise something like this with the MIOS C wrapper, there are also assembler examples (with some comments) which explain, how button/LED matrices can be handled in an efficient way, and they can be easily ported to C Best Regards, Thorsten.

How long is the required pulse width? Best Regards, Thorsten.

The problem is propably, that there are too much options ;-) LEDs can be controlled via MIDI exclusively from the host, or the application can control it directly with normal or toggling behaviour. In your case the first option is the better solution, so that the LEDs always reflect the state of the currently loaded song (no manual adjustments required) Best Regards, Thorsten.

Hi, you could use the inbuild simulator of MPLAB in order to determine the delay (or number of cycles) between each sent bit. At 4 MHz it must be exactly 32 cycles, not more, not less... Best Regards, Thorsten.

Hi, are you really using a quartz/crystal, or an oscillator? I haven't the voltages in my mind, but If you are not sure about the oscillator, you could also connect the clock input of the SID directly to PIC Pin #17 (remove the oscillator before you are doing this!) Best Regards, Thorsten.

Hallo, Touchpads werden nicht unterstuetzt, dafuer wuerde man bspw. eine PS/2 Schnittstelle benoetigen, und die ist im MBHP Konzept nicht vorgesehen. Joysticks sind kein Problem. Gruss, Thorsten.

Hallo, ich tippe auf einen Loetfehler/Haarriss/kalte Loetstelle, genaueres laesst sich aus der Ferne jedoch nicht sagen. Der Update ueber MIDI sollte jederzeit zuverlaessig funktionieren. Wenn man sich die Schaltung genauer anschaut, wird man feststellen, dass die Verbindung zwischen Core und SID nur in eine Richtung geht, der Core bekommt also ueberhaupt nicht mit, ob ein SID angeschlossen ist, oder nicht - deshalb verhaelt sich die Software in beiden Faellen gleich. Gruss, Thorsten.

Hallo Marc, endlich mal jemand, der sich an einen diskreten Receiver traut - die Latenz wird unschlagbar gering sein ;-) Das stimmt nicht ganz, es gibt Ausnahmen. Eine Realtime Message, wie bspw. der MIDI Clock, kann jederzeit gesendet werden, auch zwischen einem normalen MIDI Event. Und dann gibt es auch noch den Running Status, der jedoch bei einem Program Change ziemlich selten angewendet wird. Hier findest Du die Details: http://www.borg.com/~jglatt/tech/midispec.htm ja, es gibt ein Start- und ein Stoppbit. Jedes MIDI byte besteht also eigentlich aus 10 bit. Gruss, Thorsten.

Hallo, das LTC Modul ist evtl. nicht notwendig, Du benoetigst es, wenn die MIDIbox an eine RS232 Schnittstelle angeschlossen werden soll, oder wenn Du der Box MIDI In/Out LEDs + MIDI Thru spendieren moechtest. Die MB64E Firmware unterstuetzt 64 frei programmierbare LED Funktionen, die restlichen digitalen Ausgaenge werden normalerweise fuer die LED Kraenze verwendet. Gruss, Thorsten.

Hallo, der SID kann keinen reinen Sinus-Ton erzeugen, und der Rauschgenerator liefert auch nicht das, was man unter "Pink Noise" versteht. Gruss, Thorsten.

Hallo Basti, da Du bei Deinem "System" sehr grossen Wert auf eine hohe Verarbeitungsgeschwindigkeit legst (ich erinnere mich an Deine vorigen Postings), wuerde ich Adress-Latches statt serielle Register empfehlen - ansonsten wirst Du die verlangte Performance nicht in Griff bekommen. Noch besser waere ein Mikrocontroller mit einer parallelen Busschnittstelle. Gruss, Thorsten.

New design from Finland! :) Jurbo wrote: