TK.

At the hardware side, you propably only need one additional DIN register, the same DOUT could be used to select the column. From the software side an extension of sm_fast.inc isn't something which could be typed into this posting within 5 minutes, it especially needs some extensive testing by the same guy who is doing the implementation - means: I cannot really help here, it has to be done by somebody who has access to the appr. hardware Best Regards, Thorsten.

I've read about this effect several times in the meantime, and the error was mostly a swapped RW/E line Best Regards, Thorsten.

I'm already using a modified MBHP_IIC_MIDI firmware to control the SpeakJet, I think that I will release it sooner or later (I would like to add direct control of the reset and config pins before) Best Regards, Thorsten.

Hi Jim, 128 is just a number where I can say, that it works perfectly for most MIOS applications, therefore I set this limit. It's a compromise between CPU load, memory consumption, and electrical parameters (a longer chain - or more DIN/DOUT modules in parallel would require a slower clock rate) However, there are thousands of different, application specific possibilities, but all of them would require a dedicated software driver and different circuits/schematics - I cannot support this, it's too complicated to specify all the requirements and possible variations... Therefore I normaly recomment the use of an additional core Best Regards, Thorsten.

Hi Giovanni, I don't know the possibilities of Waldorf XT, on the other hand I also don't want to throw away the already existing modmatrix concept of MBSID V1 But it could be helpful to get some inspirations, so just send me the documents via email Best Regards, Thorsten.

Just two weeks ago I had the very first case where a bypass cap was really required. I supplied a SpeakJet chip from the core module of my MBSID, and noticed random resets of the SpeakJet - "ReReReaReaadyReadyRRRRe" was all I heard on the audio out, serial communication wasn't possible. I don't know how I came to the idea to add a 100 nF bypass cap between +5V and ground, but it was the solution! I think that I will never forget this design rule anymore ;-) Best Regards, Thorsten.

Hallo Joscha, das sieht schon sehr gut aus. Die Shift Register und pins werden jedoch von 0 gezaehlt Gruss, Thorsten.

Yes, but only under Wintendo with Flash8, not under Linux with Flash7

Screening is important for such distances to avoid interferences with other signal sources, but in general it won't fix the problem. It's more related to signal runtimes, and they depend not only on C, but also on L and R - in other words: on the impedance. This page provides some theory stuff http://www.epanorama.net/documents/wiring/cable_impedance.html, but I must clearly state, that I'm no expert in this area, and cannot say immediately without studiying in my old dusty study books, what could help here. Maybe another cable, maybe a termination resistor, I don't really know. :-/ But maybe there is somebody else who has more experience in this topic? P.S.: it would be worth a try, if it works better, when you are not using two seperate branches for DIN and DOUT modules, but one branch for the Ground/+5V/SC/RC signal (connected in parallel to each module), and the DI/DO signal like before - in a chain Best Regards, Thorsten.

It is a PIC16F877 based MIDIbox64, this can be easily identified by comparing the LCD screen layout. Especially the "[i.1] N" at the upper left corner says everything (no BankStick, Normal mode) So, it's an non-nameized pirate copy. Best Regards, Thorsten.

Hi, ok, now it's more clear to me. Have you ever selected the to-COM option by using the change_id application? Because, if events like 0xff or Pitch Bender are received each 2 seconds instead of the upload request, then it seems that the baudrate is wrong. Or maybe you have specified the appr. ID for the to-COM option during the SmashTV order, could this be? This also means, that the upload of MIOS and the application was not successfull. MIOS Studio should notify this (no checksums). Possible solutions: If you own a PIC programmer, you could program the bootloader with ID 0000000000000000 If you own a LTC module, you could connect the module to the COM port of your PC, upload MIOS, upload change_id in order to set back the ID to 0 If both not available, somebody else who owns a PIC programmer, and who lives close to your location, could help. Best Regards, Thorsten.

I don't want to throw away my existing case, therefore it can be considered, that MBSID V2 will run with the same hardware. New functions will be accessible with special key combinations (e.g. selecting the first modulation matrix: press Edit and E1, the second: Edit and E2, AOUT matrix: Edit and L1, Trigger Matrix: Edit and L2). However, customizations (e.g. more buttons or knobs) will still be possible, but without much support from my side. The "Control Extension" (see below) will add some more control elements in form of a "breakout" box. I just have added following to the CV Out item: Gates should also be provided, they should be part of the trigger matrix (see the possibilities which are listed there). Polarity should be selectable, also the generation of pulses on falling and/or rising edge of the internal trigger source(s). In addition, it should be possible to control the gates from the drum sequencer. The drum sequencer will be organized in a different way in order to save memory. Each note will get a dedicated track. However, it should be possible without much effort to use some of these tracks as source for the trigger matrix Best Regards, Thorsten.

Hi, The big problem is, that you haven't read the README.txt file, at the first lines it's clearly stated: Note that in most situations, only **one** .hex file needs to be uploaded via MIDI. Please read this README carefully in order to select the right binary. Oversight: A) fresh new PIC18F452 with old Bootloader V1.1b B) old MIOS installation C) virgin PIC18F452, own PIC programmer available D) checking if Bootloader V1.1b or V1.2 is installed E) installing Bootloader V1.2 and MIOS V1.9 on a PIC18F4620 A) you got a preburned PIC18F452 from SmashTV or Mike with the old Bootloader v1.1b, and haven't installed MIOS yet. In this case, upload -> pic18f452\midi\update_without_installed_mios.hex via MIDI like described at the http://www.ucapps.de/mios_bootstrap.html page. This .hex file contains MIOS V1.9 and the update program. The updater will: - do a CRC check in order to ensure that the whole binary has been uploaded - replace Bootloader V1.1b by Bootloader V1.2 Some debug messages will be print on screen and sent via MIDI: The LCD will show (if connected): CRC: CBCF ok Countdown: 10 The MIDI IN monitor of MIOS Studio will show: Sysex message: F0 0C 0B 0C 0F F7 CRC Checksum [D0 0A] channel 1: key pressure A#-1 pressure: 0 Countdown 10 [D0 09] channel 1: key pressure A-1 pressure: 0 Countdown 9 [D0 08] channel 1: key pressure G#-1 pressure: 0 Countdown 8 [D0 07] channel 1: key pressure G-1 pressure: 0 Countdown 7 [D0 06] channel 1: key pressure F#-1 pressure: 0 Countdown 6 [D0 05] channel 1: key pressure F-1 pressure: 0 Countdown 5 [D0 04] channel 1: key pressure E-1 pressure: 0 Countdown 4 [D0 03] channel 1: key pressure D#-1 pressure: 0 Countdown 3 [D0 02] channel 1: key pressure D-1 pressure: 0 Countdown 2 [D0 01] channel 1: key pressure C#-1 pressure: 0 Countdown 1 [D0 00] channel 1: key pressure C-1 pressure: 0 Countdown 0 [D0 1A] channel 1: key pressure D1 pressure: 0 Update complete Sysex message: F0 00 00 7E 40 00 01 F7 Reboot (upload request) [D0 1A] channel 1: key pressure D1 pressure: 0 Update complete Once the update has been completed, the LCD will show (if connected): Bootloader up-to-date After this procedure you can upload the application. ... a lot of step by step guides for the other cases... [/code] for your case, A) was the right selection - are there any details in A) which confused you? I would like to know this in order to improve the documentation. this was the wrong selection, but it doesn't hurt - mios_v1_9_pic18f452.hex doesn't contain the start vector at 0x0000, so the dummy start vector which branches to the old bootloader was not overwritten. The result: no effect This should *never* be made because it cannot work (I'm writing this for the case that somebody else is trying the same) So, what happend: the old bootloader wrote the new bootloader to 0x000-0x3ff. But it has modified the reset vector. After a reset, the PIC first branches to the old bootloader, and after 2 seconds to the new bootloader. Both bootloaders have different access rights - and this can lead to data loss. So again: never upload the bootloader .hex file directly, always use the update packages I've prepared. Thats also the reason, why you can find the bootloader binary in the "burner/" directory, and not in the "midi/" directory. this was done by using the new bootloader, which allows to overwrite 0x7c00-0x7fff - the address range where the old bootloader was located. So, you've overwritten the old bootloader yes, you've ruined the bootloader mechanism. The old bootloader prevented to modify the reset vector at 0x0000, now the PIC branches to 0x7c00 after reset, which doesn't contain valid code anymore. no. I would propose to send the PIC to somebody who has a burner. He can burn the bootloader again into the chip. Please note: if he burns V1.2, you need to follow the step-by-step guide of case C) Please never ignore a README.txt file! The bootloader mechanism is very save in the meantime, but there are cases which can lead to failures if you don't follow the right guide. Best Regards, Thorsten.

You can always upload MIOS again with the 1st level bootloader, and any application (also test applications!) with the 1st or 2nd level bootloader. When you are doing the update to MIOS V1.9, you will be on the most secure side that the system is up&running, because the update binary does a CRC check, and it sends some debug messages via MIDI. More details can be found in the README.txt of the update package. So, I think it would be the easiest solution just to try this out. From your posting it isn't clear to me, if MIOS ever has been uploaded correctly - if this doesn't work, the rest will also fail. So, did you ever use MIOS Studio, did you check the messages during the upload? Best Regards, Thorsten.

Yes, MIDIO128 supports up to 128 digital inputs and outputs, and you can change the configuration with the mk_midio128_syx script (this will generate a new .syx dump) without recompiling the code. yes - you could add a LCD for better debugging, but you can remove it later and use it for the next MIDIbox you are building thereafter ;-) Best Regards, Thorsten.

I've started a wishlist for v2, not at least to concretise my thoughts on how to use the new possibilities provided by the PIC18F4620. If you have further suggestions for features, feel free to post them here. There is enough time (ca. a half year) before I will start with the implementation, enough time to change concepts or to consider things, which might be useful as well -> http://www.ucapps.de/midibox_sid_v2_wishlist.html Best Regards, Thorsten.

No, you don't need to recompile the application for such a simple use case (in my eyes the monome controller is very primitive ;-)) - it's time to click on the ucapps button at the top of the forum. Proposed pages: Wiki, MIOS Introduction, Bootloader, MBHP Introduction, Core Module, DINX4 and DOUTX4 module, MIDIO128 Design and HowTo mk_syx Best Regards, Thorsten.

Hi Marcel, in app_defnes.inc, you need to define a new variable, and you have to locate it to a free memory location. Now you are able to increment this variable within the meta handler, and to send the appr. program change command. Especially the memory location is very error prone in assembler, it's easier in C. So, Why not programming this with the C wrapper? Examples for pot and button control are already available Best Regards, Thorsten.

In cv_midi.inc, CV_MIDI_CC has to control a flag on incoming CC#64's (e.g. lets call it MB_STAT_SUSTAIN). CV_MIDI_NoteOff has to be changed, so that the gate flag is not cleared so long the sustain flag is active. But the "intended clear" has to be memorized anywhere (e.g. in a seperate byte), so that the gates which haven't been released by CV_MIDI_NoteOff are cleared when sustain is released. Best Regards, Thorsten.

Yes - please build and test all modules before ordering the panel, this can save you a lot of money if you never realized a panel layout before. Especially determining the right button/fader/LCD dimensions is tricky Best Regards, Thorsten.

It can be realized with the MIDIO128 firmware. For flashing LEDs some modifications would be required, here it's maybe better to get use of the C interface of MIOS so that enhancements are easier. Basically you just need to use following examples: http://www.ucapps.de/mios_c_send_din.html http://www.ucapps.de/mios_c_set_dout.html and enhance it by a timer driven "flashing LED" handler. Best Regards, Thorsten.

First of all you should update to MIOS V1.9 and beta15, because I can see an expired menu structure; programming details are different in the meantime, and v1.7a has some anoying bugs as well. So, it doesn't make sense to work on this old version anymore. The page layout can be customized in cs_menu.inc, CS_MENU_Handler_MainPage and CS_MENU_Page_Root Best Regards, Thorsten.

sometimes such crazy ideas open my eyes, so that I see what I was missing all the time ;-) Thanks for the inspirations! Best Regards, Thorsten.

It's really difficult to answer your question, because in your case (no timecode elements required) I would strongly recomment to change the screen layout so that it matches with your needs. Thereafter you can answer the questions about spacings by yourself - everything is in your hand! With the new C based version it's much easier to customize the layout of the screen, did you already try it? http://www.ucapps.de/mios/midibox_lc_v2_0_alpha1.zip Modifications have to be made in lc_lcd.c, function "LC_LCD_DisplayPageSet" Note that this alpha version is nearly complete, only the support for timecode LED digits is missing yet, since it requires to open my MBLC case for testing Best Regards, Thorsten.

Here are some pictures of Alkex's (Alex's) extraordinary MIDIbox SID, called "Octopus" - enjoy! :) He wrote: