TK.

Just upload MIDIO128, it will send a MIDI event when a DIN changes. It's the most powerful debugging help, because in combination with a MIDI monitor you can follow the pin toggles in a logfile/window PSU: not my area of competence ;-) Best Regards, Thorsten.

if you want to have a cheap synth with less features than today, a combination could be possible. But if you want a really powerful synth, not only the firmware should focus on a single soundchip, but also the user interface (-> front panel) I don't think so, it would result into a synth with a lot of compromisses, not only because of the additional code memory consumption. Ok, the PIC18F4620 provides twice the memory, but I want to fill it with new MBSID features, and not with hardware options which most people would never use I've read the microwave manual and can confirm, that the modulation possibilities are much more flexible. A short summary: there are a lot of modulation sources, not only LFOs and envelopes, but also different MIDI events and especially the 4 modifiers. The 4 modifiers allow to combine two modulation sources with a mathematical operation. E.g., "LFO1 / LFO2" or "MIDI Note * Modwheel" - and even complex operations like "LFO1 S&H LFO2" or "Modwheel filter" (applies a low-pass filter). The modulation matrix allows 16 connections between any modulation source to any modulation target with individual depths - and there are much more targets than on MBSID (e.g. also ENV and LFO parameters, Depths of modulation assignments, etc...) Of course, the possibilities are great, but I also see some drawbacks, and I guess that I've to think very long about a concept which matches with my own requirements. a) Microwave provides only 16 modmatrix connections instead of 128 (MBSID V1) resp. 384 (MBSID V2) - so, some MBSID sounds won't be possible anymore b) the usage is more complicated - creating a modmatrix routing takes more time than just enabling the "prepared" matrix connection on MBSID c) all modulation targets require some special code, I fear that this will slow down the engine so much, that the current update frequency of 1.22kHz cannot be ensured anymore, instead I assume an update frequency of 500 Hz or slower. This will also affect the current MBSID sound d) the RAM consumption for buffering the target values will be so high, that some other features might be cancled e) the front panel doesn't match with the different matrix concept anymore, but using my existing front panel is one of the strongest requirements The performance drawback for "16 modmatrix routing paths" provided by microwave instead of 384 "modmatrix nodes" provided by MBSID V2 might sound confusing, but this is related to the implementation (the modmatrix nodes are using prepared waveforms, they are just added to the destination) But I don't want to say that I'm not impressed about the possibilities, especially the modifier concept is interesting. Maybe MBSID V2 could provide similar possibilities by enhancing the LFOs - so that they can be alternatively used as generic modulator with two source inputs and an operator. I will think about this... Best Regards, Thorsten.

Hallo Jack, der Bootloader laeuft auch auf dem PIC18F4550, wenn man bspw. PIC_DERIVATIVE 2 waehlt, und die Configs fuer PIC18F4550 anpasst - doch ich selbst verwende lieber den USB Bootloader von Microchip. Code Upload via USB macht einfach mehr Spass, die GUI ist supereinfach zu bedienen, und selbst fuer Linux gibt es mittlerweile eine Kommandozeilen-Version, die problemlos funktioniert. Ich habe kein Interesse an PCBs (habe noch zuviele eigene Projekte am Laufen ;-) Gruss, Thorsten.

Sidenote: with the new mkmk.pl script (part of the most recent C wrapper release), it's possible to integrate assembly modules (.asm files) into a C project. The assembly code must be relocatable (means: it requires a data and code section, absolute addresses should not be specified). An example can be found in the midi router package, see MAKEFILE.SPEC how to add .asm files, and see int_midi.asm/int_midi.h, how a relocatable module looks like Best Regards, Thorsten.

If somebody shoots new pictures or writes better documentation -> please add this to wiki Best Regards, Thorsten.

I also think that this is a problem with the DIN module - just use MIDIO128 and srio_interconnection_test for debugging Best Regards, Thorsten.

Hi, I'm not a Mac user, but somebody reported that the "Syx Librarian" works fine: Just increase the pause between messages until no new message is sent before the reply has been received from the MBSID Best Regards, Thorsten.

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.