TK.

The jitter monitor is a special MIOS application which can be downloaded from http://www.ucapps.de/mios_download.html You could try this out by swapping the 4051 chips. If different MIDI events are sent, you know that there is a problem with the multiplexer. With hexadecimal output debugging would be easier, because the midibox64.ini file (part of mk_syx.zip) contains the mapping. This means: if you map the events to the pot number, you know exactly which analog inputs are sending random values... Best Regards, Thorsten.

The Bxxx indicates the package type, quality and temperature range - more infos can be found in the datasheet (last page): http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1445 Best Regards, Thorsten.

If no analog multiplexers are connected, it's also required to set #define DEFAULT_ENABLE_AIN_MUX 0 (this is the default value, I only wanted to mention this) Best Regards, Thorsten.

Hi, the only crash condition which is currently known for v1.7303 happens, when CC#117 is received with value 13 (this assigns velocity depth to the velocity function). For v1.7a I'm not sure, I can only say that all other known bugs are only fixed in the current beta, and not in v1.7a In order to debug this, you could trace the MIDI output of your MPC with MIDI-Ox - which events are sent before the crash happens? Best Regards, Thorsten.

Hi Matteo, the fastest way to debug this would be to determine, if the configuration of the slave PIC is still ok, is just to plug it into the socket of the master module. I know that you made some experiments with JSynthLib, propably you've unintentionally changed the device ID or something like that (I removed this feature in the latest snapshot to prevent this). By controlling the slave PIC from a master core, you have the savest conditions: you know, that the appr. SID module is working, and you know that the MIDI connection is working. And if the slave doesn't respond, you could just upload the application again just to have a "known" starting point. Best Regards, Thorsten.

I also think that this is the better way, because it will allow you to customize the app completely :) Please don't forget to update your box to MIOS V1.8, otherwise the C application could crash ok, you will find it here http://www.ucapps.de/mios_c_handle_mf.html Sooner or later I will also add an example for accessing two LCDs Best Regards, Thorsten.

-> http://de.wikipedia.org/wiki/Wintendo Gruss, Thorsten.

Zum Song-BankStick: per default ist in main.asm ein 64k EEPROM eingestellt, fuer zwei 32k BankSticks muesstest Du die Konfiguration wie in den Kommentaren beschrieben anpassen. Encoder problem: hoert sich an, als gaebe es ein Problem mit dem Shift Clock, ueberpruefe mal vor allem die SC und RC Leitungen Gruss, Thorsten.

Linux ist leider nicht gleich Linux, bei meiner Fedora Installation (FC2, uralt) liegt das MBHP_USB auf /dev/midi0, midi1, midi2, midi3 usw... mit amidi muss ich da nichts mehr einstellen. Du koenntest mal MIOS Studio ausprobieren (vorher evtl. noch Java installieren), damit sollte die MIDI Interaktion wesentlich sicherer funktionieren, als mit den etwas angestaubten Scripten. Im Notfall dann vielleicht doch mal Wintendo booten, und von dort aus MIOS Studio starten Siehe auch http://www.ucapps.de/mios_bootstrap_newbies.html Gruss, Thorsten.

Seems that you made the same experiences with students like me ;-) In the meantime, the students which I support have to program in C instead of assembly language, it turned out that the results are better re-usable in future projects, also the quality is better. It's very similar with the MB64E application - the focus was to get as much features as possible into a single app, and not to allow easy adaptions. The time it takes for me to describe how to change certain things, or how certain mechanisms have been implemented, is so extremely high, that I cannot really help here. Especially if the code has already been modified - there could either be a resource conflict (which happens very often when more than one person works on a bad documented assembler project), or something important has been removed or changed (unintentionally) On the other hand: when I read, which features are required for your (interesting) device, then I would say, that this can be written within one hour by using the MIOS C wrapper. There are some existing examples, which help: Button handling: see http://www.ucapps.de/mios_c_send_din.html LED handling: see http://www.ucapps.de/mios_c_set_dout.html LCD handling: see http://www.ucapps.de/mios_c_lcd_out.html Scaling (0-100) is described here: http://www.ucapps.de/mios_c_send_range.html The motorfader handling is similar to this example: http://www.ucapps.de/mios_c_send_ain.html I could create a new one especially for motorfaders if required Not really, in the ain64_din128_dout128_v2_0 application, a touch sensor should behave like a button (it should send Note On/Off events). But I just have noticed, that the touch sensitivity is set to 0 by default (see main.h). This wasn't a good idea, because this value disables the touch sensor pulse at J14. I will set it to 3 next time... Best Regards, Thorsten.

In general you only need to adapt the port configuration (search for TRIS within the source code), you may also want to remove the shift register configuration, since this is MIOS specific stuff. Other changes are normaly not required. The program which should be uploaded needs two "goto <start-label>" instructions beginning at 0x0000, the first one will be overwritten during upload Best Regards, Thorsten.

Yes, the app cannot handle with "DEFAULT_NUMBER_ENCS 0", so this number must be greater than 0 I don't understand, why you want to stick to an older version. I've no idea what could be wrong there, I don't think that the changes you are showing me in the posting could cause the problem, but in general it would be less effort just to use the latest and greatest version. If you want to find out, which changes have been made in the configuration, just compare your files against the original files of the older release - it's still on the server. In order to solve the "strange LCD behaviour" issue, I would propose to upload a test application like "ain64_din128_dout128_v2_0" - check if any digital or analog input delivers unstable signals (e.g., maybe the touch sensors?) Best Regards, Thorsten.

lade mal den MIDImon auf, damit kannst Du ueberpruefen, ob ueberhaupt MIDI Events ankommen Gruss, Thorsten.

Hallo, wenn noch nicht einmal die Gate LED angeht, wird der Fehler in der digitalen Domain liegen. Zunaechst einmal wuerde ich die MBCV Einstellungen checken (Note Mode, MIDI Channel, etc...) Sind diese ok, dann loete nochmal die Leitungen zwischen Core und AOUT Modul nach, vielleicht haben die ja auch noch einen Wackelkontakt (siehe auch http://www.ucapps.de/midibox_cv/mbcv_aout_interconnections.pdf) Auch die GND und VDD Eingaenge am MAX525 koenntest Du mal ueberpruefen (hier sollten 5V anliegen) Gruss, Thorsten.

No really, they will co-exist with such touchscreens Here the proof: (a picture from the future ;-)) Best Regards, Thorsten.

(short sidenote: MIOS only has to be uploaded once, every application upload will overwrite the previous one) of course, but this shouldn't be the problem, why the LCD isn't working The core gets a watchdog timer reset. Since the LCD driver can handle with timeouts (eg. if the LCD is endless busy), it seems that your display doesn't react like expected. You could try the following: disconnect the D7 line (at pin 40 of the PIC) - does the reset still happen? It shouldn't Then you should check the control lines to the display again (RS, RW and E) - if one or more of these lines are swapped, such random effects can happen! Another point is, that the pin markers could be wrong (am I too persimistic? No, in fact I got such a display some time ago, it was a 1EUR display from Pollin ;-)) - if you are unsure, just try all combinations for the RS/RW/E pins. Or better: just connect them in the same order like shown here: http://www.ucapps.de/mbhp/mbhp_lcd.pdf, because normaly the order of control/data pins is always the same, I don't know any display which has a different pin order Best Regards, Thorsten.

Hi Rigo, are the components already mounted on a metal penal? Then it could be required to ground the outer metal case of the faders. It would also be interesting, which jitter is displayed by the "jitter mon" application Best Regards, Thorsten.

Hi Jaicen, I know several people who have used the MIDIO128 application for triggering drum modules Best Regards, Thorsten.

The bootloader doesn't run on a PIC16F device, and especially with a PIC16F84 you won't have much fun (too small memory, several instructions, peripherals and mechanisms not available) Best Regards, Thorsten.

Hi, such a behaviour was never reported before. It would be interesting, what happens, when you are loading the lcd7_clcd driver example application into the core? (Propably you have to upload the code with the first level BSL, within 2 seconds after power-on) Best Regards, Thorsten.

ca. 2 Mbps Best Regards, Thorsten.

in mb64e_ledrings.inc nach "addlw enc_offset" suchen, und durch "addlw enc_offset + 0x40" ersetzen Gruss, Thorsten.

Hallo Andreas, Jein - das LTC Modul dupliziert den MIDI In und Out Port (Signale werden ueber Inverter gebuffert, so dass sie die Ports am Core Modul nicht belasten). Wenn Du drei MIDI Out Ports benoetigst, muesstest Du lediglich den MI und MO Pin des LTC Pins zusammen an den MO Pin des Core Moduls anschliessen... und die Masseverbindung nicht vergessen! Exakt! MIDI-Ox und MIDIbox spielen Ping Pong. Oeffne mal das Routing Fenster von MIDI-Ox, dort kannst Du die Verbindung zwischen MIDI In und Out entfernen. Eigentlich sollte man die beiden Massen an einem zentralen Punkt zusammenschliessen (deshalb hat das AOUT Modul bspw. gleich drei Massepins). Von diesem Punkt kann man dann zum Netzteil verzweigen. Dadurch werden zwei Dioden in den Gleichrichtern kurzgeschlossen, doch das "tut ihnen nicht weh". Wenn der Gleichrichter eine Gleichspannung erhaelt, dient er lediglich als Verpolungsschutz. Du koenntest eine 15 polige Sub-D Stecker/Buchse Kombination wie bei einem Gameport verwenden. Die Kabel sollten jedoch nicht besonders lang sein (hier habe ich keine genauen Erfahrungswerte, aber ich wuerde mal sagen: 1m maximal!) Gruss, Thorsten.

All unused analog inputs must be connected to ground (the last C is a writing error ;-) Other possible errors: a bad connection to the DINs, jittering analog values (improve wiring to the faders), or just a unwanted MIDI loopback with your host application (are you using the internal merger?) Best Regards, Thorsten.

On the other hand: the full +/-5V range is not required for the CEM3378 anyhow, and I'm also not sure, if a buffer OPAMP is really useful I remember, that during my experiments some weeks ago I added an additional pot as voltage divider between the AOUT_LC outputs, and the resonance/CutOff input of the filter in order to reduce the control range. This remembers me, that I wanted to determine the best fitting divider values for my own final board (which will be a quad-filter) - so, i can give you more infos soon Best Regards, Thorsten.