TK.

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:

The new beta version is available now, it does not only contain bugfixes, but also new features: an update to MIOS V1.9 is required, since memory above 0x7c00 is allocated! This beta will crash with older MIOS versions! LFO sync bug fixed Modwheel/Aftertouch/Velocity/WT problem: I remembered, that this is a general problem with the data structures which I've used in the firmware. Recursive forwarding (e.g. WT -> Modwheel -> CC parameter) doesn't work properly in all cases, and if CC assignments are changed during notes are played (via MIDI or from the WT sequencer), the content of some internal registers could be destroyed, so that the patch needs to be reloaded. I added a simple workaround (WT sequencer is stopped on CC assigment changes - this works only for the master!), but a full fix will only be available in MBSID V2, where the data structures will be organized in a better way back to new features: there is now an SEO menu page to change the "sound engine options": 303 (303 mode), FIP (Filter interpolation) and E2P (linear portamento realized with the help of ENV2) the internal WT editor now allows to modify the parameters of a whole track at once, this speeds up the initialisation of a new WT sequence. Just select the position beyond 31 ("All" will be print) and modify the Mod, #1, #2 or #3 column the WT editor now marks parameters with a '!' so long they haven't been stored in EEPROM Direct Link: -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta15.zip Best Regards, Thorsten.

Sorry, this was a writing error - I meant "heat" and not "head". Hope that this makes clear, why -5V/+12V is the better solution! I don't have -12V available, only -15V/+15V from the Behringer PSU, and -5V/+5V/+12V from my own regulators... Best Regards, Thorsten.

:) Best Regards, Thorsten.

Hi Alex, the CEM3378 datasheet says, that +12V/-5V is for best performance. +12V/-12V would produce more heat, whereas +5V/-5V doesn't allow to reach the maximum cutoff frequency. For the AOUT_LC module any voltage can be used within the supported range of the TL072, it's very flexible! I don't think that you need to take care about such special cases. If somebody needs -5V instead of -12V, he can just replace the 7912 by a 7905, or he has to adapt his circuit... Best Regards, Thorsten.

Hi Ilmenator, yes, this makes sense. It seems, that the datasheet is totally wrong, because your observations indicate, that the CE input is low active. I think that RD/WR are low activate as well - and the reset, too! So: use the original driver, clamp CE to ground and RESET to +5V. I think that this will work You don't need to upload MIOS again if the core "hangs up", normaly this happens if the driver runs in an endless loop (e.g. due to a missing timeout). In this case, just upload a modified application via 1st level bootloader Best Regards, Thorsten.

Yes, the SSM2044 should do the same, a sound comparison could be interesting. It is for the CEM filters, and as the negative voltage is available, I'm also using it for the AOUT_LC module. The CV inputs (of the *external* CEM3378 circuitry -> see datasheet) are working in a range of ca. 1V-7V (CutOff) and 0V-3V (Resonance). In addition to the gain/offset trimmpots of the AOUT_LC module, I'm using 10k trimmpots against ground at the filter CV input side - all 4 AOUT_LC modules deliver the same voltages when the CVs are swept from min to max, and with the additional 10k pots I'm able to fine-adjust the desired maximum resonance and I equalize the CutOff frequencies of all filters on an easier way, than with the non-linear gain/offset pots Best Regards, Thorsten.

Yes, these are the strings and the icons which are printed out. There could be another interesting check before you unsolder this display: according to the T6963C datasheet (I just had a look), the CE (chip enable) line is low active. But in the Wintek specs it's listed as high-active signal. However, I assume that this is an error, and that all three - RD, WR and CE - are low-active signals. This means: CE_N must be connected to ground in order to activate the bus. And you have to use the unmodified driver (no bsf/bcf change) This could also explain, why there isn't a change regardless of the RD/WR polarity. Best Regards, Thorsten.

First I tried to order at robotikhardware.de - I created an account, filled all informations into the form, and finally - after 5 minutes of typing work - got a notification, that the chip is currently not available :-/ Best Regards, Thorsten.

Since months I was thinking about a nice housing for my 4 CEM3378 filters and AOUT_LC modules. Finally I got the idea, that nothing would be easier than just to integrate the modules directly into a mixer. So, I opened my "Eurorack" linemixer from Behringer and was very happy to find enough room for all the boards: As a nice side effect, the PSU is already there. It delivers +/- 15V. I'm using a 7905, 7805 and 7812 to regulate the voltages. The AOUT_LC module is supplied with +12V/-5V (+12V to get enough headroom for the filter CV). Two modules are stocked for best utilisation of the available space in the mixer case: And here the first audible results I got out of a MIDIbox FM / 4*CEM3378 combination: http://www.midibox.org/midibox_fm/PimpMyBehringer.mp3 I especially like the bubbling sounds when the filters are in high resonance, and controlled by the LFOs and EG5 :) Best Regards, Thorsten.

Hi Ilmenator, are there any new findings in the meantime? There is a simple way to debug the driver: just use MIDI events as "log mechanism". When you add following code to USER_LCD_PrintChar: USER_LCD_PrintChar movwf TABLAT ; save character movlw 0xc0 call MIOS_MIDI_TxBufferPut movf TABLAT, W andlw 0x7f call MIOS_MIDI_TxBufferPut movf TABLAT, W ;; ... [/code] each character will send out a program change Best Regards, Thorsten.

Hi Leo, did you select the HS oscillator type? Best Regards, Thorsten.

Just got my SpeakJet today - I ordered it at http://www.sander-electronic.de/be00064.html. The webshop doesn't work, but I wrote an email and received the chip within 3 days :) Best Regards, Thorsten.

I don't want to exclude the possibility, that it is a similar problem at my side. Even though both displays are working fine, sometimes strange things can happen. However, it's a little bit difficult to get the box opened (because there are some other MIDIboxes at the top :)), but I will check this sooner or later. Both displays are passive (data lines in high impedance mode) when the enable lines are 0, and this is definitely the case. There might be a difference because of higher capacitances, but I've already excluded timing issues by inserting NOPs (see above). However, thats all I can say to this, I cannot say when I will continue. Maybe somebody else with a MBSEQ could doublecheck the results? Best Regards, Thorsten.

The update procedure was complete, and if the display shows the same behaviour, it is propably related to the driver. I just have uploaded the new driver versions - app_lcd.inc is still the same, the framework is based on the v1_9 skeleton. All drivers (beside of the IIC driver) have been tested with my own displays, so please use the most recent "lcd7_*_v1_9" versions -> mios_download page (maybe it's required to refresh the page) Yes, app_lcd.inc is the right location, the driver is located there. There is a timeout loop, which you could disable (just remove the "bz USER_LCD_WaitUnbusy_Disable" branch) - if MIOS hangs up thereafter, you know that the issue is related to the busy state Yes, you are right - different polarities have to be considered. I just had a look again into the datasheet of your GLCD, it lists "RD" and "WR", but no hint about low active signals, they could be high active! Solution (try this before removing the timeout mechanism): search for "GLCD_RD_N" and "GLCD_WR_N". Each time a "bcf" is used, turn it to "bsf". And change each "bsf" to "bcf" This could help! :) Best Regards, Thorsten.

Hi Ilmenator, this bar/stripe pattern sounds like the access to the display is partly working, but the RAM hasn't been initialized, and font's are not displayed. Something like this can happen on a timeout (see app_lcd.inc, search for TIMEOUT). Either your display is slower than the one I've tested so far, or two data lines are swapped, so that commands are not forwarded properly. But I just have noticed another thing: I just have hooked my own T6963C display (donation from d2k) on a MIOS V1.9 core and noticed, that the font is scrambled. This is realted to a the "font location change" (font is now located at the end of flash memory). This means, that all LCD drivers need to be recompiled with the new mios.h file This file can be found in the migration/ directory of the MIOS v1.9 source package And there is another point for which you have to take care about when using a graphical display: the update_with_old_mios.hex and update_without_installed_mios.hex file don't contain the font, it's only part of the mios_v1_9_pic*.hex file. For the case that this is too confusing, here some step-by-step instructions: - upload mios_v1_9_pic18f452.inc in order to ensure, that the font is available - copy migration/mios of the source code package into the directory of the LCD driver - rebuild the application and upload it to the core Maybe this already helps before fixing the timeout mechanism. I will wait for an driver update until I know, that your GLCD is working Best Regards, Thorsten.

Hi Martin, from the MIOS application side this shouldn't be a big problem, because the transmission of a single MIDI event takes 960 uS, and the app. will propably process this within 50 or 100 uS. Even if your host program gets use of the "running status" feature (in this case only two bytes need to be sent for a 3byte MIDI event), it should be ok. I think that not MIDI itself is the problem, but the protocol you are using. You could control the lamps with a significantly higher framerate by using SysEx streams. Instead of sending one 3-byte event for each CV out, you could send 2 + 64 bytes instead (F0 <64 bytes> F7) The resulting frame rate would be 1 / (320 uS * 66) = 47 frames per second With the C application I sent you this can be realized without much effort, I guess that I also gave you this hint some time ago Best Regards, Thorsten.

Hi Thomas, I just have tested it on my MBSID/MBFM (one display) and MBSEQ (two displays) It works fine on MBSID and MBFM, but I would like to see a "pass message" to know, that the test has been executed. I've modified the code in the following way: void Init(void) __wparam { char error = 0; TRISB = 0x00; // enable drivers of port B // for more details about the available SFRs, just have a look into // the PIC18F452 datasheet, which is available at the Microchip // homepage: http://www.microchip.com for (i = 0; i < 8; i++) { error |= TestPins(0xb, i); } if( !error ) { MIOS_MIDI_TxBufferPut(0xf0); MIOS_MIDI_TxBufferPut(0x1a); MIOS_MIDI_TxBufferPut(0xf7); } } [/code] and I've modified TestPins(), so that it returns a value != 0 if a mismatch has been detected. On my MBSEQ I noticed a strange effect, for which I currently have no explanation: F0 00 00 0B 0E 0F 0E 00 F7 (RB0-RB4 are zero, although only RB4 should be 0, and the rest 1) I would have to open the case in order to do further analysis. I've already added some delays between the PORTB value assignment and the PORTB != TRISB check, I've also assigned the pattern "LATB = ~(1 << pin)" instead, but the result is the same... hm... Best Regards, Thorsten.

Evtl. funktioniert es auch mit einer Aenderung in mb64_button.inc. Dort gibt es bspw. die Funktion "MB64_BUTTON_Toggle", welche (wenn sich der Taster im Toggle Modus befindet) eine LED beim ersten druecken ein- und beim naechsten druecken ausschaltet. Hier koennte man abhaengig von der Button Nummer auch verschiedene Flags des MB64_BUTTON_VALUES_SR0 arrays gleichzeitig setzen/loeschen Falls Dir die Assemblerprogrammierung zu kompliziert wird (ich gebe zu, an diesen Stellen habe ich zuviel optimiert ;-), koenntest Du die Steuerungslogik immer noch mit C realisieren, muesstest dabei jedoch auf die speziellen Features der MB64 Applikation verzichten, denn die vertraegt sich nicht mit C Gruss, Thorsten.