Jump to content

TK.

Administrators
 View Profile  See their activity

  • Posts

    15,199

  • Joined

 Content Type 

Posts posted by TK.

  6. No Response from LPC17 core - Mios-studio- crashes my app

    in MIDIbox Tools & MIOS Studio

    Posted

    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.

  7. MBHP_CORE_LPC17: stuff jumper J27 (BL Hold) to select the bootloader hold mode, thereafter power-cycle the core.
  8. 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.

    9. Best Regards, Thorsten.

  10. I added a few features to the Humanize function...

    in MIDIbox SEQ

    Posted

    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.

  16. I added a few features to the Humanize function...

    in MIDIbox SEQ

    Posted

    I just listened to three one-bar tracks play more or less by themselves for like an hour...  This thing produces pretty musical results...  Lots of little subtle (and not so subtle) variations...

     

    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.

  19. I added a few features to the Humanize function...

    in MIDIbox SEQ

    Posted

    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

     

     

    Also, I could probably get away with using 4 bit (or even 2 bit for the octave setting) numbers rather than 8 bit numbers for some of these settings to save some space in seq_cc_trk.  Shorter number ranges would make the humanizers easier to use (no need to turn the encoder so many times), and I could store two settings in one CC byte that way...  Is there an example of storing more than one 2 or 4 bit numbers in the seq_cc_trk bytes anywhere in the codebase?

     

    The transpose values are a good example:

      u8       transpose_semi:4;  // semitons transpose
  u8       transpose_oct:4;   // octave transpose

     

    Could I arbitrarily define seq_trk_cc numbers above 0x7f without breaking anything?  I realize these numbers wouldn't be accessible by CC, but if I'm just looking for a place to store variables for purposes of experimenting with the humanize function, would arbitrarily defining higher seq_trk_cc numbers work?

     

    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

     

     

    Great codebase, by the way TK - it's really easy to work with, even not knowing much at all about C or hardware programming.  The toolchain setup is super easy too - I've had real problems with some other open hardware projects just trying to get to the point where I could compile anything, and the MIOS toolchain setup is super easy...

     

    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.

  21. I added a few features to the Humanize function...

    in MIDIbox SEQ

    Posted

    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.

  23. Feature Request: Set ranges with controller

    in MIDIbox NG

    Posted

    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.

  25. Fader Automation

    in MIDIbox HUIs

    Posted

    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.

  26. PGA2311 STM32F4 HowTo?

    in MIOS programming (C)

    Posted

    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.

×
×
  • Create New...