TK.

I guess that you are mixing the MIOS device ID with the device ID of the application. They are handled seperately. So, what you need to do is to rebuild the assembler source with DEFAULT_DEVICE_ID set to 0x01 (<- the application device ID), thereafter you have to convert it to a .syx file with -device_id 0x01 (<- MIOS device ID) for uploading it to the core #1 To increase the confusion, the MIDIO128 device ID hasn't to be changed in main.asm, but in app_defines.h I think this is something which should be improved in the next release. The application ID could also be derived from the MIOS ID (in the same way like it has been done for MIDIbox SID), so that no recompile is required. Best Regards, Thorsten.

You can do this in the BPM menu with the datawheel - the sequencer never stumbles when you change a value - it's a live sequencer, and not Cubase or something like that.. ;-) Best Regards, Thorsten.

The MIDIbox Extensions page http://www.ucapps.de/midibox_ext.html shows some examples for CV Inputs, e.g. a Breathcontroller and an analoque LFO. Of course, the possibilities are endless, it's your turn to realize and documentate your ideas :) Best Regards, Thorsten.

Hallo, die Spannungsdifferenz am Eingang ist ok, es kommt also etwas an. Am Ausgang werden Pin 6 und 7 *nicht* gebrueckt. Pin #6 liegt auf Masse wenn die interne LED leuchtet, und ist hochohmig, wenn die LED nicht leuchtet. Der Widerstand R6 zieht den Ausgangspegel auf 5V, wenn der Opto-Ausgang hochohmig ist. R5 stellt den Arbeitspunkt der Darlingtonstufe ein. Du machst doch so gute hochaufloesende Fotos, warum machst Du nicht mal eines von der Unterseite der Core Platine, und postest es hier? Eigentlich ist nur die rechte untere Ecke rund um den Optokoppler interessant - vielleicht erkennt man so ja eher den Fehler Gruss, Thorsten.

Hi, in this example application you have to change the events in mios_tables.inc Best Regards, Thorsten.

Hi, set #define LEDRINGS_ENABLED 0 ; if 1, ledrings are enabled #define METERS_ENABLED 0 ; if 1, meters are enabled and use the now unused DOUT registers for the leddigits: #define LEDDIGITS_ENABLED 1 ; if 1, leddigits are enabled #define LEDDIGITS_SR_SEGMENTS_1 8 ; shift register which drives the segments of digit 7-0 (right side) #define LEDDIGITS_SR_SELECT_1 9 ; shift register which selects the digits 7-0 #define LEDDIGITS_SR_SEGMENTS_2 10 ; shift register which drives the segments of digit 15-8 (left side) #define LEDDIGITS_SR_SELECT_2 11 ; shift register which selects the digits 15-8 Best Regards, Thorsten.

The MIDIbox SID in a C64-II case from Majo. It's especially interesting how he has mounted the encoders/leds/buttons: http://www.midibox.org/midibox_gallery/michele5.jpg http://www.midibox.org/midibox_gallery/michele6.jpg http://www.midibox.org/midibox_gallery/michele7.jpg http://www.midibox.org/midibox_gallery/michele8.jpg http://www.midibox.org/midibox_gallery/michele9.jpg http://www.midibox.org/midibox_gallery/michele10.jpg http://www.midibox.org/midibox_gallery/michele11.jpg

Hi, it seems that either the SCLK or the RCLK line isn't connected properly or has a short. So, just check these signals visually (measuring the voltages is useless here) from the core module (PIC Pin #21 and #22) to the DINX4 modules (pin #1 and #2 of each 74HC165). Best Regards, Thorsten.

Hi Marr, this is exactly for what I've to worry about: a small but required hardware change produces a lot of confusion, regardless where and how good it is documented... please bear in mind that we are currently in a floating process between the old and the new wiring, therefore some hints in the forum and the website are obsolete. The Hardware Mods page is currently the only reference, the other pages (e.g. MBHP_CORE) will be changed in some weeks I think that I don't have to answer all the questions, for you it's only important to know that the isolated cable from J4:SC goes to J10:MD. I've improved the Hardware Mods page, hope that it's less confusing now. The AOUT module is an option and it's not documented yet since I haven't found the time to write down all the infos. It's a very powerful, but also very expensive module and only useful for people who want to control their analog gear directly without MIDI. This module is no must-have! See also: http://www.ucapps.de/midibox_seq_options.html Best Regards, Thorsten.

Hi *, MIDIbox SEQ V2.1 is now available for download. Beside of some bugfixes and improvements it now also features two powerful morphing modes - so, there are a lot of new possibilities (which haven't been explored completely yet ;-)) Download: http://www.ucapps.de/mios_download.html ChangeLog: http://www.ucapps.de/midibox_seq_changelog.html New demo samples: http://www.ucapps.de/midibox_seq_tutorial2.html Have fun! :) Best Regards, Thorsten.

Servus Matze, die MIDIbox SEQ arbeitet ebenfalls mit einer Lookup Table, weil sie weniger Speicher verbraucht als der Code, der zur Berechnung des Timer Reload Values notwendig waere. Bei einer hoeheren Aufloesung macht es natuerlich Sinn, die Tabelle durch eine Berechnungsroutine zu ersetzen. Die muss noch nicht einmal mit Floating Point arbeiten, 32bit Integer sollte ausreichen. Und die Division ist auch kein grosses Problem, es muss ja lediglich durch 60 geteilt werden, und nicht durch einen variablen Wert... Die Berechnung des Reload Values fuer vierfache ppqn ist dann auch kein grosses Problem mehr, dazu wird das Ergebnis zweimal nach Rechts geshiftet (oder man teilt am Anfang nicht durch 60, sondern durch 15...) Shuffle: hierbei muss man sich ganz grundsaetzliche Gedanken ueber die Software Architektur machen. Wenn der Sequenzer auch als MIDI Clock Slave arbeiten soll (was eigentlich der Normalfall ist), so ist es meiner Meinung nach am geschicktesten, entweder die intern generierte Timerfrequenz hochzuschrauben (MIDI Clock Master) oder die eingehenden Clocks mit Hilfe eines Referenztakts zu vervielfachen (MIDI Clock Slave), und diese "Microticks" dann zum Triggern des Sequenzer Handlers herzunehmen. Shuffle selbst ist dann ganz einfach zu realisieren: bei geraden Steps werden ein paar Microticks hinzugezaehlt, und bei ungeraden werden sie wieder abgezogen - wichtig ist nur, dass die Anzahl der Ticks ueber den gesamten Track ausbalanciert ist, so dass bspw. bei einer vierfachen Aufloesung und 16 Steps der erste Step immer nach exakt 384 Microticks gespielt wird. Da die Taktgenerierung ein wenig tricky ist, habe ich sie sogar dokumentiert, damit ich auch nach einem Jahr noch weiss, was ich damals angerichtet habe ;-) ; Some notes to the way how MIDIboxSEQ generates the internal 96ppqn clock ; ; MASTER MODE ; ~~~~~~~~~~~ ; ; The period of USER_Timer will be configured based on bpm_table.inc which ; is a generated file (utils\gen_bpm_table.pl). The values are calculated ; based on the formula: delay = (60 / (bpm * 24)) / prescaler_delay ; ; For a common MIDI clock (24ppqn), 8 should be used as prescaler delay to ; realize BPM rates from 48 to 255 ; But MBSEQ works with 4 times resolution (96ppqn), therefore a prescaler ; delay of 2 is used here ; ; The USER_Timer hook increments the SEQ_CLK_REQ_CTR with every invokation ; which triggers the SEQ_CORE_Clk function. Using a counter instead of a ; request flag ensures that a clock event never get lost, even though the ; sequencer handler won't be called for a certain time - e.g. during a ; EEPROM write transfer ; ; ; SLAVE MODE ; ~~~~~~~~~~ ; ; Could be realized by incrementing the SEQ_CLK_REQ_CTR by 4 with every ; received MIDI clock. But for the current implementation I spent some ; effort to realize 3 interpolated clock events between the received ; MIDI clocks in order to increase the resolution. ; ; This mechanism works that way: USER_Timer is used as reference ; counter which will be invoked every 500 uS. It measures the delay ; between two F8 events by incrementing a counter SEQ_INCOMING_CLK_CTR ; which will be registered in SEQ_INCOMING_CLK_DELAY on the next F8 ; event. ; ; The delay value will be divided by 4, this is the preload value of ; SEQ_SENT_CLK_DELAY which defines the delay between interpolated clock ; events. The SEQ_SENT_CLK_DELAY will be decremented by USER_Timer ; every 500 uS. Once it reaches zero, a clock event will be triggered, ; and SEQ_SENT_CLK_DELAY will be reloaded by SEQ_INCOMING_CLK_DELAY / 4 ; ; The SEQ_SENT_CLK_CTR ensures that never more than 3 internal clock ; events will be triggered by USER_Timer. This is to avoid timing ; failures on BPM sweeps or jittering MIDI interfaces. ; ; And now the trick for stable timings: SEQ_MIDI_NotifyRx_Clk ; (which receives the F8 events) increments SEQ_SENT_CLK_CTR by ; 4 - SEQ_SENT_CLK_CTR. ; ; This ensures that the sequencer will always run in sync with ; the external MIDI clock, and that a 96ppqn clock event never ; get lost, regardless of jitter or BPM sweeps ; ; Copyright (C) 22th January 2004 by Thorsten Klose Gruss, Thorsten.

Hi, more advanced host applications can handle with this - they always send MIDI events out, regardless if a function is controlled from an external MIDI controller or internally (with the mouse or by reloading a snapshot/preset/song) Best Regards, Thorsten.

Hallo, selbst bei niedriger Aufloesung solltest Du kein "poppen" hoeren - die Host Applikation glaettet die Reglerbewegungen (in der Regel...) intern - waere das nicht so, wuerde es auch mit der Maus zu ungewollten Stoergerauschen kommen. Ausser meinen Alps Fadern habe ich bisher nur die Panasonics ausprobiert - zwei davon erhielt ich vor einiger Zeit von Steven_C geschenkt, daraufhin habe ich den MIOS_MF Driver verbessert, so dass auch diese Fader optimal angesteuert werden. Deshalb schonmal die Vorwarnung, dass fuer andere Fader evtl. die Kalibrierungstabelle in mios_mf.inc angepasst werden muss. Die Panasonics sind soweit eigentlich ok, doch der fehlende Touch Sensor ist aergerlich, ohne ihn funktioniert der "TOUCH_SENSOR_MODE 2" nicht so wie beabsichtigt: ;; following setting configures the touch sensor behaviour. The touch sensors of the motorfaders ;; have to be assigned to the DIN pins in lc_io_tables.inc - the appr. IDs are: ;; ID_FADER_TOUCH_CHN1, ID_FADER_TOUCH_CHN2, ... ID_FADER_TOUCH_CHN8 (8 sensors) ;; If the master fader option is used, the ID is ID_FADER_TOUCH_MASTER ;; ;; TOUCH_SENSOR_MODE EQU 0: touch sensor events (pressed/depressed) be forwarded to the host program ;; like specified in the Logic/Mackie Control specification ;; TOUCH_SENSOR_MODE EQU 1: like mode 0, but additionaly the sensors will be suspended via MIOS, so ;; that they are not moved so long as the touch sensor is pressed ;; TOUCH_SENSOR_MODE EQU 2: like mode 0+1, additionally no fader move (PitchBender event) will be ;; sent when the touch sensor is not pressed. ;; ;; The mode "1" by default to avoid circular troubleshooting requests in the MIDIbox forum from people ;; who don't read this information before starting the application. ;; Mode "2" should be the prefered setting if your touch sensors are working properly Dieser Modus bietet den Vorteil, dass trotz der hohen Aufloesung keine MIDI events gesendet werden, wenn man den Fader nicht beruehrt, er sich aber durch Gehaeusevibrationen um ein 100-200 Mikrometer bewegt (so klein ist naemlich der Abstand zwischen zwei MIDI Werten) --- auch die Automation wird dadurch nicht automatisch angetriggert. Doch wer das Geld fuer diese Bequemlichkeit nicht spendieren moechte, kann mit den Panasonics und einer zusaetzlichen Taste (oder einem Schalter) zur manuellen Aktivierung/Deaktivierung der Touch Sensor Funktion sicherlich auch prima leben. Noch zwei weitere Hinweise: falls ihr Euch fuer Alps entscheidet, koenntet ihr mit Balthasar Schmidt (http://www.albs.de) evtl. einen Mengenrabatt ausmachen. Je mehr Leute sich beteiligen, umso besser, deshalb evtl. auch nochmal im internationalen Forum nachfragen Fuer die Panasonics koenntet ihr SmashTV kontaktieren, der hilft bei solchen Sammelaktionen sicherlich gerne, und koennte die Pakete von den USA aus verteilen. Gruss, Thorsten.

Very good! :) Best Regards, Thorsten.

Hi, I don't think that this makes sense - either the MIDIbox should control the LEDs, or the host application, otherwise they could get out of sync. Especially when you load a new song, or recall a snapshot (I don't know which host you are using... Cubase?) the host normaly doesn't remember the button state of the MIDI controller, therefore you should also use the common On/Off button mode and enable toggling in the host application (if it isn't already handled automatically, e.g. on mute/solo, etc..) However, during programming I assumed that somebody could ask for this sooner or later, therefore I've build an option into mb64_midi.inc which allows you to try it out. So - you will see that it will disturb the interaction with the host... ;-) -> open mb64_midi.inc, search for "if 0" (it appears two times in this file). Change it to "if 1" and rebuild the project. Thereafter the LEDs are controlled internally and via MIDI by default (no need for selecting the "MIDI status received" register) Best Regards, Thorsten.

Hi, you have to assign the appr. DOUT registers to the "MIDI status received" registers. See also the midibox64e.ini file within the mk_syx.zip package Best Regards, Thorsten.

Hi, for pin J4:D4 of the second DOUTX4 module (DOUT#SR5) the pin number is 0x2c Best Regards, Thorsten.

Hi John, here some references: http://www.ucapps.de/howto_tools_syxloader.html describes that Serge's SysEx loader should not be used to upload MIOS code or data blocks. This loader is a tool for the old PIC16F based projects. http://www.ucapps.de/mios_bootstrap.html describes the use of MIDI-Ox for uploading code. The last topic "The whole upload procedure" illustrates the whole procedure --- upload MIOS, then the application. So, since the upload with Serge's loader failed, I would suggest that you just follow the instructions from the bootstrap loader page: upload MIOS again with the first level bootstrap loader (means: start the upload within 2 seconds after power-on). Thereafter upload the application (the main.syx file of the application package) Thereafter you could test the application with your DINX4 module - or, if not available - you could tap pin J9:SI of the core module shortly to ground in order to trigger 128 button events at the same time. Once this is working, you can reconfigure the application with the mk_midio128_syx.pl script if required. Best Regards, Thorsten.

Hi John, this explains everything. You have to create a new .syx file for the MIOS core with ID 0x01. You have to do this for MIOS itself as well as for the application. From the README.txt (can be found in the MIOS package): o hex/* contains the same MIOS release in .hex format --- don't burn this file directly into the PIC! The purpose of this binary is to convert the OS into .syx format with different device IDs for the use with the MIOS bootstrap loader: EXAMPLE: perl tools/hex2syx.pl hex/mios_v1_6.hex -os_upload -device_id 0x01 -> generates a mios_v1_6.syx file in the hex directory which contains code blocks for device ID 0x01 instead of 0x00 For the MIDIO128 application: change to the midio128_v2_1 directory and type: perl hex2syx.pl main.hex -device_id 0x01 Best Regards, Thorsten.

Hallo, erstmal danke fuer das Lob! :) Wo faengt man am besten an - vielleicht bei der Verbindung zwischen dem Core und DINX4 Modul. Hast Du das Kabel direkt angeloetet, oder verwendest Du Stecker? Loeten ist immer besser, damit vermeidet man Wackelkontakte. Desweiteren macht es Sinn, die Spannungen am DINX4 Modul durchzumessen. An den ICs muss jeweils zwischen Pin 8 und 16, sowie 15 und 16 ca. 5V anliegen (siehe Schaltplan, dort sind die Pinnummern eingezeichnet). Wenn die Spannungen ok sind, verfolge die Leiterbahnen auf der Rueckseite der Leiterplatte. Siehst Du irgendwelche Kurzschluesse? (also bspw. Loetklumpen zwischen den Leiterbahnen, oder zwei eng benachbarte Leiterbahnen, die aufgrund eines Aetzfehlers miteinander verbunden sind) Gruss, Thorsten.

Und nochmal ein FAQMARKER! :-) Gruss, Thorsten.

Hi John, which MIOS ID is assigned to the core? It's part of the upload request message, so if you are unsure, just write down the complete SysEx string here. Best Regards, Thorsten.

these are dummy IDs. I don't have the money to pay for my own vendor ID, and I haven't found any documentation about IDs which are free for non-profit projects or education... or do you know any? Yes, it was necessary for the case that the MBHP_USB is connected to a mainboard which doesn't switch off the USB power supply after the system has been shut down or suspended. If the interface received some MIDI events during this time, there is a potential risk for a buffer overrun which could lead to invalid MIDI events once the system is available again. Best Regards, Thorsten.

Hi Jeremy, no, I haven't. I've 3 MBHP_USB modules and can plug and unplug them multiple times without the need for a reboot. My mainboard is an ASUS P4P800 Best Regards, Thorsten.

Hi Jeremy, WinME crashed with the AC interface descriptor, thats the reason why I had to remove it. Also the order of the descriptors which are still there is very important, overwise the OS could also crash. After these changes the USB interface was finally regognized by Linux/Mac OSX/WinME/WinXP (yes, home edition, SP1), thats the reason why I think that the problem should be somewhere else. If you don't believe it, just try to change the source code and please report any observations. I don't have the time to debug this release for everbodies obscure installation, I can only estimate where a problem could be located. And from my experiences the errors are always somewhere deep in the undocumented windows APIs or hardware drivers :-( Best Regards, Thorsten.