TK.

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.

yes! Best Regards, Thorsten.

Hi Matthias, it's very interesting, that the other PC detects the USB chip! Would be interesting, if the OS version, or the USB host is the reason. However, I think that the "(2131Q/2131S/2135S)-EEPROM MISSING" selection is the right one, but I guess that it doesn't really matter, because all of them are pointing to the same driver file. It's propably only the device description that you are selecting here Best Regards, Thorsten.

The MIDImon is an exception, it uses the analog port as digital inputs. Here I prefer pull-ups to make it similar to the DIN module Main intention of the AUAIMBCTG rule is to have "stable" values, and to prevent floating inputs... Best Regards, Thorsten.

Hi Christian, yes, it's correct, that code cannot be fetched from an external memory. The PIC doesn't provide a generic parallel interface anyhow, so that your software has to handle external bus accesses via the GPIO pins in the same way like it accesses the interface of the LCD. This costs time, but in most cases it's fast enough. For you MIDI controller project, the CPU load will be very relaxed anyhow when I compare it to applications like the MIDIbox SID (as an example), therefore you could even use a serial flash or EEPROM, it will still be fast enough. Short calculation: assumed that you are planning to use a graphical 240x64 LCD (too bad, that you didn't mention the display you are planning to use, it would simplify my answer). The whole display consists of 15360 pixels, makes 1920 bytes. Assumed, that you are fetching the graphical data from a serial EEPROM (like my beloved "BankSticks"), it would take ca. 30 uS * 1920 = ca. 60 mS to write the whole screen. This is fast enough, because I don't think that you want to playback a movie? And even if latency does matter, you could split the display update into several parts (preemptive multitasking), so that on each "mainloop" only one or two lines are updated. By doing so, you would achieve an overall latency which is still less than 1 mS If you are planning to use a character LCD, then you don't need to consider such things... Even when you are writing the application in C, it doesn't matter, that (for example) the PIC18F452 doesn't provide enough code memory for your project. Because by using clever data structures, you don't need so much code anyhow. Menu structures, character strings, MIDI events and streams, parameter values or whatever can be easily saved in (and accessed from) an external non-volatile memory. The program itself only needs to know, where the informations are located (even such infos could be saved in the ext. tables). Sending different MIDI events depending on the menu just only means, duplicating the external data tables... Such methods have also another advantage: by using a socket for the external memory (like the "BankStick"), you could allow the user to switch between different setups (it doesn't matter, how many synths are part of the setup), or to make backups, or whatever. It's also easily expandable by multiple memory devices. Best Regards, Thorsten.