TK.

Wieviele Bytes werden vom Snapshot gesendet? Vielleicht kommt es zu einem Buffer overrun? Der IN Buffer ist 64 bytes gross, wenn gleichzeitig eingehende und interne Events weitergeleitet werden sollen, entsteht das typische Bottleneck-Problem. Mit dem RAM Monitor von MIOS Studio kann man das debuggen (Rx Buffer: 0x500-0x53f, Tx Buffer: 0x540-0x56f) Eine einfache Moeglichkeit waere, zwischen den einzelnen Events, die gesendet werden, ein Delay von 1 oder 2 mS einzufuegen (MIOS_Delay(2); ), um Zeitschlitze fuer die eingehenden Events freizulassen. Faustregel: 1 mS = 3 bytes Gruss, Thorsten.

Which BankStick board are you using, which BankStick (part number, vendor name?) Best Regards, Thorsten.

Maybe you could create a list of components you want to use, and somebody else can say, which ones are not really required - you could write this into the Wiki in order to ensure, that the same question doesn't need to be answered again and again... Best Regards, Thorsten.

When the ground of your tester is connected to the cathode (pin marked with the black line), and + with the anode, it should beep (or show the current draw if no accoustic signal is available). If you test it in the other direction, it should not "beep" (-> no current draw). Unfortunately on your pictures the direction of the diode cannot be regognized, but I guess that you've already doublechecked this with my pictures? In the last months, we had several users who reported problems with the MIDI interface of their mainboard. I noticed, that you haven't mentioned yet, which kind of MIDI interface you are using...? Best Regards, Thorsten.

Interessant! Zum "Fader 4": dass die 0-Position nicht exakt erreicht wird, ist ein Alps-typisches Problem, deshalb auch folgende Massnahme im Code: ;; --- special case: if target and current position <= 0x07, stop motor ;; (workaround for ALPS faders which never reach the 0x00 value) [/code] Gruss, Thorsten.

1000 mal pro sekunde (1kHz) Gruss, Thorsten.

Hallo Thomas, dass es Probleme mit dem Shift Register gibt, wundert mich sehr, doch das ist vielleicht erstmal ein anderes Thema. Wie verhalten sich die Fader, wenn Du die direct_control applikation auflaedst? Hiermit kannst Du Ausgaenge des Shift Registers direkt ansteuern. Ist Fader 3 dann immer noch so langsam? Wie verhaelt es sich, wenn Fader 3 von einem H-Bridge Ausgang angesteuert wird, der zuverlaessig funktioniert? (bspw. der fuer Fader 2) Welchen 10-bit Wert erreicht Fader 3 bei Min/Max Stellung? Was sagt der Jitter Monitor, wenn die Motoren aktiv sind? Gruss, Thorsten. P.S.: meine Alps Fader laufen nach 4 Jahren zwar nicht mehr 100% gleichmaessig, doch immer noch sehr schnell. Ist bei Dir im Laufe der Zeit vielleicht der eine oder andere Fader mechanisch ueberdehnt worden?

It depends on what you are planning to do with the MIDIbox. In general you can crosslink the Rx/Tx lines, since they are working at TTL level - it works exactly like described at the MBHP_USB page (MIDIbox Link port) But if you are using a MIDIbox which generates audio, like MIDIbox SID or MIDIbox FM, don't ommit the optocoupler - I tested this on my own MBSID and noticed some additional background noise Best Regards, Thorsten.

Thank you Widdly, it's good that an expert looks over these tables :) Best Regards, Thorsten.

Hallo Brain, die Pitch Funktion laesst sich aehnlich wie unter http://www.ucapps.de/mios_c_send_ain.html beschrieben realisieren - nur sendet man keine MIDI Events wenn der Fader bewegt wird, sondern aendert stattdessen die BPM Rate - das geht mit 'MCLOCK_BPMSet(pin_value >> 2);' (pin_value ist ein 10bit Wert, mit ">> 2" wird er zu einem 8bit Wert) Evtl. musst Du hier auch noch einen Offset (+48 oder so) hinzurechnen, ich weiss gerade nicht die minimale BPM Rate auswendig Ich fand die Idee fuer eine separate Start und Stop Taste eigentlich sehr livetauglich. Wenn man bspw. mit dem naechsten Beat die ersten drei Clocks deaktivieren moechte, muss man nicht lange ueberlegen, welche Tasten man nun druecken darf (welcher Clock laeuft noch, welcher wurde bereits deaktiviert), man drueckt einfach auf die ersten drei Stop Tasten. Gruss, Thorsten.

Hallo Thomas, wenn 256 mal das gleiche Ergebnis gemessen wurde (der Fader sich also nicht bewegt) - wenn das analoge Signal jittert, funktioniert diese Erkennunng natuerlich nicht niemals, die Fader werden voellig unabhaengig angesteuert. auch hier: niemals - alles laeuft interruptgesteuert niemals, die Ansteuerungsroutine benoetigt weniger als 20 uS, bleiben 300 uS fuer die Verarbeitung von eingehenden MIDI Daten bei voller Bandbreite Du kannst in der Init Funktion den Zielwert einstellen, die Fader werden dann im Hintergrund bewegt, der Mainthread wird dabei nicht blockiert Deine Fragen helfen mir leider (wie auch schon in der Vergangenheit) nur wenig, mich in das Problem hineinzudenken. Wie sehr hast Du mittlerweile die Hardware modifiziert (Du hast ja auch schon in de.sci.electronics angefragt)? Welche Ergebnisse erhaelst Du mit der "mf_direct_control" Applikation, welche die Motorfader direkt (ohne MF Treiber) ansteuert - kannst Du hiermit alle 8 Fader gleichzeitig bewegen. Werden sie bei in diesem Fall langsamer? Gruss, Thorsten.

Maybe it works better with a 50k pot instead of a 10k pot, could somebody try this out? The backlight has a polarity, it's a LED - therefore this is not related Best Regards, Thorsten.

Hallo, der Test ist erfolgreich verlaufen. Mir ist aufgefallen, dass es sehr unguenstig ist, wenn man den MIDI Clock einfach nur wegschaltet, weil der Sequenzer dann u.U die angespielten Noten solange haelt und nicht loslaesst, bis er wieder Clocks empfaengt. Deshalb sendet die Clockbox nun ein Stop Event wenn ein Slave angehalten werden soll (der Sequenzer stoppt dann alle Noten), und ein Continue Event wenn der Clock wieder freigeschaltet wird. Weitere Details gibt es hier: http://www.midibox.org/forum/index.php?topic=5691.msg48932#msg48932 Die Play/Stop Button Logik entspricht nicht Deiner Beschreibung, aber sie laesst sich einfach anpassen (ich finde es so praktischer). Der Code steht in mclock.c Gruss, Thorsten.

The clockbox got a new "multi MIDI Out option" based on an idea of Braintu. It allows to enable/disable the MIDI clocks of up to 8 MIDI clock slaves (sequencers, drum machines, synths) seperately and in a synchronized manner (clock will be enabled/disabled exactly on the next beat) [tt] Update V1.1: A "multi clock out" option has been added which supports 8 additional MIDI Outs. The clocks which are sent can be enabled/disabled with 8 seperate play and stop buttons. Changes will be synchronized to the beat (1/4 note) This option is based on an idea of Braintu, his full concept can be found under http://www.midibox.org/dokuwiki/doku.php?id=midimasterclock Only the stop/play function has been implemented yet, he will continue on this project. Technical details about this option: the 8 MIDI outs are available at J5 of the core module. This port is normaly used as analog input. In order to ensure, that no short circuit happens if a user uploads this application on a MIDIbox which has pots or AIN modules at J5, the MULTI_CLOCK_OPTION flag in main.h is disabled (0) by default. It has to be set to 1 to get the MIDI outs working MIDI events are sent over these outputs with the "bit banging" method. (see mclock.c, MCLOCK_SendMultiPort) The enabled MIDI clock channels are displayed with 8 LEDs There is a special schematic which describes the additional connections: http://www.ucapps.de/mios/clockbox_multi.pdf [/tt] Download: http://www.ucapps.de/mios_download.html Interconnections: http://www.ucapps.de/mios/clockbox_multi.pdf Best Regards, Thorsten.

Hi, I'm normaly using my scope to measure the performance. A free IO pin is set to 1 when the function starts, and to 0 when it is finished - it gives a good feeling about the processor load. In addition, the scope can display the minimum and maximum pulsewidth. However, w/o a scope it gets difficult. You could use the integrated simulator of MPLAB, but it requires that you call the function which should be profiled with a correctly initialized memory. Since it is difficult to combine MIOS with the application in order to simulate it completely, you have to add some debugging code, located at 0x0000 (reset vector), which inits the memory and jumps to USER_Tick (not to Tick()) - this ensures, that also the stack pointers are initialized correctly This debugging code must be removed when you want to upload the application again. Best Regards, Thorsten.

Btw.: I'm planning to create a 64 button/LED matrix application soon, I will use moxi's DIY button caps for this. This hardware is intented as an extension for MBSEQ, but it can also be used by other apps. Only 3 DOUT and 2 DIN registers will be required. This means, it can be easily extented to a 256 or 512 button/LED variant :) Best Regards, Thorsten.

Today I've tested SDCC 2.6.0 for compatibility with the MIOS wrapper. It seems that all functions are still working... so, these are the good news :) But the bad news are, that I found a bug in SDCC during the tests - see http://sourceforge.net/tracker/index.php?func=detail&aid=1539278&group_id=599&atid=100599 So, currently I cannot recomment the usage of the most recent SDCC versions until this bug has been fixed I've released a new SDCC wrapper version v1_9a which got a fix for one of my own bugs (MIOS_HLP_Dec2BCD now working as expected) Best Regards, Thorsten.

Hallo Brain, das ist super! Bei mir ist die Situation so, dass ich so etwas zwar schnell auf die Beine stellen koennte, sie aber ohne die entspr. Hardware nicht testen kann. Bzw., wenn ich etwas blind programmiere, baue ich vielleicht einen Bug ein, den ich mit einer realen MIDIbox die vor mir steht sofort sehen wuerde. Ausserdem liegt bei mir die Prioritaet momentan auf die Entwicklung von MBSEQ V3, anschliessend MBSID V2... Deshalb moechte ich eigentlich nur die grundlegenden Funktionen einhacken und selber testen, den Rest muesstest Du dann weiterprogrammieren. Dabei wirst Du sicherlich die eine oder andere Idee fuer Verbesserungen haben, die Du dann selbst umsetzen kannst. Ich habe heute mal die Funktion zum Senden von einem MIDI Clock ueber 8 Pins programmiert, auf dem Scope sieht es ganz gut aus. Die Pins lassen sich maskieren, und die Synchronisierung auf 1/4 Note klappt auch. Morgen werde ich mit den Clocks mal zwei MBSEQ, eine MBSID und einen RM1x ansteuern, wenn das funktioniert, werde ich die modifizierte "Clockbox" Variante veroeffentlichen. Darauf kannst Du dann aufsetzen. Falls dann spezielle Programmierfragen offen sind, kann ich natuerlich weiterhelfen. Es gibt ein paar Programmierbeispiele auf meiner Webseite, welche die Grundlagen erklaeren. Gruss, Thorsten.

MTV

I'm running MIOS Studio and MIDI-Ox mostly in parallel w/o issues. With which operation system are you working, and which MIDI interface are you using? Best Regards, Thorsten.

Maybe there are some random button triggers which prevent MIOS from checking for upload requests. However, could you please try to upload MIDIO128 with the 1st level bootloader, which is active for 2 seconds after power-on (before the MIOS V1.9 message appears on the LCD). Please also use the latest MIOS Studio release beta7_4 Best Regards, Thorsten.

the GP buttons are located below the two 2x40 displays - how large are your fingers? ;-) Isn't it easier and much more flexible to use a normal keyboard for entry into the chord memory? A split function is already available in MBSEQ V3 for the transposer (lower keys, also used so select the base note), and the arpeggiator (upper keys). By activating the "force-to-scale" function on all tracks which are playing arpeggios (see the tutorials how MBSEQ handles this), you have something similar, but much more powerful :) (yes, I know that this is not what you mean, but your suggestion is not on-topic anyhow ;-)) I implemented a C based "magic chords" application some time ago (see this topic http://www.midibox.org/forum/index.php?topic=5966.0) but didn't found it very useful, and therefore never released it. However, it only supports major and minor scale, with all the new scales it could become interesting. Is somebody interested in maintaining (improving, writing documentation) for this "magic chords" app? Best Regards, Thorsten.

yes, it's ok, even this method consumes more memory, because a "goto" instruction takes 4 bytes, storing the target program counter in a table would only take two byes per entry. However, for simple applications this should be ok, and for larger applications just use the PIC18F4620 ;-) Best Regards, Thorsten.

yes, this is correct. If you want to make it easy and less RAM memory efficient (which would be ok, since there is enough free in the MBCV application), you could store the received velocity values in an array of 128 bytes: in app_defines.inc, add: VELOCITY_VALUES EQU 0x200 ; ... 0x27f - used as velocity value storage [/code] Within CV_MIDI_NoteOn, you can store the velocity value: [code] lfsr FSR0, VELOCITY_VALUES movf MIOS_PARAMETER2, W ;; use note number (0x00..0x7f) as index for the array movff MIOS_PARAMETER3, PLUSW0 ;; works like: VELOCITY_VALUES[note] = velocity now a really quick&dirty solution: in cv_map.inc, CV_MAP_Hlp_Note function, you can send the velocity instead of the note in following way: replace ;; get note lfsr FSR0, CV_C1_NOTE movf CV_CURRENT_CHANNEL, W, BANKED movff PLUSW0, TMP1 [/code] by: [code] ;; get velocity of note lfsr FSR0, CV_C1_NOTE movf CV_CURRENT_CHANNEL, W, BANKED movf PLUSW0, W lfsr FSR0, VELOCITY_VALUES movff PLUSW0, TMP1 Best Regards, Thorsten.

This would be perfect! Could you please take a look into the assembly output? It's located in the _output directory Best Regards, Thorsten.