TK.

Hi, after you've uploaded MIOS and the main.hex (! not the main.asm !) file of MB64 to the PIC, the single pot should send 8 CCs at once (since it isn't multiplexed via AIN) If not, the pot is propably not connected correctly? One outer pin has to be connected to ground, the other outer pin to +5V, the middle pin (taper) to the analog input. Best Regards, Thorsten.

The disadvantage is, that such a method doesn't allow to change the master clock dynamically from the host application, you always have to readjust it, and thats not flexible enough. A combination of the BPM detection routine used in the MIDImon + the clock pin output routine used in MBSEQ and MBCV would bring very accurate results. Unfortunately so many people are requesting new features from me, that I'm propably not able to combine the two codes this year - anybody else? It isn't so difficult, and it could also be made in C instead of assembly. Finding out how it can be realized was the main effort, and I've added a lot of comments to the code in order to make the functionality clear. Best Regards, Thorsten.

No, you don't need new boards - the main difference is, that the oscillator will be removed (see also http://www.midibox.org/forum/index.php?topic=5748.0, and that a 1:1 pinning to J10 of the core will be possible. The circuit will be the same. If you want to fix the oscillator issue, then just don't mount it and connect the SID clock input directly to PIC Pin #17 like described at the MBHP_SID page. (the purpose of the new layout is, to make it more newbie friendly...) Best Regards, Thorsten.

Ok, v2.4a can now be downloaded from the MIOS download page: http://www.ucapps.de/mios_download.html New features: if not in songmode, the Fwd and Rew button can now be used to increment/decrement the menu value. This is a nice alternative possibility for "fine adjusting" values without the datawheel the clock rate of the external clock pin is now selectable from 96 ppqn to 24/13 ppqn in the BPM menu - just press one of the 16 general purpose buttons. With 96 ppqn the clock output is permanently 1 (thats not a bug) 24 ppqn is the standard setting (GP button #4) a new option has been added which allows synchronized pattern switching, the pattern will be changed with the next measure (after the 16 steps of the "master track" have been processed) a new option has been added for arpeggiator mode which avoids that the track position will be reset if no note/chord is played there is a new "MBSEQ Options" menu page which allows to select these two new features online Have some fun :) Best Regards, Thorsten.

Is anybody else interested in such features? Best Regards, Thorsten.

I will consider this in the next release (as well as the synchronized pattern change feature and a "don't reset arpeggiator when keys depressed" option) Best Regards, Thorsten.

Hi, it shouldn't be a big problem to realize this, the timings are pretty stable. Of course, this depends on the CPU load, but so long the application is doing nothing else than receiving MIDI clock, determine the BPM and sending/generating a MIDI clock to slaves, you can expect a latency of less than 100 uS and a jitter of less than 20 uS! Even if the CPU is doing some additional stuff, the latency should always be less than 1 mS (thats for example the jitter of MIDIbox SEQ). For comparison: todays USB interfaces for PCs have mostly a latency of > 10 mS, and a jitter of +/- 5 mS! Especially the jitter does hurt if you are planning to sync external devices, therefore I prefer to use my MIDIbox SEQ as a MIDI clock master. You could use the "clockbox" application as basis for your project, it's easy to build: http://www.midibox.org/forum/index.php?topic=5691.0 and since it's written in C, it's also easy to enhance by additional features. E.g., in order to get the same functionality like the Sync2 device, a BPM detector has to be added - and a good timing interpolation routine, which compensates the jitter effects of your PC application. Best Regards, Thorsten.

This is a nice looking MIDIbox SID (Step A) built into a "razor box" by Thomas, he wrote (in german - use babelfish.altavista.com for a translation):

The error could also be located in the circuitry around the transistor, thats hard to say without seeing your PCB Do you have a digicam? Maybe you could make a snapshot of the bottom side and post it here? Best Regards, Thorsten.

After an email exchange it turned out, that this venture was mainly planned as a "sell-out" of existing MIDIbox projects. Especially when somebody expects help from the community if he runs into problems (...and who should support the customers?), and if no programming knowledge is available to implement new applications, I'm forced to stop this before it's too late. Therefore: DENIED However, you are always welcome to contribute to the community without making commercial profit Best Regards, Thorsten.

ACCEPTED Reasons: new application has been developed. Source code, hardware specs and additional documentation will be published so that everybody can build (and modify) the controller without purchasing it from Adrian. PCBs are delivered from SmashTV, this will help to keep his service alive Best Regards, Thorsten.

No, you don't have a problem, since you don't need a MIDI Out, and since I would prefer to use the same pins like for the BankStick for the Tx pin replacement (Soft-IIC, transfer maybe to second PIC with reliable USART, speed is fast enough, second MIDI In would also be possible). You see: such questions will raise the need for additional documentation and support... :-/ Best Regards, Thorsten.

yes (but note that nobody has written a companion firmware yet...) In theory it should also be possible to get the MIDI interface properly running, when an external serial transmitter is used - e.g. via the IIC interface. If Microchip is not able to fix the problem until this summer, this is propably the way I will go (even it will cost me a lot of documentation and support effort...) Best Regards, Thorsten.

This is an older erratum which only mentions the 9bit mode... Note that the workaround suggested there is not sufficient for continuous (back-to-back) transmissions over the MIDI interface. E.g., if a SysEx string should be forwarded which is longer than the transmit buffer, a buffer overrun will occur. Best Regards, Thorsten.

As some of you have already noticed, the linker sometimes fails if your .c code gets use of multiplications, divisions, pointer operations, etc... the main reason is, that the win32 release of SDCC doesn't include the important libsdcc.lib file, which contains the object code of functions which are used for such operations. Note that the official libsdcc.lib file is not MIOS compliant anyhow, some modifications have to be made. Therefore I've created a special library, which can be downloaded from here: http://www.ucapps.de/mios/mios_libsdcc_v2_5_0.zip The details (e.g., how to integrate this into a MIOS project) can be found in the README.txt file Best Regards, Thorsten.

I think you've got anything wrong. My permission is only required if somebody wants to sell a project which is based on the MIDIbox platform. I must highlight that this was initialiy not planned from my side, but over the last years it turned out that such an option is required in order to allow a legal path for somebody who has developed an innovative device and wants to sell it to interested users who don't have the skills to DIY it by themself. The intention is, that even if he makes money with a project based on my platform, the he must publish all sources/schematics and in best case also some documentation which is required to recreate the project without purchasing it. Regarding the hardware license: the Creative Common license fits very well with my requirements, especially the term which you've left out in your quote: yes, and this problem has been discussed several times in this forum (I'm a little bit tired to share my oppinions again and again...) - I also don't follow it so strictly like propably required, because there are just things which cannot be prevented, and things which make more fun than spending weeks in discussions about the bad guys in the world... Best Regards, Thorsten.

Hi Goule, in the clockbox application you will find an assembly based division routine in "mclock.c" (search for __asm) However, here another hint: if your program just only converts value A to B based on static parameters, then you could also use a table (constant array) with the required number of entries. This is significantly faster, and for common CC's it doesn't consume that much memory (e.g. a table of 128 entries allocate the same memory like 64 instructions) I'm normaly using perl scripts to calculate such tables, example: #!/usr/bin/perl print "const unsigned char exp_table[128] = {\n "; int i; for($i=0; $i<128; ++$i) { my $value = int(0x80 * (1-exp(-$i/32))); printf "0x%02x, ", $value; if( !(($i+1) % 8) ) { # linebreak printf "\n "; } } print "};\n"; [/code] generates: [code] const unsigned char exp_table[128] = { 0x00, 0x03, 0x07, 0x0b, 0x0f, 0x12, 0x15, 0x19, 0x1c, 0x1f, 0x22, 0x25, 0x28, 0x2a, 0x2d, 0x2f, 0x32, 0x34, 0x37, 0x39, 0x3b, 0x3d, 0x3f, 0x41, 0x43, 0x45, 0x47, 0x48, 0x4a, 0x4c, 0x4d, 0x4f, 0x50, 0x52, 0x53, 0x55, 0x56, 0x57, 0x58, 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x65, 0x66, 0x67, 0x68, 0x69, 0x69, 0x6a, 0x6b, 0x6b, 0x6c, 0x6c, 0x6d, 0x6e, 0x6e, 0x6f, 0x6f, 0x70, 0x70, 0x71, 0x71, 0x72, 0x72, 0x72, 0x73, 0x73, 0x74, 0x74, 0x74, 0x75, 0x75, 0x75, 0x76, 0x76, 0x76, 0x77, 0x77, 0x77, 0x77, 0x78, 0x78, 0x78, 0x78, 0x79, 0x79, 0x79, 0x79, 0x79, 0x7a, 0x7a, 0x7a, 0x7a, 0x7a, 0x7a, 0x7b, 0x7b, 0x7b, 0x7b, 0x7b, 0x7b, 0x7b, 0x7c, 0x7c, 0x7c, 0x7c, 0x7c, 0x7c, 0x7c, 0x7c, 0x7c, 0x7c, 0x7d, 0x7d, 0x7d, 0x7d, 0x7d, 0x7d, 0x7d, }; Best Regards, Thorsten.

There is no workaround... The forum message still exists, just the URL has been changed (fixed) Two days ago Microchip closed my case with following message (one of my initial questions was, what will happen with the PIC18F452) Best Regards, Thorsten.

it depends on your endurance while soldering so many buttons and diodes ;-) Best Regards, Thorsten.

it could have blown the fuse of the PSU, but it can be easily exchanged Best Regards, Thorsten.

uploading (and especially updating) MIOS through a master core is not trivial, because you need to reset the slave seperately. Since the MIDI Out of your slave is not connected to the PC, MIOS Studio cannot determine if a code block was uploaded correctly. For an expert it's easy and comfortable to upload code in this way so long he knows what he is doing, but for a newbie it's just too error prone, and it's especially hard to think about what went wrong here (too many possibilities). Therefore I will change the suggested upload procedure for the slave modules at my website - thanks for testing! Best Regards, Thorsten.

It could be, that this was caused by a temporal short circuit caused by the probes. The propability that this fried your chips is low, but it cannot be excluded. I just had an idea for a simple check of the transistor amp circuit: instead of using the SID, you could attach another audio signal (e.g. from a radio or a walkman) to pin 27 of the empty SID socket. You also need to connect the ground to pin 14 - now you should hear some sound at the audio out Best Regards, Thorsten.

I haven't continued, because nobody gave me feedback if the example works in real life. This would also be interesting for me ;-) I only tried it very shortly with the old keyboard of a friend. I won't be able to test larger matrices, therefore my hope is, that somebody with the appr. hardware and assembly skills enhances and example for a larger number of inputs. (Note that I by myself have absolutely no advantage of this project, therefore it's really low priority for me to support variations) Additional info: from the technical point of view, scanning 1024 buttons organized in a matrix is no problem, and it will work with very low latency (< 1 mS, so faster than a single MIDI event could be transmitted) Best Regards, Thorsten.

Kepping informations consistent isn't that easy, especially because of the fact, that the wiki is currently not editable due to php incompatibilities. However, a first try to explain my "whishes" more explicitly can be found here http://www.midibox.org/forum/index.php?topic=5758.0 Please let us know, which license your friend has finally taken, inspirations are always welcome Best Regards, Thorsten.

Hi Justin, this requires a note stack which queues the played notes. As mentioned above, examples can be found in MBSID/MBFM/MBSEQ/MBCV Next saturday I've some time to make a first try for the new "Magic Chord" application, it will get a note stack based on C, which will be easily reusable for other projects Best Regards, Thorsten.