TK.

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.

Thanks for the offer, but I considered to use my BLM16x16+X for testing instead, just only have to solder the adapter ;) Debugging with a CRO is problematic if you want to check multiple LED functions at once (e.g. to ensure that they don't influence each other). However, I think (hope) that I found the issue - could you please try the latest version? Best Regards, Thorsten.

I already spent some thoughts on this, but it still needs some conceptional work. E.g. there must be a way to terminate the loop from external (at least from the MIOS terminal) in case of a programming error (endless loop), otherwise the danger is too high that it won't be possible to update the .NGR file via MIOS Filebrowser without unwanted side effects (e.g. application crash). This is especially required for the case that the loop already starts in the DEFAULT.NGR file... etc... Another potential issue is, that somebody could think, that a time consuming loop would run without side effects. But currently we would have such effects, e.g. LCD output triggered by events won't be handled as long as the .NGR script is executed. Allowing more "multitasking" will require a lot of extensions, which I actually wanted to omit. And btw.: I'm also pretty sure that the next request will be to allow some "simple" calculations, and variables, etc... things which will cause more effort at my side than initially planned. Best Regards, Thorsten.

P.S.: I updated the code, so that for the case that (hw_id)LED:1001 hasn't been configured as EVENT, the value 127 will be set automatically. Background: "virtual events" can't store the value. Please update your repository. Best Regards, Thorsten.

Well, the hope was that you could test this without forcing me to build up the HW for tries at my side ;) However, could it be that the LED value is 0, so that the LED isn't turned on? Please try: set (id)LED:1001 127 set_rgb (id)LED:1001 15:0:0 delay_ms 1000 set_rgb (id)LED:1001 0:0:0 delay_ms 1000 set_rgb (id)LED:1001 15:0:0 If this doesn't help, please enable debug mode ("set debug on" in MIOS Terminal) - maybe it prints out some useful informations. If this still doesn't help, start to instrument the code with DEBUG_MSG to follow the data stream. Best Regards, Thorsten.

Check your ensemble configuration (especially the INS page), maybe you've reduced the keyboard zone? Best Regards, Thorsten.

You've to #include <seq_ui.h> to get the declarations. The change could lead to issues with Note On/Off if you hold a note and change the track. However, the "Live Play" function is doing exactly the same - and it remembers the open Note On commands to avoid hanging notes. It can even apply effects! :smile: Just select Utility->Live (GP#11) to configure this function. So, actually there is no need for such a (redundant) enhancement. Best Regards, Thorsten.

Better to get USB working again before changing any router settings... The GM5 driver could be the problem, did you already try to de-install it? If not: just open the setup program and select the deinstall option... With the single_usb option it shouldn't be relevant anyhow. And it would be interesting of SD Card accesses via MIOS Filebrowser are working thereafter. Best Regards, Thorsten.

I implemented the discussed enhancements, they are available in the repository. Could you please test them at your side? Details can be found in the ChangeLog: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2FCHANGELOG.txt Best Regards, Thorsten.

yes thanks for the food for thoughts - RGB handling will require a special "set" (e.g. "set_rgb") command. I can't promise that this will already work with the next version, because such a command will require some testing with special hardware... Best Regards, Thorsten.

Yes Best Regards, Thorsten.

In the next version I will add the possibility to access all channels from a single track via dedicated CCs Best Regards, Thorsten.

"set" searches for an EVENT with the given id - instead of fwd_id it won't address the hardware directly if the id hasn't been specified. Note also, that it searches for id, not for hw_id (which can be different). In the next version I will change this: set will work like fwd_id, and if the "id" instead of "hw_id" should be addressed, somebody can write "(id)<controller>:<number>" Best Regards, Thorsten.

@Ilmenator: this is unrelated to MIOS Studio and has to be fixed in the MIDIbox NG application (output string too long) /update: fixed this, the error shouldn't appear in the next MBNG release! @rvlt: as mentioned at the MIOS Studio page, the app is built for 10.7 and 10.8 (not for 10.6) However, meanwhile I was able to install an older Xcode version, which allows to build for 10.5 upwards Could you please try the new build? (same link, the old app has been replaced) Best Regards, Thorsten.

This statement isn't up-to-date. I changed it to: OUT1..OUT4: STM32: 3 physical MIDI OUT ports are provided by the MBHP_CORE_STM32 module. The remaining one is reserved for the emulated MBSEQ. LPC17: all 4 physical MIDI OUT ports are accessible via OUT1..OUT4 It won't be possible to integrate the SCS (or any "memory intensive" app) into MBSEQ V4 due to RAM limitations. Actually the RAM is almost completely allocated Try to compile it, come back if you see compile errors which you can't solve by yourself ;-) Best Regards, Thorsten.

J16 is used by the application to access the SD Card -> no way! J19 would be used by the application if the .NGC file enables the AINSER or CV port -> potential conflicts as well. Therefore I would propose to use J5C instead. In many applications (e.g. MBSEQ V4) J28 of the LPC17 core is used as a replacement for J5C of the STM32 core anyhow, so why not using it for your special case as well? Best Regards, Thorsten.

Please always consider that I wrote for your case in the past - your PC doesn't work reliable. "show" doesn't display the actual file, but generates a file from the content in RAM and redirects the output to the terminal. If you've luck, SD Card transfers will work more stable with MIOS Studio 2.4.4 If the latest changes still don't help, there is no hope for your PC setup - I'm sorry for this, but as mentioned above, I'm not a Windows expert... Best Regards, Thorsten.

What??? %-) However, it's finally possible to browse through the command list with MIOS Studio 2.4.4 Best Regards, Thorsten.

Topic closed - MIOS Studio 2.4.4 has been released.

MIOS Studio 2.4.4 is available now Changes: switched to most recent Juce release v2.0.38 in the hope that it fixes some MIDI issues reported in the past from users with "exotic" OS installations MIOS Terminal: you can now browse through the command history with the up/down cursor keys Best Regards, Thorsten.

Thanks for the compliments! :) Best Regards, Thorsten.

I knew that I forgot something... ;-) Please try the new release: MIDIbox NG V1.023 ~~~~~~~~~~~~~~~~~ o the current AIN/AINSER pot values can now be taken over by the meta events RetrieveAinValues and RetrieveAinserValues o new .NGR command: EXEC_META Write following commands into your .NGR file: if ^section == 0 exec_meta RetrieveAinserValues exec_meta DumpSnapshot endif Best Regards, Thorsten.

These LEDs are directly assigned to the first SR in cs_menu_matrix.inc The direct SR assignment (for all 8 pins) saves execution time and flash memory. As you already noticed, flash is very reduced for PIC18F452... and performance is an important topic as well. Best Regards, Thorsten.

I agree with Nils - this was initially code from the PIC (without HW support for modulo). I should optimize this for "modern CPUs" based on Nils' proposal before somebody else copies it for his projects ;-) Best Regards, Thorsten.

Not yet... as mentioned above, it will need some time. I've to open my MB64 case, replace the MBHP_CORE_LPC17 module by a MBHP_CORE, have to find out what I did years ago and then try out changes (which are error prone...) in order to help you on this topic. Best Regards, Thorsten.