TK.

The "emu_enc_mode" is available in v1.024 See also this configuration example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Femu_enc.ngc And this page for available modes: http://www.ucapps.de/midibox_ng_manual_ngc.html Best Regards, Thorsten.

A new version is available: MIDIbox NG V1.024 ~~~~~~~~~~~~~~~~~ o bugfix for "single_usb" option o support for LED Digits (7-segment displays). Configuration examples can be found under cfg/tests/leddig*.ngc o the DIN_MATRIX and DOUT_MATRIX configuration command now allows to mirror the row pattern with "mirrored_row=1" o added EVENT_RECEIVER emu_enc_mode and emu_enc_hw_id parameters. See cfg/tests/emu_enc.ngc for an usage example o .NGR now allows to cast the ID type: (id) or (hw_id). E.g. (id)LED:1 will search for the EVENT specified with id=1, and (hw_id)LED:1 will search for the EVENT specified with hw_id=1 if (hw_id) is used (default if no type specified), and no EVENT with a matching hw_id can be found, a virtual event will access the control element directly. This is currently only relevant for the SET command. This matches with the behaviour of the "EVENT ... fwd_id=<id>" function. o added RunStop meta event to stop the execution of a .NGR file o added "runstop" terminal command o new .NGR command: set_rgb <id> <r:g:b> E.g. "set_rgb (id)LED:1001 15:8:4" Some user manual pages have been updated as well Best Regards, Thorsten.

The "single_usb" option now also works properly under WinXP - thanks to Johnc and Pete for testing! MIDIO128 V3.016 ~~~~~~~~~~~~~~~ o bugfix for "single_usb" option Best Regards, Thorsten.

Ok, for the case that it's really useful for other people, the enhancement is now part of the official release. MIDIboxSEQ V4.073 ~~~~~~~~~~~~~~~~~ o bugfix for "single_usb" option o the MIDI router provides the new destination "Sel.Trk" Usecase: MIDI events, such as CC or Notes, should be sent from a master keyboard or MIDI controller to the MIDI port and channel of the currently selected track. Best Regards, Thorsten.

enc_speed_mode (especially Slow:<divider>) is intended to solve your request. It enables a pre-divider, so that no special calculations are required. Yes, a map would work as well, but the usage is more cumbersome. Best Regards, Thorsten.

Hurray! :) Best Regards, Thorsten.

Good progress! :) Maybe the MIOS32 based SD Card driver gives you some helpful inspirations: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_sdcard.c Note especially the difference for HCSD devices. Yes, Timer2 isn't used by MIOS8. I've only an example based on assembly code: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fmbsid_testtone%2Fmain.asm For 500 kHz following configuration should work: movlw 0x04 movwf PR2 movlw 0x24 movwf T2CON movlw 0x0f movwf CCP1CON movlw 0x02 movwf CCPR1L Best Regards, Thorsten.

Thanks a lot for testing it! :smile: WinXP doesn't allow to change the name of the "audio device" - unfortunately... Best Regards, Thorsten.

I think (hope) that I found the issue - faster than expected. Please try following version: http://www.ucapps.de/mios32/midio128_v3_016.zip Installation via USB: close MIOS Studio mount the "BSL Hold" jumper J27 power-cycle the core USB connection should work open MIOS Studio install midio128_v3_016 close MIOS Studio remove the "BSL Hold" jumper J27 power-cycle the core MIDIO128 will be started and USB connection should work again under WinXP Best Regards, Thorsten.

-> should also work for AOUT_LC, search in the sources for more infos Best Regards, Thorsten.

I will try to reproduce this issue. This will probably result into some hours work at my side, but I hope that this will give me some more insight into the WinXP behaviour. To JohnCs questions in another thread () > Where to find a copies of past midio128 ver 3 releases. Was using rel .005 beforeneed the latest release that will work with the XP USB composite driver. Backups are available, but I won't give you the links, because trying to go back to older versions can result into compatibility issues due to dependencies with bootloader and MIOS Studio. I fear that you won't be able to debug this at your side. Please wait until I've finished the analysis. > Need a reliable version of mios studio (I have given up on the file Browser feature of ver.2.4.4). Probably we will never get a reliable version under WinXP Best Regards, Thorsten.

Please don't spread different postings, which are related to the same "story", over multiple threads, this doesn't really help to follow the topic in future, and other people (who might have the same problems) will even more confused about the incomplete informations than you ;-) This "story" continues here:

thanks - fixed Best Regards, Thorsten.

Hi Pavel, yes: the PIC is supplied at 5V, the LPC1769 at 3.3V. This means that the s/n ratio is lower, which results into sporadical jittering values even at (only) 7bit resolution. With a MCP3208 conversions can be done at up to 10bit without jitter (12bit conversion jitter +/- 2 LSB when supplied from USB) However, since you create your own PCB, you could maybe improve results by considering the ADC design guidelines: AN10974_-_LPC176x_175x_12-bit_ADC_design_guidelines This page describes, how to configure the SED1520 display: http://www.ucapps.de/midibox_ng_manual_lcd.html This page describes, how to output special fonts (inclusive bars, knobs) on a GLCD: http://www.ucapps.de/midibox_ng_manual_ngc.html If you are not happy with the available fonts, then you would have to create your own one(s) here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fglcd_font%2F And you would have to integrate it into the project here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fsrc%2Fmbng_lcd.c Or you just wait, until we've integrated John's new fonts into the official build: Best Regards, Thorsten.

the usage of the embedded ADCs isn't recommended, because conversion values are jittering to much. I will release the AINSER8 module soon: http://www.ucapps.de/mbhp/mbhp_ainser8.pdf which would perfectly fit for your usecase. Just yesterday I got the mail that the prototype PCBs are shipped. :smile: Where are you located? If in Europe, I could give you one of the three prototype boards. If outside europe, it makes sense if you would order the PCB directly at http://www.oshpark.com (once I've released the .brd file) Best Regards, Thorsten.

The linked article describes an expired approach anyhow, no need to scan a keyboard this way with modern hardware... This isn't so difficult, because all code modules have an own namespace, so that they can be combined without conflicts. I would propose to read through the tutorials to get a basic understanding, how the framework is organized -> http://www.ucapps.de/mios32_c.html It's important to read it from the beginning, otherwise you could miss important informations which are helpful to work with the more advanced examples. Once the framework is understood, you should also be able to do modifications in an existing application, or to build up a new one from scratch. Best Regards, Thorsten.

The wrong warning message is fixed, and the "delay_ms" command has been improved, so that it doesn't stall SD Card accesses anymore. This means, that you can now use the filebrowser without conflicts while the .NGR script is executed. The new "RunStop" meta event has been added, which allows to stop the execution of a script with a control element (e.g. button) And a "runstop" terminal command is available as well - just for the case... Best Regards, Thorsten.

No, I don't know such a method. Best Regards, Thorsten.

This isn't enough input for remote diagnosis! ;) So, it seems to be related to colors controlled from bank1 - what happens if you remove all other events located in this bank, maybe there is some kind of overlaying in your configuration? It could also make sense to start the analysis with a minimal setup - or the other way around: downstrip the .NGC file until you notice a difference. Best Regards, Thorsten.

This is not a toggle mode button, you would have to specify button_mode=Toggle instead. Then you can write (I haven't tried it out, but I hope that you get the idea how it could work): if ^section == 0 exit endif if ^section == 1 log "Section 1 called" # do this # and that # maybe with some delays: delay_ms 1000 # and finally: if BUTTON:1 != 0 log "Retriggering section 1" exec_meta RunSection:1 else log "Finished." endif exit endif Hope that it works (last mail today... ;-)) Best Regards, Thorsten.

yes, you can already do this yes, this is already possible: exec_meta RunSection:<section> exit As you can see, you are even able to start the .NCR script with different ^section values to execute different branches. Btw.: meanwhile I got an idea how to deal with delays and SD Card access (just close the file, release the mutex, wait for x mS, take back the mutex, re-open the file). In addition, a new Meta event makes sense which allows to terminate the execution (resp. clear an open request). I will try this tomorrow. But my statement is still true, that I don't plan to add language extensions to control the program flow. Best Regards, Thorsten.

it should be cloned. If this doesn't work yet (because it seems that you have multiple issues), then remove the problematic PIC and continue debugging the MIDI IN. Resp. it could make sense that you are trying only with the master core to get a less complex system. shouldn't make a difference. Btw.: could it be, that you wrote about the same topic some months ago? (I remember a similar story) Best Regards, Thorsten.

Why did you reinstall the driver? Ah... I see, because I wrote the wrong term "de-install" (more german than english ;-) - I meant uninstall (which probably requires a reboot) In other words: Please try the "single_usb" option without the GM5 driver. Best Regards, Thorsten.

I don't see a blocking point for such an application, the LPC17 has more than enough power to handle this! :) You could take the MIDIbox CV V2 as a code basis, because it already contains many functions that you intended to program: Sources: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2F ...just combine it with the keyboard driver: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fkeyboard%2F Why do you want to scan the keyboard with such an exotic matrix configuration? Here you can find typical circuits: http://www.ucapps.de/midibox_kb.html they are all supported by the keyboard driver Best Regards, Thorsten.