TK.

You've to type "java JSynthLib" (<- with capital letters) or just "run", if you would use the updated JSynthLib package like suggested above. Best Regards, Thorsten.

Nice to hear that your core was running immediately! :) The problem with SysEx support is, that the .syx generator has to be aligned with the application every time you make changes in the configuration tables. Every new or changed function leads to special effort, and once people are using the script and saving their tables in this fixed format, it will be much harder to implement changes. So, it could make sense to create a comfortable SysEx configuration mechanism once this application has reached a state where you are sure that it won't get dramatic changes anymore (after one year or so...), but before it would be wasted time. Especially when you take into account that the configuration within an assembler file (-> see midio_presets.inc) is also simple and that the upload of new code just takes some seconds - it's just another way to define the setup. By using additional constant definitions and macros, the assembler file could look very similar to the midio128.ini file, only drawback is that the user has to download the assembler tools (see http://www.ucapps.de/howto_tools_mpasm.html) Best Regards, Thorsten.

Hi Seppoman, of course, everything is possible, but the trade off isn't so high. You definitely need a seperate uC which does nothing else then to generate the waveform(s) and to send them to the DAC channel(s). Kilian Leonhardt realized this with a multi chip solution - with success, but it took him one year (-> http://www.rozzbox.de). I think a really powerfull feature is the possibility to add analog waveform generators/filters/LFOs/ENVs/etc... to the SID, and this is already possible with the current MBSID implementation, you only have to use it Best Regards, Thorsten. P.S.: my plan for end of this year is to start with MIDIbox FM, an OPL3 based synthesizer with FM synthesis - just to let you know that I don't feel boring ;-)

Der Vorteil an RS ist, dass die einfach alles haben, und der Nachteil, dass die Komponenten zu Apothekenpreisen ueber die Theke gehen :-( Gruss, Thorsten.

Hi, you don't need a meta event, you only have to specify different "velocity" values for the note which controls the radio button section. And you have to set the button mode to "OnOnly", so that no Note Off (with zero velocity) is sent when the button is released. Example (in midibox64.ini format). I'm assuming that the radio button group is assigned to Note Number 0x30 (C-3). Of course, you can do the same with CC's... # The first five Buttons control the Shaper mode 1 = 90 30 00 @OnOnly 2 = 90 30 20 @OnOnly 3 = 90 30 40 @OnOnly 4 = 90 30 60 @OnOnly 5 = 90 30 7F @OnOnly Best Regards, Thorsten.

You will find the "run.bat" file only in the special MIDIbox SID release with the updated driver module for MBSID V1.6 See http://www.ucapps.de/midibox_sid.html, search for "Updated version of JSynthLib" Best Regards, Thorsten.

So long it's ok for you to modify the table directly in the source code, and don't rely on any SysEx editor or mk_xxx_syx.pl script, it isn't so much effort. At least 16k internal flash are still unusued in the sm_example2 application, this means that you could define up to 2730 complete "On" and "Off" events (2 * 3 bytes) in the same way like in the MIDIO 128 project (see midio_presets.inc, search for "MIDIO_Presets_OffsetOut"). A table of 1024 On/Off entries allocates 6*1024 = 6k bytes I will create the other drivers next weekend. Best Regards, Thorsten.

Hi, oops! This is caused by a incomplete 16bit addition. Bugfix: open "midio_midi.inc", search for following lines: MIDIO_MIDI_PrepareDINEventOff ;; off event: add 3 to address movlw 0x03 addwf MB_ADDRL, F MIDIO_MIDI_PrepareDINEventOn and exchange it by: MIDIO_MIDI_PrepareDINEventOff ;; off event: add 3 to address movlw 0x03 addwf MB_ADDRL, F movlw 0x00 addwfc MB_ADDRH, F MIDIO_MIDI_PrepareDINEventOn I will upload a new MIDIO128 release soon. If you have a special whish for this release (minor feature which could be useful for you), just let me know :) Best Regards, Thorsten.

Hi Xile, you have to set the "MIDIbox-to-COM" flag in the ID header of the PIC, so that the alternative baudrate is selected after power-on. This is explained at the http://www.ucapps.de/mios_bootstrap.html page. Yes, you have to use a 1:1 cable, the same like for the JDM. See also the http://www.ucapps.de/mbhp/mbhp_ltc_orderlist.txt Best Regards, Thorsten.

Thank you, Pay_c :) To the first issue: maybe the fixed gatelength is too long, you can change it in seq_morph.inc, line 71. Try "movlw 0x10", this should avoid legato. Best Regards, Thorsten.

Hallo, alles deutet darauf hin, dass etwas mit der SCLK oder RCLK Leitung nicht stimmt. Entferne mal alle ICs aus den Sockeln, schalte Dein Multimeter auf Widerstandsmessung (oder falls es einen Durchgangspiepser hat, dann nimm den), und miss die Verbindungen zwischen PIC Pin #21 und #22 und den 74HC165 Pins #1 und #2 durch. Zwischen diesen beiden Leitungen darf kein Kurzschluss bestehen. Sie duerfen auch nicht mit Masse oder 5V verbunden sein, das laesst sich mit dem Multimeter sehr schnell ermitteln. Am besten druckst Du auch mal die Schaltplaene aus, das erleichtert die Orientierung. Gruss, Thorsten.

Since these applications are very complex, it isn't possible to combine them to one firmware. But you are able to swap between the applications in between 10 seconds, just upload the appr. .syx file I would suggest to build the hardware based on the MIDIbox SEQ plans. The MB64E package comes with a prepared setup which runs also with this hardware. And a Logic/Mackie Control emulation setup is also planned. Best Regards, Thorsten.

I've noticed that the .syx file within the sm_example wasn't up-to-date, so please download the new package. It's now possible to use a scanmatrix with diodes in the other direction by swapping the column and row lines, and by setting SM_SWAP_CR to 1 in sm_simple.inc Best Regards, Thorsten.

John, thats a very good explanation about the SRIO driver - we should add this to the Wiki once it's available. Jim: maybe the best documentation is just to write a report who you've realized your project (with a lot of pictures). I guess that not only the scanmatrix driver is for interest, but also the hardware around it. Here is an example: http://mmd.foxtail.com/Tech/mvdReijden.html Yes, you can use the analog input driver in parallel. It runs in background and doesn't add that much jitter. Ok, here some news: today a friend brought me a keyboard from an older synth so that I was able to test the new, optimized scanmatrix driver: The contacts are realized with springs - thats a big advantage, because this allowed me to verify the debouncing routine. The DIN/DOUT register is soldered on a breadboard: The new driver can now be found in the MIOS download section (sm_example2_v1.zip). I've measured the capturing cycle for 64 nodes with a scope, it's 80 uS, so much less than expected! :) Jim: which MIDI events should be sent by the various buttons? Best Regards, Thorsten.

Currently the matrix driver uses the general timer interrupt driven SRIO handler which has been designed for the common approach for up to 128 digital INs and OUTs, the target was to capture as much registers as possible with lowest system load, so that a lot of other tasks can run additionally without affecting the realtime behaviour: in between 1 mS all tasks should be finished. The handler is called every millisecond and consumes ca. 16 uS for each DIN/DOUT shift register pair, makes ca. 128 uS for 16 DIN/DOUT registers. The DIN and DOUT registers are captured/loaded in parallel, the DOUT data gets valid after the DINs are captured, therefore it doesn't make a big difference how much DINs and DOUTs are chained, the longest chain defines the overall delay. If the core has nothing else to do than to scan a matrix and to receive/transmitt MIDI events, it makes sense to bypass the common driver and to write a dedicated one which isn't called periodically, but every time when nothing else is to do (means: from USER_Tick - the mainprogram) By doing so, an overall latency of ca. 8*20 uS can be achieved for a 8x8 matrix, maybe 16*80 uS for a 16x32 matrix Some Jitter has to be expected, caused by the MIDI handlers (they are buffered and therefore don't stall the system) and for the debouncing counters which still require a timer interrupt, but this isn't a big problem when we are speaking about a latency of much below 200 uS My suggestion: discuss about some useful hardware setups and draw the schematics. Once they are available, I will program the drivers for you. My own effort is low, since all routines do already exist, I only have to rearrange them... my effort would be higher if I would also have to documentate the stuff ;-) Best Regards, Thorsten.

A very noble MIDIbox controller made by Josh aka Jost (Michigan, US)! He wrote:

Hallo Lemonhorse, das AOUT Modul gibt es sogar bereits in Mikes Elektronikshop, ich bin lediglich noch nicht dazu gekommen, es zu dokumentieren, da es soviele Konfigurationsmoeglichkeiten gibt. Den Schaltplan findest Du hier: http://www.ucapps.de/mbhp/mbhp_aout.pdf, das Bild vom Prototypen hier: http://www.ucapps.de/mbhp/mbhp_aout.jpg Die Filterschaltung werde ich nicht layouten. Ja, die Schaltung ist leicht modifiziert, dazu kann vielleicht Hallucinogen etwas schreiben (von ihm habe ich die Bauteile und den Schaltplan erhalten) AOUT und SID: ja, die Pinbelegung steht in sid_aout.inc Momentan geben die acht Kanaele die Werte der vorhandenen Modulationsmatrix aus (also Pitch V1/2/3, PWM V1/2/3, Filter), sowie den Resonanzparameter. Langfristig plane ich eine eigene Modulationsmatrix fuer alle acht Kanaele. Das wird eine reine Softwareaenderung, das CS muss hierfuer nicht erweitert werden (die LEDs zeigen entweder die normale, oder die AOUT Matrix an, mit einer speziellen Tastenkombination kann man dann zwischen den beiden Anscihten umschalten) Gruss, Thorsten.

Hi Jim, for somebody with programming experiences it should be very easy to adapt the code to any hardware constraints he want. But a user-friendly configuration would make the whole thing more complex, that means: slower (reduced performance due to variables) and error-prone (normaly every possible configuration should be tested in reality) I would suggest that we define three or four useful setups, for which I could provide the source codes. The "scanmatrix drivers" have to be tested by somebody else. Everything else will lead to a configuration disaster ;-) Best Regards, Thorsten.

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.