TK.

Es gibt tatsaechlich noch eine logische Erklaerung fuer dieses mysterioese Verhalten: falls die RC (RCLK) Leitung nicht richtig verbunden ist, muesste der Interconnection Test trotzdem durchlaufen, in der MBSID Application wuerden alle Output Pins des 74HC595 auf '0' stehen. Deshalb das alte Spielchen - um evtl. Kurzschluesse auf der Platine auszuschliessen (um das herauszufinden, hilft Dir kein Durchgangspruefer!) Pin #23 (RC4) des PICs sowie Pin #12 der beiden 74HC595 zur Seite biegen und direkt miteinander verbinden. Falls das dann auch nicht der Grund war, liegt es entweder am Core, oder am SID Modul. ;-) Gruss, Thorsten.

Ok - das flag "SID_STAT_USE_BANKSTICK" ist gesetzt, somit ist der BankStick aktiv. Das war auch schon alles, was ich zu diesem Thema beitragen konnte. Vielleicht solltest Du nochmal den sidplayer ausprobieren, ansonsten kann ich Dir keinen weiteren Tip mehr geben. Die Sache wird mir einfach zu aufwaendig - aber vielleicht hilft Dir ja jemand anderes weiter. Gruss, Thorsten.

Bzw., ich sehe gerade, dass Du am Ende der MIOS_MIDI_TxBufferPut's ein return eingefuegt hast. Habe ich davon etwas erwaehnt? Denke nicht... Also so koennen wir noch wochenlang weitermachen.. ;-) Gruss, Thorsten.

Jo, die Firmware versucht alle SID Register neu zu laden, SID_SR_Handler wird jedoch nie aufgerufen. Kann es sein, dass Du in sid_tick.inc den urspruenglichen Code entfernt hast? Falls Du Dir nicht sicher bist, lade bitte die alpha3 Release erneut von der Webseite und spiele das Original .syx File auf Gruss, Thorsten.

...ohne ein LC Display nur wenn der SID richtig angeschlossen ist oder man den Source Code kennt ;-) Baue mal folgendes in sid_tick.inc ein: movlw 0xb0 call MIOS_MIDI_TxBufferPut movf SID_STAT, W andlw 0x0f call MIOS_MIDI_TxBufferPut swapf SID_STAT, W andlw 0x0f call MIOS_MIDI_TxBufferPut Dieses Prograemmchen sendet permanent den SID Status. Welche Daten zeigt Dir MIDI-Ox an (ich muss eigentlich nur den letzten Controller Event wissen) Gruss, Thorsten.

So hoert sich der SID an, wenn er im Reset ist - passt also (leider) Gruss, Thorsten.

Danke! :) Von der Software Seite her sehe ich keine Probleme. Beim Aufbau der Hardware solltest Du jedoch penibelst auf EMV achten. Die 128 LED Ringe werden mind. 1 Ampere benoetigen, vielleicht sogar mehr. Und da die einzelnen LEDs nicht permanent eingeschaltet bleiben, sondern von der Firmware im Zeitmultiplex-Verfahren sehr schnell ein- und ausgeschaltet werden, koennte dadurch die 5V Versorgungsspannung mit extremen, hochfrequenten Stoerungen ueberlagert werden. Und dies wuerde sich wiederum als Jitter bei den analogen Fadern bemerkbar machen. Deshalb mein Vorschlag: verwende am besten zwei getrennte Netzteile (gibt es bei Pollin sehr guenstig) fuer die MB64 und MB64E/MIDIO128, und verbinde den MB64 Master via Optokoppler mit den Slaves (also eine "normale" MIDI-Verbindung ueber MIDI In/Out). Die Slaves koennen untereinander ueber den MBLink Port - ohne Optokoppler - verbunden werden, solange die analogen Eingaenge ungenutzt bleiben. Ich bin mir nicht sicher, ob es etwas ausmacht, wenn die Massen der beiden "Voltage Domains" miteinander verbunden sind - das muesstest Du dann ausprobieren. Es macht sicherlich auch Sinn, an jedes DINX4 und DOUTX4 Modul Stuetzkondensatoren (jeweils 10uF und 100 nF parallel) zwischen Vss und Vdd anzuschliessen, um die Spannung zu stabilisieren und Stoerungen abzufangen. Auch Spulen und Drosseln sollen hier helfen, aber das ist absolut nicht mein Gebiet. ;-) Gruss, Thorsten. P.S.: diese Anmerkungen gelten hauptsaechlich fuer Mega-Konfigurationen mit mehreren Cores. Meine MIDIbox LC kommt bspw. ohne besondere EMV Massnahmen aus...

Dann hast Du Glueck gehabt ;-) Nun schliesse mal den BankStick an. Und zwar aus dem Grund: nach dem Formatieren (dauert > 1 Minute, wie bereits geschrieben), wird kurzer ein Ton gespielt. Und zwar direkt ohne dass der MIDI Kanal oder der Preset-Sound irgendeine Rolle spielt. Ist der BankStick erstmal formatiert, wird dieser Ton ca. 5 Sekunden nach jedem Einschalten gespielt. Ergebnis? Gruss, Thorsten.

Argl! Mach' die Bruecke weg, die erzeugt einen Kurzschluss und koennte den 74HC595 zerstoeren! :-/ Den Widerstand kannst Du weglassen, aber daran wird sich nicht viel aendern. Im Schematic steht ja "it isn't required anymore...." und "could be left out". Mit der Bruecke erzwingst Du nun, dass der SID keinen Reset mehr erhaelt, und das wird so ebenfalls nicht funktionieren. Was hat sich bei der direkten Verbindung der beiden Pins ergeben? Die Pins duerfen dabei keinen Kontakt zur Leiterplatte haben! /edit: es macht wirklich Sinn, das mal auf diese Weise zu testen, glaube mir einfach... ;-) Gruss, Thorsten.

Hallo, es ist normal, das manche SIDs (vor allem die ersten Revisionen) ziemlich heiss werden. Oder hast Du den Eindruck, dass der Chip wesentlich heisser als im C64 Gehaeuse wird? Nun, das wuerde alles erklaeren. Der Reset ist Low-Aktiv, das heisst: solange an diesem Pin keine 5V anliegen, befindet sich der SID im Reset und wird garantiert keinen Mucks von sich geben. Ich halte es fuer unwahrscheinlich, dass es am 10k Widerstand liegt (zumal es sich hier ja um einen Pull-Up handelt). Vielleicht liegt es an der Bruecke zwischen dem SID und dem 74HC595? Sie hat hoffentlich keinen Kontakt zum Oszillator-Gehaeuse? Ist es Dir gelungen, den Reset Pin mit dem SID Interconnection Test "wackeln" zu lassen? Du koenntest mal Pin #5 des SIDs und Pin #2 des 74HC595 zur Seite biegen und direkt miteinander verdrahten. Gruss, Thorsten.

A 2 HE solution would be really interesting! But an inportant tip: try to arrange the "real" components before ordering the panel! When you compare my first panel idea with the final one, you know why... ;-) It's always a good idea to prepare all boards before ordering a panel! To the button functions: EDIT: changes to the common edit view, steps are muted/unmuted with the 16 general purpose buttons. 1/2/3/4 to select the track, A/B/C to select the layer. MUTE: changes to the appr. menu page which is used to mute the tracks with the general purpose buttons. PATTERN: changes to the pattern menu. 1/2/3/4 to select the pattern, GP buttons to enter the pattern number SONG: changes to the song menu. 1/2/3/4 to select the pattern, GP buttons to enter the pattern number, A selects the song number, B: song position, C: End/Repeat/Loop points (in fact the cursor within the menu page is controlled by 1/2/3/4/A/B/C) SOLO: only the currently selected "edit" tracks will be played. With the 1/2/3/4 button you are able to select multiple tracks at once (like known from the MIDIbox SID) ALL: allows you to set a value for all selected tracks, steps and layers at the same time with a single encoder FAST: faster encoder movements - works for all encoders at the same time. If you are using encoders with inbuilt push-button, you can activate the function also from there Best Regards, Thorsten.

Some countries or language areas have their dedicated boards for exchanging informations about local electronic shops, for starting collective orders, for requesting help (i.e. PIC burning), etc. I just noticed that something similar is missing for english speaking nations. So my question: would it make sense to start at least three additional boards for Australia, UK and Canada/USA? Maybe also for english speaking asian nations? Or would it make sense to start two new international boards "collective orders" and "PIC burning" (suggestions for alternative names are welcome) Best Regards, Thorsten.

Did you try the ENC example 1? Then you should continue with ENC example 2 which handles more than 1 encoder... (it always makes sense to read the comments in main.asm ;-)) Best Regards, Thorsten.

Hi, I didn't wrote that this is a Steinberg bug, I wrote that they violated the protocol. Or in other words: either they haven't read the specification and implemented the meters in the wrong way, or they thought that they could "enhance" the protocol, but did this in a very unusual and incompatible way. The biggest problem with the Steinberg implementation: it's not fail-save. Means: there is no flag or something else which indicates the first and the second byte. This means that the protocol handler could get out of sync (e.g. during the startup phase or if the MIDI cables are temporary not connected). Something like a time-out mechanism could help here as a dirty workaround. Second problem: they don't use the meter events in the same way like Logic. The emagic guys were clever, Logic sends only the peaks, and Logic Control decreases the meter level automatically: MIDIbox LC decreases the meter levels also automatically (of course). But from your logfiles it can be assumed that Cubase sends every single LED event. This costs a lot of bandwidth (means: motorfaders won't be moved in realtime, very slow LCD messages, etc...). Third problem: I don't know why it would make sense to send LED meters with 7+4 = 11 bit resolution. Who really wants to have 2048 LEDs for a single meter? ;-) Result: the implementation is very different from the original LC. Either you've misconfigured Cubase (a user wrote some time ago that Cubase provides some kind of generic metering via MIDI - hope that you haven't enabled it, because it wouldn't be compatible with MC/LC), or a special function for Cubase has to be programmed (without the automatic decrease and with a parser for this broken protocol). Of course, not a big problem with MIOS, but who wants to spent the effort? Best Regards, Thorsten.

It's a EMC problem. Add the 100nF caps (maybe also to the LCD), and check your power supply (5V@core should still be stable when *all* motorfaders are moved) Best Regards, Thorsten.

Hi Frank, I will try to reproduce this. I never tested this code... since I don't own so much ledrings ;-) Best Regards, Thorsten.

Oh, by the way: I'm also planning to release a MIDIbox LC setup file for MIDIbox SEQ (however, without Motorfaders the handling isn't that much perfect, but it's a cheap solution for people who want to master their tracks after the sequences have been recorded :)) efficient scheduling ;-) (I'm working on the MIOS based MIDIbox SEQ application since some months, mostly not more than 2-3 hours a week) Yes, definitely. My effort for the MIDIbox projects is about 60% to answer postings and emails, 30% for implementing applications and writing documentations, and the remaining 10% to make music with all the stuff... however, this is a totally different topic, so I will stop here. ;-) In my opinion this would be perfect, also for beginners who don't know where to order all this stuff. Btw.: Arumblack - it's a 3U panel Best Regards, Thorsten.

Did you really follow the instructions? See http://www.ucapps.de/mios_bootstrap.html MIOS has to be uploaded with the primary loader, this means: within 2 seconds after power-on (before MIOS boots) Best Regards, Thorsten.

Ok, scheint wohl nicht das Problem zu sein. Bleiben noch die oben erwaehnten Tests uebrig. Gruss, Thorsten.

Fuer das Multiplexen koenntest Du Dir vielleicht mal das ENC Example 3 anschauen, aus dem Header: ; ; ENC Example, Part 3 ; ; Purpose: ; -> Sends a MIDI event when one of 64 encoders (#0-#63) is moved ; -> Prints the value on LCD ; -> updates the encoder value if CC#0 - CC#63 has been received via MIDI ; -> handles 64 LED rings ; ; For interest: ; -> variable definitions in app_defines.h ; -> ENC initialization in main.asm, USER_Init ; -> ENC pin definitions in mios_tables.inc, MIOS_ENC_PIN_TABLE ; -> single encoder handler in main.asm, USER_ENC_NotifyChange ; -> simple display handler in main.asm, USER_DISPLAY_Tick ; ; -> MIDI events which have been defined in mios_tables.inc, MIOS_MPROC_EVENT_TABLE ; -> MIDI event handler in main.asm, USER_MPROC_NotifyFoundEvent ; ; -> LED ring handler in ledrings_handler.inc (called by main.asm, USER_SR_Service_Prepare) Der Code, der Dich interessieren duerfte, steht in ledrings_handler.inc Du musst natuerlich nicht alle 64 Ringe (=768 LEDs) anschliessen, man muss sie auch nicht ringfoermig anordnen... und das Beispiel funktioniert auch mit weniger LEDs ;-) Zu den Haendlern, die den PIC18F452 fuehren (nein, der PIC18F442 ist nicht kompatibel): siehe die CORE Bestell-Liste: http://www.ucapps.de/mbhp/mbhp_core_orderlist.txt Gruss, Thorsten.

Just to clarify if this is really true (sounds like a poor implementation from Steinberg if they violate the protocol and if they really use the same events for two different informations) - could you post a logfile with the metering information of a single channel? Sweep the volume from low to high to make the coding clear to me. Dan, if you read this: did you notice the same effect with your MIDIbox LC? Best Regards, Thorsten.

I just found the part numbers: the encoder knobs are from http://www.albs.de DK13-164, black-soft DK13-164, gray-soft Each knob costs 0.65 EUR Datawheel also from http://www.albs.de DK38-144 I got this as free sample These knobs cannot be found in the (poor) webshop, I contacted Albs directly via EMail. If you have luck, you will get an immediate response. If not, it can take some days or weeks ;-) However, if more guys are interested, we could start a collective order (Albs normaly delivers only to big customers in quantities of 100 pieces and more) The buttons are from http://www.reichelt.de DT 6 <colour> <colour>: BL, GN, GR, RT, SW Each button costs 0.43 EUR Best Regards, Thorsten.

It always makes sense to use the latest MIOS version... ;-) Best Regards, Thorsten.

Mir ist noch eine weitere Fehlermoeglichkeit eingefallen: mit welchen Spannungen werden die beiden Module versorgt? Siehe auch: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1072108209 Zum Debuggen wuerde ich empfehlen, die Module mit zwei getrennten Netzteilen zu versorgen. Gruss, Thorsten.

Ja, macht trotzdem Sinn. Ueberpruefe auch mal die Spannung am Reset Pin (#5): 5V Und am RW Pin #7: 0V Vielleicht solltest Du auch nochmal den mbsid_interconnection_test durchgehen. Und wenn das nicht weiterhilft, wuerde ich vorschlagen, dass Du mir das SID und CORE Modul einfach mal per Post zuschickst ;-) Gruss, Thorsten.