TK.

no, you only need to copy the curve flags into temporary registers, which then can be accessed from the io table Chriss did this some time ago, see also http://www.midibox.org/midibox_gallery/chriss8.jpg So, before re-inventing the wheel, you could ask him. And please: add some step-by-step instructions to the Wiki, so that this information doesn't get lost. Best Regards, Thorsten.

Hallo Tubbu, wenn der Bootloader den Block nicht komplett erhaelt, liefert er normalerweise eine Fehlermeldung. Wenn jedoch noch nicht einmal das abschliessende F7 eingetroffen ist, fuehrt das zu einem Time Out, und der Upload Request wird erneut gesendet. Der Core verhaelt sich also korrekt. Er sendet zumindest manchmal eine Checksumme zurueck, was darauf schliessen laesst, dass die MIDI Verbindung hardwaremaessig funktioniert. Einen Fehler in MIOS Studio halte ich eher fuer unwahrscheinlich, ich wuerde auf Anhieb erstmal auf das MIDI Interface tippen. Mach mal den Loopback Test: PC MIDI In and PC MIDI Out anschliessen, und bspw. mit MIDI-Ox ein laengeres SysEx File verschicken. Du koenntest bspw. das mios_v1_8.syx hernehmen. Das SysEx tool von MIDI-Ox bietet auch eine "Compare" Funktion, damit kann man die eingegangenen Daten ueberpruefen. Den Loopback Test kann man auch noch etwas weiter treiben, und die Daten durch den Optokoppler schicken. Hier ist der entspr. Schaltplan: http://www.ucapps.de/howtodebug/mbhp_core_extract_io_loopback.gif Gruss, Thorsten.

Hi Tomcody, this could be a problem with the SC connection, this is a clock signal which shifts the data through the serial chain. If this signal is not working (e.g. due to a short), the core will always get the state of the first pin in the chain, therefore you see a lot of MIDI events triggered by a single button. I've written an application which allows to debug this, it can be downloaded from http://www.ucapps.de/mios_download.html, search for "srio_interconnection_test_v1" The details are explained in main.asm Best Regards, Thorsten. FAQMARKER

Hi Wilba, the old settings are still available, since this change only affects the formatting of new (unwritten) EEPROMs. If you want to test this, you could change the "magic numbers" in app_defines.h in order to force a formatting. Thereafter you have to change them back to prevent an unintended formatting on firmware updates So long the control surface is enabled, it is not possible to change the MIDI channel via SysEx, because the CS handler "owns" this value. I will add this to the docs. Best Regards, Thorsten.

before it will be forgotten: FAQMARKER

Hi QBAS, I'm not an expert in this topic, and I can not help that much for finding the perfect implementation to control a keyboard matrix with velocity sensitivity, especially because I don't own such hardware. I created an assembly based example which demonstrates, how to scan a matrix (-> sm_example2_v1.zip, see MIOS download page). The latency is about 80 uS for 64 buttons. The code for velocity detection needs to be added. If additional switches and encoders should be used in parallel, it would be required to connect the DIN/DOUT chain to seperate pins (thats possible, the pins are defined in sm_fast.inc) - I would propose J6 and J7, since these ports are designed for such purposes Best Regards, Thorsten.

Regarding the scaling routine: Goule made some experiments with it using C - it's mostly easier to program this in C first, because modifications can be made faster. Once the perfect algorithm has been found, we can help you to port this to assembler in order to allow an integration into MB64 -> http://www.midibox.org/forum/index.php?topic=5270.0 Best Regards, Thorsten.

Hi Ludo, there is no documentation available how to do this, the only info can be found in cs_menu_leds.inc It's not a simple modification, and it's not easy to explain if you never did such changes before Best Regards, Thorsten.

Hi, maybe it makes sense to check the Windows driver of your gameport first. This can be done with a loopback test - you have to connect pins 12 and 15 of the gameport together. Thereafter send a MIDI event (e.g. a note with the virtual keyboard of MIOS Studio or MIDI-Ox), it should be received and displayed on the Input monitor Best Regards, Thorsten.

Der Core laesst sich in MIOS-C programmieren (es wird also keine GUI zum Konfigurieren oder aehnliches geben). Das bedeutet wiederum: alles ist moeglich, selbst die abgefahrenen Sachen ;-) Gruss, Thorsten.

Important question: do you notice the same problem with missing notes, when the MIDI Out of the master is not connected to any MIDI device? (only to the slaves) Best Regards, Thorsten.

Hallo, so etwas befindet sich gerade in der Mache: (nicht von dem USB Kabel verwirren lassen, das MIDI Processing laeuft auch ohne USB) Mehr Details dann nach meinem Urlaub... Gruss, Thorsten.

In der Preset Library befinden sich ein paar wavetable sounds, sie sind mit "WT ..." bezeichnet Gruss, Thorsten.

don't know. Does the volume drop very fast, or slowly? The effect could also be related to the SID envelope bug, what are the ADSR settings of the sound you are testing? I would propose to measure the volume amplitude with a sampler. Just record a sound and check the dB settings in the waveform window of your sampling program. In order to 100% ensure, that the audio in of your soundcard doesn't falsify the results (who knows...), always take the same audio input. Thereafter swap the SIDs and record it again - this should give you a good comparison. Btw.: you could send me the samples in .mp3 format, I will upload them to the midibox server so that everybody can get an impression. For the "missing sound" problem, there is also another good test which ensures that the slaves are working independent from the software. Currently the J11:MI lines of the slave are connected to J11:MO of the master. When you connect these lines to J11:MI of the master instead, the slaves will receive exactly the same MIDI data like the master. This isn't a useful setup (because slaves won't receive patches from the master anymore), but it gives some important input for finding out the root cause Best Regards, Thorsten.

only by programming a scaling routine into the application... Best Regards, Thorsten.

Well, this shows again, that somebody cannot check the LCD connections often enough... To your offer for new documentation: we are going to improve the Wiki in order to put more newbie friendly information in there. The goal is, to have ucapps.de as "reference manual" site (maintained by myself), and the Wiki as "user manual" site (maintained by the users). Improving the Wiki is very easy (once the new version is public, the old one doesn't work anymore), and if you are missing a certain tip and you know the solution, it will be very easy to add something without asking others :) LCD mod: just have a look into the main.asm file, it contains all the settings. In your appr. case, search for "DEFAULT_LCD_SIZE", set it to 2 (4x16), build a new .hex (see http://www.ucapps.de/howto_tools_mpasm.html), upload it to the core. You haven't answered yet, if the upload is working (because based on the previous posts, it doesn't). So, if you don't see any change after the upload, you need to troubleshoot your MIDI In port! Best Regards, Thorsten.

Hm... volumes are lower at the slave side, MIDI (or PIC) doesn't work stable - could it be a voltage problem? Have you measured the voltages at the Vdd/Vss pins of SID and PIC? Note: don't measure the +5V/+12/+9V voltages against the common ground, probe them directly on the pins - because it could also be a ground problem! Best Regards, Thorsten.

So, here we've already found the problem: you haven't mentioned that you've uploaded the application after MIOS. This propably means, that MIOS hasn't been received by the core, because in this case the application would be disabled, and AIN/DIN wouldn't work until you are uploading e.g. midibox64 Let's doublecheck this: enable the "use feedback from core" option, upload the lcd7_clcd.zip application and copy&paste the messages of the hex upload window into this article. This gives me the information, if your computer MIDI Out -> core MIDI In connection is working. In addition this application will bypass the ID setting, and print a message directly on the LCD (a good test application) You should not receive AIN/DIN events anymore after the upload! For the case that the upload stucks (since the core doesn't response), you can troubleshoot the MIDI In port based on these step-by-step instructions: http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

the core should send the checksum, but it doesn't. This is visible in the log, as well as in the MIDI in monitor. See also this snapshot: http://www.ucapps.de/mios/mios_studio4.gif Just follow the MIDI troubleshooting guide, it really helps! Best Regards, Thorsten.

The goal should be to have a low resistance (impedance when we are talking about R/C/L) - than higher the impedance, than higher the jitter. This means, that an additional resistor will worsen the results. I would suggest to search in the web for this topic, it cannot be explained so easy (maybe somebody else knows some good links?) Best Regards, Thorsten.

I don't see any problems... Best Regards, Thorsten.

I can see three things: - you computer receives an upload request (MIDI Out of the core is working) - your core never response to a upload block (MIDI In of the core propably not working, or a problem with the MIDI Out of your computer) - you've disabled the "use feedback from core" option of MIOS Studio, therefore you get a "Upload process complete" message - in this mode MIOS Studio doesn't check if your core has ever received the data correctly, therefore it says "complete" Proposals: - troubleshoot your MIDI In port -> see http://www.ucapps.de/howto_debug_midi.html (in most cases, just only the two connections to the MIDI In jack are swapped...) - don't forget to enable the feedback option of MIOS Studio again, because without it can be dangerous Best Regards, Thorsten.

It is an impedance problem, because the 4051 multiplexers have a resistance which need to be added to the impedance of the sensor itself. It's not a software problem! Maybe a small amplifier helps to improve the output signal Best Regards, Thorsten.

The changes have to be made in seq_buttons.inc Search for "SEQ_Button_Fast", add a label like "SEQ_Button_Fast_Direct" below the first #endif, and before the "data wheel" comment. Now you can add following code below SEQ_BUTTON_LayerA (as an example): bcf SEQ_MODE0, SEQ_MODE0_FAST_ENCODERS, BANKED call SEQ_Button_Fast_Direct Best Regards, Thorsten.

All known bugs are now fixed in the beta14 version. I hope that no new ones have been added ;-) -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta14.zip Best Regards, Thorsten.