TK.

Hi, First I must say, that I'm happy about the fact, that you've looked into the ucapps.de website before asking these questions. I can read this between the lines, and I think it must be highlighted, because most people just ignore the existiting documentation (thus I mostly don't feel motivated to bring it up-to-date) yes, thats correct. The ain64_din128_dout128 application demonstrates these capabilities. This is just a simple example application, but it works sufficient so long your PC software is able to "learn" MIDI events. thats partly correct. The restrictions exist, because I wanted to prevent an update of existing tools (not written by myself). But in general it's possible to write a new application which gets use of all capabilities provided by MIOS. A lot of combinations are possible, and I hope that sooner or later the users will provide their fully customizated controllers to the community. there is a hidden feature in the MB64E application which allows you to get use of the AINs, as well of the motorfader feature (see ChangeLog and comments in main.asm file) Exactly! (with MIOS 0-1023: 10 bit resolution) In general you have to take into account, that the serial DIN chain is scanned each millisecond. This is fast enough for buttons/switches/encoders, since the resulting reaction (normaly a MIDI event) isn't much faster (the transfer of a 3-byte MIDI event takes 960 uS). So, your question is a little bit too abstract. What kind of data do you want to handle with the DIN pins exactly? How fast does it change? Yes, this page http://www.midibox.org/dokuwiki/doku.php?id=midiboxlc contains a link to the Logic Control spec yes, but I must say, that these terms are mixed very often in MIDI controller specs. Even in the MIDIbox LC application, I've called the rotary encoder "Jog wheel" to keep it aligned with the Logic Control spec. Normaly it should be differed between a jog wheel, which is just a multi-state switch, and datawheels/rotary encoders, which are techically called "quadrature encoders". Best Regards, Thorsten.

Der Regulator war falsch gepolt (linkes und rechtes Bein vertauscht). Vergleiche die Schaltung mal mit dem PCB Layout des Core Modules - der 7805 hat das gleiche Pinning wie der 7809. Am linken Beinchen wird die Eingangsspannung angelegt, in der Mitte ist Masse, auf der rechten Seite die regulierte Ausgangsspannung. Gruss, Thorsten.

Zum bauen eines neues .hex Files kannst Du den MPASMWIN auch direkt aufrufen, das ist einfacher und weniger fehleranfaellig (ich traue dem Wizard nicht). Eine Anleitung gibt es hier: http://www.ucapps.de/howto_tools_mpasm.html Mit deiner derzeitigen Variante wird es ein Problem geben (welches dann auch im main.err File erscheinen wird): das Label USER_MPROC_NotifyReceivedEvent existiert nun zweimal, es darf aber nur einmal gesetzt werden. Ein Label ist nichts anderes als ein Verweis auf eine Adresse. Ein weiteres Problem: MIOS springt auf USER_MPROC_NotifyReceivedEvent, wenn ein neues Event empfangen wurde. Von dort aus wird die Funktion CV_MIDI_NotifyReceivedEvent aufgerufen, anschliessend verzweigt das Programm zu "USER_Tick". Der Code dahinter wird also niemals aufgerufen. Stattdessen muesstest Du den zusaetzlichen Code also vor das rgoto setzen. Oder noch besser, direkt unter das USER_MPROC_NotifyReceivedEvent Label (also vor dem call und vor dem rgoto) - dies ist auch der Grund, warum ich das Label in meinem Codeschnippsel angegeben habe Gruss, Thorsten.

Hi Goule, there are several possibilities. By using the MIOS_DOUT_PinSet function, you can address the appr. outputs with pin number 8-15. With the MIOS_DOUT_SRSet function, you can write all 8 pins with a single function call - the SR number is 1 in this case (we are counting from 0) A pintable can be found here: http://www.midibox.org/dokuwiki/doku.php?id=din_dout_pintable Best Regards, Thorsten.

It could be a short which is hard to find. You can ensure that the RD3 pin (pin #22) is still working by lifting it from the socket, so that it doesn't have contact with the PCB anymore. Is it possible to switch between 0V and 5V now? Best Regards, Thorsten.

Das ist uebel! Es wird Zeit, dass ich im Wiki mal eine Blacklist aufsetze, auch die Soundblaster Audigy hat Probleme (die sich jedoch mit einem Treiberupdate beheben lassen) Theoretisch gaebe es die Moeglichkeit, die Blocklaenge auf bis zu 8 Bytes herunterzusetzen. Doch leider habe ich gerade die Sourcen zur aktuellen MIOS Studio Version nicht parat - Adam moechte noch ein paar Schoenheitskorrekturen anbringen, bevor er sie mir schickt.... Gruss, Thorsten.

By adding following code to the debug trigger hook: USER_MPROC_DebugTrigger goto SID_BANK_FormatStick [/code] it's possible to trigger the format function via SysEx (e.g. with MIOS Studio :)) Best Regards, Thorsten.

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.