TK.

I'm planning on a 16x16 MIDI interface based on the cyclone board http://www.futureelectronics.com/promos/cyclone/ as a FPGA entry project --- so, no PICs for this project, but least latency Best Regards, Thorsten.

I fear that there is no simple formula to calculate the required resistor values for muliplexed LEDs, because the brightness has a non-linear curve which you maybe can read in a datasheet (if it exists...). So, just try out different values :) Best Regards, Thorsten.

Did you push the Link button? -> see also http://www.ucapps.de/midibox_sid_csB.html Best Regards, Thorsten.

J14 is not the right pin, from the MBHP_SID page: so, if sharing the clock from a single crystal doesn't work, why not using the PIC clock output of PIC Pin #17? Best Regards, Thorsten.

Of course, but this is no solution for graphical LCDs or for MIDIbox FM (where the 8 data pins are directly connected to the OPL3 data port). However, people with small assembler skills should be able to re-assign the IO pins for their needs, this saves me from writing new documentation for most of the existing projects ;-) The applications are always written in a way which allows to define a new pinning by changing constants in the program header. Depending on the hardware which is connected to the core module, the user can decide by himself which pins are the best for his setup. To the app note: this describes how to write a driver for RS232 replacement and won't help you for MIDI. The MIDI driver will be similar to the MBHP_USB software (which gets also use of a legacy driver...) Best Regards, Thorsten.

A MoogModular MIDIBox made by Gene: More infos can be found at his website: http://www.ggbnet.com/midibox.html

The MIDIbox SID of Seppoman --- he wrote: --------------------------------------------------------------------- Here are some pictures of my new MidiBox SID, called "Der Brat." (difficult to translate... the german verb "braten" means "to fry something" (on a pan using fat) so if a sound "fries", it sounds fat... nevermind ;) ). It is a MB SID with only one SID 6581, but with a slightly changed control surface. The nine keys on the right provide direct access to the submenus, with "return" you get directly back to the preset selection - no more need to step up and down through menus. The Menu encoder is only used for patch selection, and for scrolling in the OSC and Config menus. Below the 2x40 LCD are ten soft/assign encoders so you have direct access to every shown parameter. I find the box faster to use this way, but it´s also less "future-proof"( fixed number of menu keys...) The switch behind the RUN/STOP key is the original shift lock switch from the C64 keyboard and toggles a relais (Power). The Commodore key toggles between normal menu soft encoder function and a "fun layer" - that´s a collection of parameters I found useful for live tweaking (the white encoder labels). I wanted this key to be illuminated from behind when "fun mode" is active but found it too complicated to achieve a clearly visible but indirect lighting, so I will use a bi-color LED as power LED to indicate the status. Today I borrowed professional photo lights and color filter foils from university and took a few pictures: These are made using only green and a bit of purple light - the MB SID is definitely red and the pictures were not processed in any way :) Some from the inside (just flashlight...). The key pads were built using old Cherry typewriter replacement switches. I used them because the C64 keys fit perfectly. But the switches are very long so I needed to bury them in a huge amount of hot glue...

Hi JR, hard to say, I don't know this effect from my own hardware Problem is that I only had the chance to try Alps and Panasonic faders with my driver. I'm no "motorfader expert", and I don't know how the drivers of commercial devices are working. Therefore I cannot tell you if my implementation is qualified for each motorized fader/pot available on the market... however, if you are not able to get it running, you are free to send me the fader so that I can try to make adaptions (if required...) yes, thats a good indicator. Maybe it's worth a try to change the MIOS_MF_GetSpeed table in mios_mf.inc - it varies the PWM pulsewidth depending on the distance between current and target position. Best Regards, Thorsten.

Hallo Heinz, nein, die gleiche Funktionialitaet laesst sich leider nicht in MIOS realisieren, da der softwaremaessig implementierte MIDI Eingang auf eine extrem niedrige Latenz angewiesen ist, so dass nebenher nicht mehr viel laufen kann --- es sei denn, man spendiert eine Menge Programmieraufwand, aber den moechtest Du ja gerade vermeiden. Besser waere es evtl., den PIC16F877 vor dem MIOS Core zu schalten Gruss, Thorsten.

Hallo Bernd, ja, auch ohne externes Programm kann man die MIDIbox konfigurieren, denn auch sie bietet eine MIDI Learn funktion. Dafuer muss man jedoch ein LCD anschliessen. Wenn Du das nicht spendieren moechtest, bleibt noch das mk_syx Script, mit dem man die SysEx Konfigurationsdatei auch auf einem Mac erzeugen kann. Das mk_syx.zip Package enthaelt uebrigens eine vorkonfigurierte .syx Datei fuer Programme wie Reason, deren MIDI Events man vom Program aus selber einstellen kann -> midibox64_generic.inc Damit senden die Potis CC#00-CC#63, und die Buttons CC#64-CC#127 auf MIDI Kanal #1 Gruss, Thorsten.

Better to sell this on Ebay (also Six Packs are sometimes sold with big success ;-)), because my shelfes are already heavily filled with such stuff Best Regards, Thorsten.

You've already programmed this correctly (although you are new to uC programming --- thats good news! :)) MIDI is a very simple protocol, only runtime messages >= 0xf8 are allowed to interrupt the transmission of a MIDI event. So, if your parser ignores all bytes which are greater than 0xf8 (you will find this in most MIOS applications), then you are always on the save side. MIOS itself waits until an incoming MIDI command has been completely received before a notify function for AIN/DIN/ENC events is called. Therefore the Patch name will always be printed completely before a changed expression pedal value will be notified. Best Regards, Thorsten.

Hi JR, there is already a timeout mechanism in the MF driver which ensures that the move event will be skipped if the fader didn't move within ca. one mS. So, this cannot be the reason (FYI: the driver is located in mios_mf.inc) First suggestion: connect a LCD, it gives you a lot of important debug informations! Second suggestion: upload the Jitter test and determine the jitter on your fader. It should be less than 3 Third suggestion: the AIN deadband *must* be less than the MF deadband. The AIN deadband should be >= the jitter. So, 3 is normaly a save choice for AIN and MF deadband. I can propably give you more input once you reported the new observations. Best Regards, Thorsten.

Great Huw! :) Matteo: since you have so much SIDs, it's worth a try to connect the audio input of your stereo directly to the audio out of the SID chip. Although this can be dangerous (on the other hand: it never caused problems with my SIDs), it gives you the important input if the transistor stage is really the problem, or if it is located anywhere else.. Best Regards, Thorsten.

Hi Kostix, a simple solution (which I've used in MIOS) is to define a so called "deadband" in within a value change won't trigger a new (MIDI) event. Here the pseudo code (not tested, since the original one is written in assembler) if( abs(new_value-value) > deadband) { value = new_value; notify_value_change(); } (abs() returns the unsigned absolute value) of course, the penalty of this solution is a redocued effective resolution - on the other hand it doesn't produce additional delays and is very memory friendly (you only need to store the last sent value once...). A deadband of 1..3 is mostly sufficient, even when multiplexers are used on the analog inputs Best Regards, Thorsten.

Yes, good news! :) But please note that the USB peripheral allocates 3 pins. This means that not every MIOS application will be compatible, some can be adapted very easy. Maybe it makes sense to provide a special core module for this option, which can either be used as common USB->MIDI interface, or as a regular core module + USB extension for applications which don't rely on too much IO pins. Best Regards, Thorsten.

Hi Reiner, I remember that an early release of MIDIO128 had this problem, it should be fixed with v2.1 - if not, then please send me your .ini file Best Regards, Thorsten.

the new section is now available: MIDIbox Documentation Project Best Regards, Thorsten.

Thats a difficult topic, since sometimes (not always) people tend to ask for special support once they made a donation, or they are very unhappy when I don't pay enough attention for their personal wishes although they gave me some money. Therefore I don't promote acitivties into this direction. On the other hand: if somebody wants to make a more or less anonymous donation to my PayPal account, I don't prevent him from doing this - this could lead to a bigger frontpanel in the next design, or to new supported device/module which I normaly wouldn't use by myself, just to have some fun on the driver implemention. (Example: alternative, cheaper DACs for the AOUT module, Motorpots, special graphical LCDs, etc...) Moebius alludes to an important point: I'm very happy with the situation that in the meantime most people get superb help from you guys without any effort from my site. Since some weeks I'm able to totally focus on MIDIbox FM when I find the time without beeing distracted from permanent help requests for which nobody takes care about. Under these conditions you can be sure that I will continue with releasing new projects to the public :) Best Regards, Thorsten.

Hi Marcel, the required software changes are not so easy compared to the small hardware changes you have to make: just cut the tracks to the buttons/encoders which are affected and re-wire the DIN inputs with small cables. This will possibly cost you one hour of work on the ready-made PCB, but this is much less time than writing down an article about the required changes especially for your problem. Best Regards, Thorsten.

Hi Thomas, this is not a bug, but a feature. The SID volume is a 4-bit value. This means that you won't hear any change when selecting a volume between 0 and 7, 8 and 15, etc... the same is true for the other 4-bit parameters like attack/decay/sustain/release... it's a limitation by the SID so, why shouldn't the CS just display the value which is really used? The 4-bit values are patted to allow the proper use with poor MIDI controllers which don't support min/max values (like NOT the MIDIbox controllers ;-)) and with poor sequencers which always display the 7-bit range in the automation The value is not reduced to 4-bit resolution when editing the parameter directly on the control surface. This was to have the same "feeling" when tweaking different values with different resolutions. If you don't like this, then you are allowed to change the source code, but you will propably switch to the original version as soon as you regognize what I mean ;-) Best Regards, Thorsten.

Hi Matteo, this doesn't match with the programming concept, a lot of changes would be required in order to chain the steps without changing the pattern, and some features would not be possible with the current performance anymore (e.g. accurate song position pointer/rewind/forward). I'm also not sure if the song mode would work in this form anymore. Chaining tracks was possible with MIDIbox V1, but I removed this not without special reasons... Best Regards, Thorsten.

Hi Matteo, no, the AOUT implementation is not final, and it still works like described in the changelog - an even more powerfull implementation is planned for next year, but this should not say, that the current version doesn't make a lot of fun :) Best Regards, Thorsten.

Hi Stefan, there is a very simple way to display a message - just use the "print message on LCD" SysEx command of MIOS (http://www.ucapps.de/mios/mios_sysex_implementation.txt) It's an internal MIOS feature which works also in a running application. If you want to prevent that the message vanishes after 2 seconds, you have to modifiy the USER_DISPLAY_Init hook (e.g. the small skeleton: add a "return" below USER_DISPLAY_Init") Example for a message (use MIDI-Ox to send this command) F0 00 00 7E 40 00 08 01 00 00 4d 79 20 66 69 72 73 74 20 4d 65 73 73 61 67 65 21 20 3a 2d 29 f7 Best Regards, Thorsten.

Hallo Stefan, ich vermute, dass es sich hierbei um einen Programmierfehler von meiner Seite handelt -- meine MB16E hat ausser den LED-kraenzen keine zusaetzlichen LEDs, deshalb habe ich dieses Feature nie ausprobiert. Mit der naechsten Version sollte es funktionieren. Gruss, Thorsten.