TK.

Are the MUTE# and ZCEN inputs really unconnected? Both should be connected to VD+ Best Regards, Thorsten.

It works at my side. Are you really using the latest lemur panel from http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2Flemur%2F&rev=2084# ? And are you able to update to a newer Lemur version? I'm using Lemur 5.2 Best Regards, Thorsten.

As far as I remember, the registration has to be done somewhere in the tool (but I don't remember where exactly) Best Regards, Thorsten.

From the documentation: The Error Codes (0E) ~~~~~~~~~~~~~~~~~~~~ Structure: F0 00 00 7E 40 <device-id> 0E <error code> <additional information> F7 <device-id>: the MIOS device ID from 00 to 7F <error code>: see below <additional information>: for internal use, ignore it Error Code | Description -----------+--------------------------------------------------------------- 0x01 | Less bytes than expected have been received 0x02 | More bytes than expected have been received 0x03 | Checksum mismatch 0x04 | Write failed (verify error or invalid address) 0x05 | Write access failed (invalid address range) - | used by 1st level bsl 0x06 | MIDI Time Out 0x07 | Wrong Debug Command 0x08 | 2nd level bsl: Read/Write command tried to access an invalid | address range 0x09 | 2nd level bsl: Read/Write address not correctly aligned 0x0a | BankStick not available 0x0b | MIDI IN Overrun (CPU load too high) 0x0c | MIDI IN Frame Error (Bad signal/Optocoupler) You got 0xc -> bad signal or optocoupler. If the resistor values are ok now, try another 6N138 Best Regards, Thorsten.

Hi Tim, no, this display won't work. It has no backlight anyhow -> no fun Best Regards, Thorsten.

Click on http://www.ucapps.de/midibox_seq_manual_blm.html Search for "MIOS Terminal" Best Regards, Thorsten.

Ok, I will check this tomorrow. Best Regards, Thorsten.

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.