TK.

Basically we need a long term solution for "living documents" which can be created and modified easily by a group of volunteers. Currently we have two platforms for this: the forum and the MIDIbox portal. To give you an expression, here an example for a forum based documentation: (1) http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=misc;action=display;num=1061917936 And here an example from the Portal: (2) http://www.midibox.org/users/jim_henry/building_a_midibox_lcd_cable.pdf Advantages of (1): low administration effort, searchable, very easy editable (not only by the original name, but also by the moderators), fast load time, possibility for other users to add interesting comments, questions and answers Disadvantages of (1): limited formating capabilities, difficult to add pictures, not printer-friendly, no possibility to arrange the topics to a book structure Advantages of (2): best formatting, very printer friendly, easy to add pictures/schematics/etc. Disadvantages of (2): only editable by the document owner (in worst case only with a commercial system dependent software), impossible for others to integrate changes (e.g. due to new hardware), long load time, not searchable (only in the document itself) I think that a mixture between a Wiki (which provides similar editing features like the forum) and a motivated maintenance as backbone (which arranges the topics, takes care for picture/schematic uploads, keeps the contributions up-to-date and not at least takes care for the system installation) could help to improve the documentation a lot. As Marr mentioned it makes sense that many people take care for small tasks, otherwise it can take months for the launch, the publication of new topics can take weeks and as a result the knowledge base will always be out of date. For myself it would be important that I've the possibility to change details very quickly, e.g. on software or hardware changes to avoid contradictions between the specs and the implementation. Btw.: here's a Wiki I've used some time ago and which I found very useful: http://alsa.opensrc.org/, but I fear that the MIDIbox Documentation requires a deeper tree structure (and therefore another Wiki software) midibox.org: traffic ca. 11GB/month, 1000k hits, low bandwith (the webspace is very cheap), ca. 100 MB data ucapps.de: traffic ca. 4GB/month, ca. 200k hits, high bandwith, ca. 70MB data Best Regards, Thorsten.

Isn't it possible to host it at the midibox.org server? (I'm asking because you already have the password... ;-)) Best Regards, Thorsten.

Hi, just follow the instructions under http://www.ucapps.de/midibox_sid_csB.html ("Preparation of PIC18F cores") Don't forget to update to MIOS V1.7 (thats only possible with the first level bootstrap loader during the first 2 seconds after power-on) Best Regards, Thorsten.

Witzig - das war mein erster Gedanke: diese Schaltung muss ein Schueler oder Lehrling aufgebaut haben :) Wenn gar nichts mehr geht, kannst Du mir das Core Modul natuerlich zuschicken, aber lass es uns erstmal mit den Testschaltungen versuchen. Mir geht es vor allem darum, langfristig eine Sammlung aufzubauen, die alle bekannten Fehlerfaelle abdeckt. So, und hier die neue Testschaltung: Gruss, Thorsten.

Design by D2k - nothing more to say! :)

Mir hats die Sprache verschlagen, ein so sorgfaeltig aufgebautes Core Modul habe ich noch nie gesehen! :) Nein, am Modul kann es nicht liegen. Ich werde mir morgen ueberlegen, wie man den Optokoppler noch einfacher durchmessen kann. Gruss, Thorsten.

Hi, this is no MIOS programming question - this intention of this board is to share knowledge about coding an application. However, to your question: you can use any plug and socket you want, SubD-9 is just the cheapest solution. Normaly the application provides a software interface to program the BankStick, e.g. via SysEx. But this is really very application dependent. The BankStick is not comparable to something you know as USB Memorystick or similar, a computer cannot program it directly, only via a MIOS core module Best Regards, Thorsten.

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.