TK.

Yes, the order of the MIDI configuration is (unfortunately) important: - start Ctrlr, ensure that the MBSID panel isn't loaded yet - click on the green "MIDI Device Settings" icon and select the IN/OUT port of your MIDI Interface - load the MBSID panel - in the lower toolbar, select the IN/OUT port to which your MBSID is connected. This procedure is only required once, the setup will be stored. Best Regards, Thorsten.

Hallo, (fast) alles richtig - das IIC_MIDI-Modul ist in Deinem Fall jedoch nicht notwendig, da im LPC17 bereits vier UARTs integriert sind; IN3/OUT3 befindet sich auf J5B.J6/7, und IN4/OUT4 auf J4B.SC/SD Siehe auch: http://www.ucapps.de/mbhp/mbhp_core_lpc17_midi3_midi4_extension.pdf Die externe Beschaltung koenntest Du auf Lochraster bauen. Theoretisch waere uebrigens auch eine direkte Verbindung ohne Optokoppler zwischen Core und MF Modul moeglich, doch fuer beste Ergebnisse (bspw. minimaler Jitter an den Motorfadern) ist eine galvanische Entkopplung vorteilhaft. Schaltplan fuer DOUT Matrix und ein dazugehoeriges Tutorial werde ich nachliefern, die vorhandenen Loesungen (siehe bspw. BLM Sektion in diesem Forum) sind als Vorlage unnoetig komplex. Gruss, Thorsten.

Hi Gert, I will update the "universal" lcd driver under modules/app_lcd/universal soon to simplify such changes, currently they are not obvious (basically you would have to change each line where MIOS32_BOARD_J15_E_Set() is called, it makes sense to add an additional SW layer to overwrite the default function) Best Regards, Thorsten.

Problem: MB64 is written in assembly, not C Best Regards, Thorsten.

Ja, es muesste genau so funktionieren, wie Du es skizziert hast. Die Software-Option laesst sich ohne grossen Aufwand in die Firmware integrieren - ich halte sie auch fuer sinnvoll, da sie auch fuer andere Anwendungsfaelle hilfreich sein konnte (bspw. Drumpads) MBKB unterstuetzt uebrigens von Haus aus zwei Tastaturen, Du kannst sie also auch trennen wenn es Sinn macht (Vorteil: sie lassen sich dann auch unabhaengig transponieren und/oder auf verschiedene MIDI Kanaele legen) Gruss, Thorsten.

It would be interesting for me as well, if anybody is working under Windows here? See also my question in the first posting: probably only the "lost" r945 will work correctly, if somebody has this binary on his harddisk, please send me the file. Best Regards, Thorsten. P.S.: Roman wrote in the Ctrlr forum, that the next nightly build will be available this week.

Hi, difficult... using pots without multiplexer in an application which has been programmed for multiplexer usage is an exotic usecase and not prepared. Currently I'm unsure how to handle this properly without making it too complicated at the software (configuration) side, it's definitely not something which could be programmed (and documented) in less than 1 hour. Do you have a spare 4051? It would be the most efficient solution just to use a multiplexer (costs 0.30 EUR!) Or alternatively: do you have assembly programming skills, so that you could program this special variant by yourself? There are four solutions to change the button mode: - use the control surface - this requires a LCD and the 4 menu buttons, are they available? - edit the src/mb64_presets.inc file: e.g. instead of "BUTTON_ENTRY 0x90, 0x30, 0x7f, 0x00" write "BUTTON_ENTRY 0x90, 0x30, 0x7f, 0x02" (0x02 selects the toggle mode) - configure via SysEx by using an .ini file and converting it to .syx format with the mk_syx.pl script - preferred solution under Linux and MacOS - configure via SysEx with Serge's editor - preferred solution under Windows. I'm unsure which one is the best at your side, since I neither know how your MIDIbox looks like, nor (if you prefer configuration via SysEx) which operation system you are using. Best Regards, Thorsten.

Hi, unused analog inputs have to be clamped to ground to avoid random events, see also this document: http://www.ucapps.de/mbhp/auaimbctg.pdf Best Regards, Thorsten.

Hallo, die MIDIO128 Applikation waere schonmal der richtige Ausgangspunkt. Hiermit koenntest Du bspw. die 173 Taster ueber zwei 8x8 Matritzen scannen, was den Hardware-Aufwand reduziert. Source Code: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidio128_v3%2F Hier der Schaltplan fuer eine einzelne 8x8 Matrix: http://www.ucapps.de/midio128/midio128_v3_scanmatrix.pdf Mit einem zweiten DIN Register (das DINX4 Modul hat vier davon) koennen weitere 64 Taster gescannt werden, das DOUT Register zur Selektierung der Spalten benoetigt man nur einmal. LEDs: hier ist ebenfalls eine Matrix vorteilhaft, bestehend aus zwei DOUT Registern fuer jeweils 64 LEDs. LED-Matritzen werden zwar von der MIDIO128 Applikation nicht nativ supported, doch der entsprechende Code laesst sich einfach integrieren und es gibt auch bereits eine Menge Programmierbeispiele zu diesem Thema (Links auf Wunsch - vielleicht sollte ich mal ein Tutorial daraus machen). Encoder: einfach integrierbar, hierfuer gibt es ein Tutorial: http://www.ucapps.de/mios32_c.html, #014 Der Encoder selbst ist beliebig waehlbar, dieser hier ist bspw. recht guenstig: http://www.pollin.de/shop/dt/NjE2OTU3OTk-/Bauelemente_Bauteile/Passive_Bauelemente/Potis_Trimmer_Encoder/Encoder_Noble_RE0124PVB17_7FINB_24.html Wenn es qualitativ hochwertiger sein soll, dann lieber Alps (gibts bspw. bei Reichelt) Die Jogwheels werden auf die Encoder draufgesetzt. Ich habe meine bspw. vor Jahren bei http://www.albs.de gekauft (DK38-144), ich bin mir allerdings nicht sicher, ob ein Einzelversand noch moeglich ist. Ansonsten lohnt es sich immer mal bei Pollin oder Ebay vorbeizuschauen; vielleicht auch bei Mouser den (umfangreichen!) Katalog durchwaelzen - oder aus einem defekten Geraet ausschlachten. Motorfader: ja, das MBHP_MF_NG Modul ist am besten geeignet, der LPC17 hat bis zu 4 MIDI INs und 4 MIDI OUTs, die sich in der MIDIO128 Applikation mit Hilfe der Router-Funktion zu einem USB IN/OUT mergen lassen. Gruss, Thorsten.

The sequencer records exactly the note which has been received. Maybe you've activated the transpose function in the Track Mode page, or increased the octave in the Transpose page, so that the playback is affected? Best Regards, Thorsten.

Ok, I will check it next week. It would be helpful to know if somebody else who owns a sammichSID notices the same issue with v2.039? Best Regards, Thorsten.

Does sammichSID send back an error code? (-> see MIDI IN window of MIOS Studio, assumed that you've a bidirectional IN/OUT connection - check this by pressing the "Query" button) Best Regards, Thorsten.

MB64E doesn't run on LPCXPRESSO, only on the old PIC based core. For MIOS32 MBNG will provide equivalent features (+ more), but this application isn't available yet. However, if you are planning to implement the app by yourself anyhow: the tutorials are here: http://www.ucapps.de/mios32_c.html Another discrepancy: for LPCXPRESSO you will need a AINSER64 module, MBHP_AINs are not recommended. Best Regards, Thorsten.

Strange... because it would be a possible explanation. Background: writing into the external EEPROM (BankStick) takes some time, and if a new patch is received when the write operation still hasn't been finished, a MIDI IN buffer overflow can happen. Therefore the delay is required between each patch. If you are trying to write the patch again, regardless of the firmware version, it will mostly consume much less time, because before the write operation MIOS will check the current content (of a 64 byte block) and then decide if the write operation could be skipped. It would be interesting to know, if you are now able to upload the presets with v2.039 (the patch write should now be much faster, as the EEPROM already contains the expected content). I've to check if 750 mS is still sufficient. Sidenote: the Java based SysEx editor works bidirectionally, therefore no delay has to be specified which makes the process much faster. But the editor doesn't work under MacOS anymore, and the Ctrlr based patch manager isn't ready yet. If you are working under Windows, it would be a good alternative solution to ensure consistent patch uploads of course. Best Regards, Thorsten.

Alright! Which tool are you using for the SysEx dump, and if it isn't a MBSID V2 librarian (like the java based editor): which delay is inserted between the individual patches? (should be configurable, I think it was at least 750 mS, otherwise it won't work reliable) Best Regards, Thorsten.

Bx is a CC event which can't be sent with the keyboard of MIOS Studio (it only sends note on/off commands). 49 and 7f are hexadecimal numbers (0x49 -> the CC number, 0x7f -> the CC value) You could send it directly from your core module of course... Or if your operating system supports this: from the SysEx window of MIOS Studio. Or - maybe the most comfortable solution - with Ctrlr Best Regards, Thorsten.

I like it! :) Best Regards, Thorsten.

I'm currently not at home and therefore can't try this. Could somebody please install V2.039 on his sammichSID and confirm that he sees the same misbehavior? From your description: Was "08" really the ID, or is this a typo and you mean the SysEx type, e.g. after "f0 00 00 7e 4b 00 02 >> 08 <<" In order to support bidirectional communication with the new I had to change the handling on "RAM buffer" transfers: they don't change the patch and bank number anymore. This is the only (intended) change in the SysEx handling. If you confirm that really the ID was wrong during the first tries of v2.039, I can check the related sources. Best Regards, Thorsten.

The circuit is so simple, that it's very likely a connection problem. Since you've a scope, it could be debugged the following way: First check the Dx outputs of J5A, each output should be strobed for 1 mS with a period of 8 mS. If not -> problem at the core module. Thereafter check the J5 Dx inputs on the frontpanel. Do you see the same pattern on each pin? If not -> problem with the ribbon cable. You won't see the same pattern at the collector of the transistors, because they are used in "open collector" mode. But you could connect a 10k resistor between collector and 5V, and then check the pulses on the collector - they should be inverted compared to the input pulse. It makes sense to disconnect J5A/B and J10 for this check to avoid wrong results (which could be caused by a short circuit for example) Then it's time to check the polarity of the diodes and LEDs. The cathodes are on the right side (see also schematic). J5A and B should only show a pattern when the LED of the appr. row is enabled, your description matches with my expectation after power-on. J10 should show pulses (according to the button matrix) when a button is pressed. Check this at the frontpanel and core module side. Best Regards, Thorsten.

Meinst Du, dass diese PRESSED (=gedrueckt) und DEPRESSED (=losgelassen) Meldungen ausgegeben werden, wenn eine einzige Taste gedrueckt wird? Ich schau mal in meine Kristallkugel, und die sagt mir, dass dies wohl der Fall war - zumindest deuten darauf die Timestamps hin, denn es ist quasi unmoeglich, soviele Tasten innerhalb von 100 mS zu bedienen. Oder hast Du hier gerade mal mit der Hand draufgehauen? Die ist leider nicht auf dem Bild ;-) Ich schaue nochmal rein, und bemerke, dass von Column (=Spalte, von DOUT getrieben) 6 und 7 jeweils alle Rows von 0..15 (= Zeile, von den DINs abgelesen) wackeln. Mein wahrsagerisches Gespuer sagt mir nun, dass an einer Stelle (aber nicht an allen Pins) Row und Column vertauscht wurden. Jetzt ist das Bild leider wieder unklar geworden. Gruss, Thorsten.

Hallo, ja, die sollten noch funktionieren. Ich habe sie zumindest vor gut 10 Jahren mal angetestet, falls es Probleme gibt bitte bescheid sagen. Gruss, Thorsten.

Thanks for testing! :) A new release is available - optimized for your Easter Jam! :-) MIDIboxSEQ V4.058 ~~~~~~~~~~~~~~~~~ o a new Pattern Remix feature has been implemented by Midilab. It's optimized for live sessions and got a special page: - pattern names can be previewed before they are selected - patterns change when the selection button is pressed a second time - mixer maps are dumped with pattern change - the "Remix" function allows to select tracks which should be kept (not overwritten by pattern changes) - allows to synchronize with Ableton Live clips The full documentation can be found under: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fdoc%2Fpattern_remix_manual.txt Note that the correct function of this feature requires, that the remix page is assigned to a dedicated button. This has to be done in the MBSEQ_HW.V4 file (new entry: BUTTON_PATTERN_RMX) - e.g. you could assign it to F4 o corrected SysEx output for LPC17 [/code] Proposals for enhancements of the Remix page are welcome! Best Regards, Thorsten.

Sorry, I haven't noticed your troubleshooting questions here... is it solved meanwhile? A new release is available: MIDIboxSEQ V4L.058 ~~~~~~~~~~~~~~~~~~ o corrected SysEx output for LPC17 [/code] Best Regards, Thorsten.

Ich kann mir leider mit den gegebenen Informationen gerade nicht vorstellen, wo genau das Problem liegt. Zwei Kontakte werden geschlossen und wieder geoeffnet, doch die Key-Nummern passen nicht zueinander. Eigentlich kann das nur dann passieren, wenn die Schalter falsch angeschlossen wurden (bspw. um einen Pin verschoben, entweder am DIN oder DOUT) Gruss, Thorsten.

No problem! I fixed it, it was done in less than 1 minute. ;-) Guidelines or a sophisticated documentation wasn't required yet, and I think that when you are seeing the changes now, it's clear how the source code is stored in the repository: -> http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fmisc%2Fvisual_metronome%2F I just copied the SDCC skeleton from http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Ftemplates%2Fsdcc_skeleton%2F, copied your .c and .h and .txt files into the directory, and adapted the Makefile - done. As you can see, the version number is not part of the directory. This would only done if you are planning major updates in future and still want to maintain the old application (e.g. like I did for midibox_sid_v1 and midibox_sid_v2). Since only the source code of the actual application is in this directory, you will automatically "inherit" the programming environment for MIOS. For a release, please do following steps: cp -r visual_metronome visual_metronome_v0_1 cd visual_metronome_v0_1 rm -rf .svn make dist sh dist.sh -> thereafter .zip this directory The release-mios-app.pl script automates these steps, but it only works under Linux and MacOS, and not under Windows. These steps ensure that users are able to modify parts of your source code for customizations (and you prepared this according to your README.txt) and to build a new .hex file without downloading the SVN repository (+ knowing which SVN revision had been used -> less dependencies) But as a developer you would always work with the latest files in the repository, e.g. to get updates done by somebody else. Where to release it: either attach the .zip file in the Wiki, or in your forum posting. Best Regards, Thorsten.