TK.

The MIDI channel is combined with the MIDI event type. We are using 0x90 for Note Events over MIDI channel #1 To change the channel, use: 0x91 for MIDI Channel #2 0x92 for MIDI Channel #3 0x93 for MIDI Channel #4 0x94 for MIDI Channel #5 0x95 for MIDI Channel #6 0x96 for MIDI Channel #7 0x97 for MIDI Channel #8 0x98 for MIDI Channel #9 0x99 for MIDI Channel #10 0x9a for MIDI Channel #11 0x9b for MIDI Channel #12 0x9c for MIDI Channel #13 0x9d for MIDI Channel #14 0x9e for MIDI Channel #15 0x9f for MIDI Channel #16 Best Regards, Thorsten.

Timing inaccuracies can be emulated on a MB808 by letting the analog input for swing pot unconnected (don't clamp it to ground! ;) Best Regards, Thorsten.

No, thats fine - the crystal is oscillating with high frequency, you won't be able to measure this with your multimeter, and probably only read the RMS value (or something similar) Best Regards, Thorsten.

Habe den Schaltplan nun geaendert, und hoffe, dass damit alle Klarheiten beseitigt sind: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf Gruss, Thorsten. P.S.: die CAN Rx/Tx Beschriftung habe ich mit Absicht entfernt, denn sie schien bei Newbies wohl auch nur unnoetige Fragen aufzuwerfen... ich sollte wohl mal eine Experten-Ansicht in uCApps einbauen ;)

it's fixed now... Best Regards, Thorsten.

The "official" J5_IO driver is now available at http://svnmios.midibox.org/trunk/modules/j5_io/ Note that the integration hints described in the README.txt are intended for the future programming environment. So long you are working with the old C wrapper approach, you need to copy j5_io.asm, j5_io.inc and j5_io.h into your project directory, and add j5_io.asm to your MAKEFILE.SPEC Best Regards, Thorsten.

Irgendetwas machst Du anders als die anderen... hat jeder PIC eine eigene MIOS Device ID? Gruss, Thorsten.

I received my kit, and was positively impressed about the PCB - very good work! :) Since I'm currently busy with MB808 and some other stuff (e.g. Seppoman's Stereo SSM2044 filter), I won't find the time to populate the board in the next weeks. But once this has been done, I will be able to provide a modular driver for MIOS based hardware quickly... I'm also planning to integrate support for Stribes into projects like MBSID V2 and MBSEQ V3 (for my own interest ;)) Creating an application for softpots will be extremely simple :) Best Regards, Thorsten.

Please note, that Wilba's .inc file is not the latest one (e.g. $Id: $ header is missing) Never overwrite files, only change them directly within the repository Best Regards, Thorsten.

It could also be a nice exercise for you to change the original file in the repository (special_characters.inc), because I like the changed layout as well :) Best Regards, Thorsten.

Works fine! Thank you for starting to improve the documentation! Best Regards, Thorsten.

A while ago I changed the behaviour of the ALL function based on user requests, so that it affects all steps and not only the selected, which is especially useful while editing CC tracks. Now people are starting to request the old behaviour again.... ;) ris8_allo_zen0's proposal is excellent! It would be the perfect solution to tell the UI exactly, which steps should be modified, thats much better than changing only the gated steps (which doesn't work on CC tracks), because it allows you to quickly specify a certain "pattern" (of steps within the layer) which should be set to a specific value. I will consider this in the next release. As you know, I'm currently busy with MB808, so it could take some weeks. But you can be sure that the idea won't get lost (and in addition, we will get new features which have been implemented during MB808 development :)) It would be interesting to me, if there are more use cases for a "focus" function, beside of using it in conjunction with the "All" button. Best Regards, Thorsten.

It's probably related to the MIDI In port of your MIDI interface (of PC or whatever platform you are using). If the middle pin isn't disconnected at the MIDI In side, there is a potential risk for a ground loop, which can result into a 50 (or 60) Hz buzz. In order to solve this, you could disconnect the ground connection to the middle pin of the MBHP_CORE MIDI OUT port. It doesn't really hurt Best Regards, Thorsten.

Haha, you really want to transfer a whole patch via NRPN? ;) Not only access to the mod matrix is missing, there are much more parameters only available via SysEx for good reasons. If you would like to change the whole patch, it would take ca. 5 seconds (!!!) via NRPN, while it takes ca. 300 mS via SysEx. There are also SysEx commands which allow you to modify individual locations (e.g. only mod matrix parameters) - therefore SysEx is provided as the only complete solution. If you want to provide a flawless user interface, I strongly recomment you to learn how to handle SysEx with your software. Best Regards, Thorsten.

Ich komme irgendwie mit der Fehlerbeschreibung nicht klar. Man kann bspw. waehrend der Laufzeit die SID Spannung wegnehmen, und wieder anlegen, der aktuelle Patch geht dadurch nicht verloren, denn die digitale Spannungs-Domaene wird ja mit 5V versorgt - und in dieser Domaene befinden sich die Konfigurationsdaten (mal ganz einfach formuliert) Ausserdem werden die SIDs erst 2 Sekunden nach Startup konfiguriert. Vorher wird auch nochmal die Reset Leitung aktiviert, was zu einem definierten Start fuehrt. Die Frage ist also, wie sich die SIDs genau verhalten, wenn sie mal "nicht anspringen". Hoerst Du bspw. ein Geraeusch, wenn Du vom CS aus den Patch wechselst? Gruss, Thorsten.

A very helpful demonstration of the effects, Matrigs! :) My first impression: it sounds like a logical defect inside the SID chip, because no parts of the firmware which could "bend" the sound output so much. On the other hand: while reading your previous posting, it isn't clear if you already fixed the 74HC595 issue. If there are shorts or bridges or faulty connections which can cause an improper logical level (should be either 0V or 5V +/- ca. 0.3V), the SID won't "receive" correct data and will output random sounds - or nothing. Like demonstrated in your MP3 Best Regards, Thorsten.

For MBLC: you only need to invert MIOS_PARAMETER2 within the USER_DIN_NotifyToggle function, before it branches to LC_BUTTON_Handler This can be done with "comf MIOS_PARAMETER2, F" Best Regards, Thorsten.

When I read your initial question, I guess, that the 0x40 was confusing you. The 8th and 9th byte are the address, 0x4000 means: BankStick, offset 0 Best Regards, Thorsten.

When you are starting at the 12th, and not at the 13th byte, it makes sense: First 8 bytes of BankStick content: 0x04, 0x4b, 0x53, 0x2d, 0x35, 0x2f, 0x30, 0x39 Binary representation: 00000100 01001011 01010011 00101101 00110101 00101111 00110000 00111001 Scrambled SysEx Stream: 0x02 0x12 0x6a 0x32 0x69 0x54 0x5e 0x30 0x1c 0x4c 0x06 Binary representation: 0000010 0010010 1101010 0110010 1101001 1010100 1011110 0110000 0011100 1001100 0000110 Now we concatenate the binary values to a single string (remove spaces) 00000100010010110101001100101101001101010010111100110000001110010011000000110 And split it into 8bit chunks: 00000100 01001011 01010011 00101101 00110101 00101111 00110000 00111001 ... Convert it back into hex (or decimal) values: 0x04 0x4b 0x53 0x2d 0x35 0x2f 0x30 0x39 Surprise! ;) Best Regards, Thorsten.

Doublepost http://www.midibox.org/forum/index.php/topic,10842.0.html

No - did you already follow the DIN troubleshooting guide? -> http://www.midibox.org/dokuwiki/din_module please ignore these files, they are part of the release package by accident. They won't work with the current firmware anymore. Please use the released presets, which can be found at the MIDIbox FM page It's described in the README.txt of preset_patches_20050212.zip Where did you found the addressing A/B/C? No, A0..A2 are three address selection input. There are 8 possible combinations for 8 possible addresses Each BankStick requires a unique address, otherwise the firmware won't be able to access any. It could even crash! See also the MBHP_BANKSTICK page for a schematic which describes the different address configurations Maybe this info already helps you to solve the issues Best Regards, Thorsten.

Enjoy the show! :) Z3d6U9ahh_E

So, it's installed under /usr/local/bin now, I guess you already doublechecked this? And the permissions are set properly, so that your user account can execute the file without sudo? You checked that $PATH contains /usr/local/bin? That I don't know, what else could be the reason... :/ Normaly the installation is really straightforward... Best Regards, Thorsten.

Oh yes, of course! So, the firmware wasn't working, because it wasn't completely programmed into the flash. Random things can happen then. It's also possible, that the upload errors happened because the firmware image was corrupted before (this explains, why the testtone app upload wasn't successfull) Just to highlight it again: random things can happen then - things which are hard to diagnose via remote ;) A corrupted firmware upload can be "repaired" the following way: reset the box, and upload the firmware via first level bootloader (so, start the transfer within 2 seconds after power-on) This should give you a clean upload. Not really, because if the application upload wasn't stable, it could be an issue with your MIDI interface. What happens when you are doing the hardware-loopback test. I mean: loopback MIDI Out to MIDI In of your PC, and use MIDI-Ox to send&receive the .syx file The SysEx tool of MIDI-Ox provides a compare function, which allows you to check the equivalence of the sent and received SysEx dump If MIDI-Ox prints mismatches, you know that there is something wrong with the MIDI interface/ MIDI driver/ MIDI cable... Best Regards, Thorsten.

The term "counter" could be missleading, it actually means: SysEx block size / 8 It's normaly the same for all blocks. 256 byte blocks are usually prefered, this results into a "counter value" of 0x100 >> 3 = 0x20 Best Regards, Thorsten.