TK.

Yes, the range is part of the .NGC configuration and not of the snapshot. Best Regards, Thorsten.

Should work as well Best Regards, Thorsten.

Yes, this could be the problem. You could solder a 5.6k (or 4.7k) resistor in parallel to the 82k - the resulting resistance is still in an acceptable range. Best Regards, Thorsten.

@Borfo: could you please integrate the changes into the new "*humanize2*" files by yourself and give me the changed code? I just want to ensure that I don't miss anything again, and that we are working with the same sources. Best Regards, Thorsten.

Just enable Boot Hold mode and upload the fixed application under save conditions with MIOS Studio (under Linux or whatever OS you like) See also in this picture. However, the Primer contains an integrated debug interface which makes it easy to recover the MIOS32 installation w/o this measure. MBHP_CORE_LPC17: stuff jumper J27 (BL Hold) to select the bootloader hold mode, thereafter power-cycle the core. MBHP_CORE_STM32F4 and STM32F4DISCOVERY: press and hold the blue "User" button, trigger the black "Reset" button shortly. This will restart the core and enforce bootloader mode as long as the blue "User" button is pressed. Best Regards, Thorsten.

Please check by yourself if the code is matching with yours ;-) (I'm off now) Best Regards, Thorsten.

Ok, taken over. The UI handling is not really intuitive, the second parameter layer activated with the SELECT button is some kind of hidden function, there is no display change if SELECT is pressed - so without knowing this, somebody could think that the Fx is not working. I also did a minor optimisation in seq_humanize2.ct: check for the humnote/humoct/humvel/humlen first before fetching a random number, this saves some cycles if the function is not activated. Best Regards, Thorsten.

I used the wrong .c file - will fix this now Best Regards, Thorsten.

I remember that Poly mode isn't implemented yet. To the remaining observations: are you using Lemur on an iPad or Android device? Best Regards, Thorsten.

Should be possible without too much effort. I added this to the wish list Best Regards, Thorsten.

Yes, it supports Bank Select LSB and MSB Bank Select LSB is CC#32 Bank Select MSB is CC#0 Best Regards, Thorsten.

Yes, MBSEQ V4 and MBCV V2 are running on MBHP_CORE_LPC17 as well. Best Regards, Thorsten.

This motivated me to integrate your current code into the firmware in the way that it doesn't affect the legacy humanize function, and everybody will be able to try it out (with the known store/restore limitations). It's in seq_ui_fx_humanize2.c and seq_humanize2.c now All new CCs got the "humanize2" prefix and are above 127 Please take over the changes to simplify sharing :smile: It seems that the UI doesn't give access to all parameters yet, right? Note that I simplified the parameter modification handling (and I did the same improvements in seq_ui_humanize.c): the button handler calls the encoder handling with incrementer=0, so that the same code can be used for both control elements. Btw.: is this still a "humanizer"? Or a randomizer, or robotizer, or noodleizer? ;-) Best Regards, Thorsten.

Yes

Could you please check if following lemur patches are working: - the BLM16x16+X emulation: http://www.ucapps.de/midibox_seq_manual_blm.html - the MIDIbox CV V2 controller: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2Flemur%2F Best Regards, Thorsten.

Fine! :smile: *gp_leds is just a binary coded pattern which will be copied into the 16 DOUT SRs of the GP LEDs. The rightmost LED (GP #1) is bit #0, hence at the right side. E.g. 0x0001 -> GP #1 will be set 0x0002 -> GP #2 will be set 0x0003 -> GP #1 and #2 will be set The transpose values are a good example: u8 transpose_semi:4; // semitons transpose u8 transpose_oct:4; // octave transpose CC numbers above 127 won't be stored in the pattern bank on SD Card. There is currently no simple way to overcome this limitation. My plan is to write a conversion function which migrates the banks for V4 Plus, but as mentioned above, it's not the right time to start with this. So, just continue with the quick&dirty way Thanks! When I look into seq_ui_humanize today, I would change two or three minor details to make it easier customizable (already did this for some other pages). There is also an error in my code: #define NUM_OF_ITEMS should be 5, not 7, otherwise the cursor inc/dec function isn't working correctly. I will change this before the next release (but I won't take over your changes yet - too early... ;-) Best Regards, Thorsten.

LED control is not difficult, just cumbersome, because you've to write many if/else conditions ;-) But I would propose that you go ahead with the cumbersome solution first, and once you are happy with the handling, we can discuss if an optimization makes sense. Best Regards, Thorsten.

No, there is no other struct, because from my experience sooner or later a user will ask for (external) CC control and then we will be in big trouble if the CC format (128 parameters maximum) hasn't been considered ;-) RAM limitations (especially LPC17) are also a reason why I haven't started with alternative structures yet. However, I consider to start with an alternative struct for MIDIbox V4 Plus, which will only run on a STM32F4 (less RAM limitations, more freedom for extensions). It could be made accessible via special NRPN channels and loopback ports (for those who want to automate changes). But I'm still not ready to start with this step. However, for your first experiments, just use quick&dirty methods, code could be merged later based on the "official" approach. Best Regards, Thorsten.

Did you already consider to write a .NGR script for this purpose? -> http://www.ucapps.de/midibox_ng_manual_ngr.html It allows you to send multiple MIDI events at once and set the LED accordingly based on (if/else) conditions. Best Regards, Thorsten.

Hi Chris, I remember that you requested this feature some time ago, and I implemented the "set_min" and "set_max" command for this purpose which can be executed from a .NGR script. E.g. together with a conditional EVENT_KB (active when a dedicated button is pressed) you could execute a .NGR section which sets the min/max ranges based on the pressed key. You've even the flexibility to set multiple split points this way... Best Regards, Thorsten.

Hi Kai, this is the white list: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_whitelist There are many MIDIbox users in the UK who could help, but I fear that they won't read this posting. I would recommend to create a new posting with a meaningful topic Best Regards, Thorsten.

Hi Zam, I would expect that following configuration works: EVENT_LED id= 1 type=SysEx stream="0xf0 0x01 0x02 0x03 0x04 ^value 0xf7" This should switch the LED based on the ^value which is part of the SysEx string: LED on: f0 01 02 03 04 7f f7 LED off: f0 01 02 03 04 00 f7 (can be sent with the MIOS Studio based SysEx tool) Best Regards, Thorsten.

I noticed two errors: 1) beside the IO pins, you also have to initialize the SPI protocol. Here the appr. code for APP_Init(): // initialize SPI IO pins and protocol MIOS32_SPI_IO_Init(2, MIOS32_SPI_PIN_DRIVER_STRONG); MIOS32_SPI_TransferModeInit(2, MIOS32_SPI_MODE_CLK0_PHASE0, MIOS32_SPI_PRESCALER_16); // ca. 5 MBit 2) MIOS32_SPI_RC_PinSet() sets the RC2 pin instead of RC1 Use: MIOS32_SPI_RC_PinSet(2, 0, 0); to set J19:RC1=0, and MIOS32_SPI_RC_PinSet(2, 0, 1) to set J19:RC1=1 After the modifications the transmitted values look ok on the scope. Best Regards, Thorsten.

Yes, correct. The IO pins have to be configured for push-pull mode (and not open-drain mode). Best Regards, Thorsten.

Hi, welcome on board! :smile: MIOS32 is more like a framework for MIDI applications. Together with FreeRTOS (the actual operating system which handles the multithreading) it gives you many functions which are typically required, and some kind of abstraction layer which simplifies porting to other microcontrollers. For your plan there are two possibilities: either you start from scratch by learning the MIOS32 basics, then start with the tutorials: http://www.ucapps.de/mios32_c.html Tutorial #029 explains how to scan a FATAR keyboard, but you shouldn't go into this before reading the first tutorials. Alternatively start with a premade application. MIDIbox KB matches exactly with that you are looking for: http://www.ucapps.de/midibox_kb.html MIDIbox NG is more advanced, because it also allows to connect additional control elements: http://www.ucapps.de/midibox_ng.html Last but not least: search in the forum for "fatar" and you will find some postings with additional information. Maybe somebody has the same keyboard? A picture and/or type number would help... Best Regards, Thorsten.