TK.

You don't know the good 4051 yet, therefore just swap two of them in the hope to see any differences The jitter monitor allows you to select the analog input which should be measured with two buttons. One button, which increments the number, another which decrements the number. See the main.asm file, on which digital inputs they are expected (you could also change the digital pins if required) Best Regards, Thorsten.

Thanks! Yes, I meant seconds (statement corrected for forum search function) I just had another idea: an even more secure way to upload new code is the following: 1) send a "bad" block and wait for error response 2a) if MIOS is uploaded (code starts at 0x0000), upload a dummy block which contains two "reset" instructions, located at 0x0000 2b) if the .hex file contains some code which is located in between 0x100-0xffff (0xffff because of PIC18F4620), upload a dummy block which contains one "reset", located at 0x3300 2c) in all other cases (no code between 0x0000-0xffff) just upload the data and ignore this algorithm 3) don't continue if this dummy block hasn't been uploaded correctly, because it should ensure, that no code is executed until the complete .hex file has been uploaded successfully 4) upload all blocks execept for the block which contains the "reset" instruction(s) 5) at the end, overwrite the block which contains the "reset" instruction(s) This algorithm ensures, that uncomplete code will never be executed, if something unexpected happened during the upload phase (e.g. low power, disconnected MIDI cables, MIDI interface driver crash or whatever) If required, I could try to implement this into MIOS Studio by myself (in this case, please send me the most recent source code) Best Regards, Thorsten.

Zum Poly/Legato Problem - ich kann mich daran erinnern, dass mir das auch mal passiert ist. Die Ursache war, dass ich den MIDI Stecker abgestoepselt hatte, waehrend noch ein paar Noten gehalten wurden. Dadurch war der Notestack belegt, und Legato funktionierte nicht mehr. Der Polymode sollte in diesem Fall nur noch Noten fuer nicht belegte Stack Eintraege spielen. Es handelt sich hierbei um ein generelles Problem mit Synthesizern, deshalb bieten manche einen "All Notes Off" CC, doch dieser ist bei der MBSID ja bereits fuer eine andere Funktion belegt. Eine weitere moeglichkeit waere, dass man saemtliche Noten, die in Frage kommen, anspielt und wieder loslaesst - ist aber auch nicht gerade bequem. Mir ist gerade eingefallen, dass ich den Stack auch einfach beim Umschalten des Patches loeschen koennte - werde ich wohl in die naechste Version einbauen, Zu den IDs: verschiedene IDs machen vor allem dann Sinn, wenn mehrere MIDIboxen an einem einzigen MIDI Out angeschlossen sind, denn nur so kann man gezielt Code in eine Box einladen. Doch selbst wenn jede Box ihren eigenen MIDI Port hat, macht es u.U Sinn. Bei mir kam es z.B mal vor, dass ich in der Eile die MIDIbox SID Firmware in meine MIDIbox FM eingeladen habe. Dadurch wurde der BankStick neu formatiert, dabei wurden die selbstgemachten FM Patches unwiederuflich ueberschrieben. Seitdem hat bei mir jede MIDIbox ihre eigene ID, um die Wahrscheinlichkeit fuer solch eine Panne zu minimieren. Gruss, Thorsten.

The "sid_random" application gets use of an external "real random" generator In C, the "software random generator" in SEQ_CORE_GenRandomNumber function would look similar to this: [code] unsigned char random_seed_l; unsigned char random_seed_h; void gen_random_number(void) { unsigned int tmp = random_seed_l * random_seed_h; random_seed_l = TMR0L + (unsigned char)(tmp & 0xff); random_seed_h = 0x69 + (unsigned char)(tmp >> 8); } [/code] Maybe with some additional XOR operations the random value distribution could be improved, but I'm not an expert on this topic... Best Regards, Thorsten. [/code]

Hi John, this is a bug, the variable should be declared as "unsigned int". Propably the measure will restart at 0 once 256 has been reached (at 140 BPM this takes 7.3 minutes, therefore I never noticed this ;-) Best Regards, Thorsten.

Hi John, yes. And you would have to overwork some parts of the j5_din source, since it uses macros, which are not compatible with gpasm (this reminds me, that I wanted to search for a solution for this compatibility problem) I guess, that the code in J5_DIN_Update wouldn't run much longer if written in C, because there isn't that much data handling. It should look similar to this: unsigned char j5_din_status, j5_din_status_changed; void j5_din_update(void) { unsigned char tmp = (PORTA & 0x0f) | ((PORTA & 0x20)>>1) | (PORTE << 5); j5_din_status_changed |= j5_din_status ^ tmp; j5_din_status = tmp; } [/code] Best Regards, Thorsten.

Hi Adam, reg. features, here is one I would like to see. :) Somebody had problems with the program upload directly after power-on. The core already sent out an upload request, but the voltage hasn't reached the required range before MIOS Studio started to upload the first block. For some reasons, something went wrong and the core crashed (ramp-up phase is always mysterious) The upload procedure could be made more stable - either o by adding a < 2s delay after an upload request, before the first block will be sent o or (this is what I would prefer) by sending a known "bad" block (e.g. a write block with 0 bytes content), and to wait for the expected error response. This would reset the timeout value, so that the core is ready for receiving again under relaxed conditions (MIOS Studio has 3 seconds to send the first "good" block) Best Regards, Thorsten. /Edit: mS replaced by s

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.