TK.

Hi Rowan, no, with "LCD_EMU_COL 40" the text output will be cutted after the 40th character. LC doesn't send individual messages for each fader/vknob combination, there is only one message type and one 2x55 screen. Some people (e.g. Axel) customized the display output routine by removing some of the characters within the 2x55 range, so that they are able to use smaller displays. You could ask them for the code... Best Regards, Thorsten.

Hi Rowan, the logic/mackie control protocol supports 2*55 maximum, therefore the screen layouts (-> lc_clcd.inc) are only prepared for this max. number of characters per line. You will notice that the left and right side of the display is filled with some additional informations (e.g. button status of mute/solo/rec, time code, etc...) by MIDIbox LC, so that the whole screen (2 * 2x40) is utilitzed. Best Regards, Thorsten.

Yes, but in reallity you won't regognize such an effect. E.g., the AIN driver still samples the analog inputs in background (interrupt driven), so changes won't get lost. This system behaviour ensures not only the LCD coherency, but it also solves some other issues (e.g. it prevents MIDI protocol violations if an incoming stream is merged with the outgoing stream) Best Regards, Thorsten.

Of course, #2 could be made quickly, but over the years I've learned not to do such quick changes on request anymore, since this mostly means that people start to request even more - with the effect that I'm not able to finish my own plans. I also don't want to change the user interface in a way which is obsolete once the song part functiuon is available... mostly such "redundant" features will lead to a really unwanted complexity. In worst case it could lead to the situation where much more useful functions are not integratable anymore since the code for the redudnant functions fills the memory A general note.: users are always allowed to integrate these functions by themself. But without my support, and propably without the chance to bring the additions into the official release (this is only possible once the project is completely finished from my side...). This is not because of ignorancy to other programmers, but just required to reduce the effort from my side. Best Regards, Thorsten.

Hi Nico, thanks for the compliments! :) First of all I must say that I'm aware of this "problem", but currently I'm totally focused on MIDIbox FM, therefore I fear that I won't find the time to add some new features to MIDIbox SEQ in this year. I've already defined a solution which improves the live handling of multiple patterns which belong together. See also the wish list under http://www.ucapps.de/midibox_seq.html: Especially the "song part" feature will allow you to define up to 16 sets of patterns within one song. You will be able to switch between the parts from the general purpose buttons, or with a keyboard. You will also be able to edit track 5-16 in realtime. Hope this makes sense :) Best Regards, Thorsten. P.S.: no, it is not possible to save the track mute status. Maybe this could be added to song mode in combination with the parts

Hi Skynth, yes, you can do this on a similar way like for the double note events. Just take a look into mb64_meta.inc Best Regards, Thorsten.

They are generated with selfmade perl scripts: http://www.ucapps.de/midibox64_tutor/gen_mb64_screens http://www.ucapps.de/midibox64e_tutor/gen_mb64e_screens http://www.ucapps.de/midibox_cv/gen_mbcv_screens http://www.ucapps.de/midibox_seq/gen_mbseq_screens http://www.ucapps.de/midibox_seq/tutorial1/gen_tut1_screens http://www.ucapps.de/midibox_sid_cs/gen_mbsid_screens Best Regards, Thorsten.

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.