Jump to content

TK.

Administrators
  • Posts

    15,246
  • Joined

Posts posted by TK.

  1. Hi,

    you don't need to change the existing code to do this, just use the "set_kb_transpose" command in a NGR script.

    Following example demonstrates this: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/kb_6.ngr

    And here the corresponding events which trigger the ^sections: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/kb_6.ngc

    Best Regards, Thorsten.

  2. Additional notes: could be that you rely on 5V output - in this case change MIOS32_BOARD_PIN_MODE_OUTPUT_PP to MIOS32_BOARD_PIN_MODE_OUTPUT_OD, and add a 1k pull-up to 5V to this pin.

    And if J10A is already used for SCS inputs (standard), just take J10B.D0 (pin index #8)

    Best Regards, Thorsten.

  3. You don't need to enhance mios32_spi, just control the additional pin directly from AINSER_SetCs

    E.g. let's assume that J10.D0 is unused so far, then add to AINSER_Init():

    MIOS32_BOARD_J10A_PinInit(0, MIOS32_BOARD_PIN_MODE_OUTPUT_PP);

    and to AINSER_SetCs:

    case 2: return MIOS32_BOARD_J10_PinSet(0, value);

    Best Regards, Thorsten.

  4. Unfortunately there is currently no way without a duplicated track.

    Background: the sequencer engine handles tracks which are sending to an internal bus (so called "loopback tracks") differently compared to common tracks:

    • they are processed before MIDI events of "common tracks" are scheduled to ensure that transposers/arpeggiators get updated before they play the next note independent from the track order
    • they have no timing information - MIDI notes directly processed without delay, note off, echo, etc
    • that's also the reason why the "Duplicate" Fx doesn't allow to route MIDI events to Bus1..4

    This approach solved many problems that we noticed in earlier MBSEQ versions (V1..V3), but it has the drawback that loopback tracks can't be used for sending "common MIDI events" anymore.

    Best Regards, Thorsten.

  5. Hi Bruno,

    yes, just try it and commit your change in a special branch (from master) - we can merge once we both are satisfied.

    By searching for defines like MIOS32_SYS_ADDR_SPI_MIDI (e.g. via "grep --rec") you can find the places which need to be modified.

    Best Regards, Thorsten.

  6. Which values would you like to permanently store & change in the bootloader.

    I need names + sizes

    I will define those values in mios32_sys.h within the MIOS32_SYS_ADDR_BSL_INFO_BEGIN section
    -> https://github.com/midibox/mios32/blob/master/include/mios32/mios32_sys.h

    As you can see, we can either define a block + confirmation value, or individual values + confirm.
    If you could predict today how many bytes need to be allocated, we could use a single confirmation which saves space for other future extensions (used for other purposes)

    Best Regards, Thorsten.

  7. Hi Peter,

    I'm resistent on this feature, because it will dramatically increase the CPU time and RAM consumption. We've up to 256 layers which could send CCs, and we would have to determine the target value when the start CC is played - means, we've to walk the steps until the next CC is found for each layer, this will consume some uS for each layer!

    The next CC could change while the sequencer is playing, this leads to special treatments at some places...

    In RAM we've to store the current, target and sent values for each layer, resulting into 3 * 256 bytes

    Best Regards, Thorsten. 

  8. We could reserve a bootloader location to make this basic_node number configurable without touching the source code.

    Similar the way I did for other "permanent" flags & values.

    Best Regards, Thorsten.

  9. Reverse engineering a protocol for private purposes is one thing, publishing the information another.

    In any case: please don't publish any specific information about this protocol in this forum, this could bring me (as the forum owner) into serious legal issues!

    Best Regards, Thorsten.

    P.S.: I haven't looked into this protocol because I don't like the license. Anything which can't be openly published isn't interesting for my projects.

  10. Impressive work!

    The WS2812 driver was only a quick hack, I was already satisfied after it was working and haven't expected that somebody would ever drive more than 50..100 LEDs.

    It shouldn't be a big deal to optimize the memory consumption. There are various places in MIOS32 where I already used DMA double buffers (e.g. I2S audio output). Nothing needs to be explored, just translation :)

    Best Regards, Thorsten.

  11. Yes, each RGB LED will consume 48 bytes. With the latest changes up to 390 RGB LEDs can be defined, and you will get a proper RAM error message if there are too much, such as:

    /opt/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: project_build/project.elf section `.bss' will not fit in region `RAM'
    /opt/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 424 bytes
    collect2: error: ld returned 1 exit status
    

    Best Regards, Thorsten.

  12. Hi,

    STM32F4 was running out of memory - and due to an wrong linker file entry you haven't got an error after the 128k boundary of the "normal RAM" has been touched.

    However, this chip has some additional 64k as a so called "core coupled memory", which is located at 0x10000000

    I changed the linker file and preload code to support this memory.
    In addition, in the MBNG application I moved the heap memory into this CCMRAM, giving us about 10k more space.

    Updates are available at github: https://github.com/midibox/mios32/commit/9dc48579c31766815997b0ce3eac88f9d772578a

    I havent't checked if this has a new negative side effect, but at least MBNG is booting and RGB LEDs are working

    Best Regards, Thorsten.

     

  13. Source code is here: https://github.com/midibox/mios32/tree/master/apps/sequencers/midibox_seq_v4

    Beat Light is controlled in src/seq_ui.c: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_ui.c
    (search for BEAT)

    The problem is understood - it appears on frontpanels with single colour LEDs (MEASURE not assigned). 

    However, a quick fix is easy: just replace

    SEQ_LED_PinSet(seq_hwcfg_led.beat, (seq_hwcfg_led.measure && measure_led_on) ? 0 : beat_led_on);

    by

    if( seq_hwcfg_led.measure != 0xffff )
      SEQ_LED_PinSet(seq_hwcfg_led.beat, (seq_hwcfg_led.measure && measure_led_on) ? 0 : beat_led_on);
    else
      SEQ_LED_PinSet(seq_hwcfg_led.beat, beat_led_on);

    Untested code

    Please let me know if it works, so that I will bring it into the repo

     

    Concerning mirrored Roll parameter: that's normal if the parameter layer is only 16 steps. It's due to a memory limitation - drum tracks can only store 1024 parameters, and they are partitioned over the number of drum tracks and parameter layers

    Best Regards, Thorsten.

  14. The workflow can be much easier: just clone the worktree, create a branch, commit into this branch how often you want, push to GitHub whenever you want to ensure that your work doesn't get lost (and want that other people can access your changes).

    There are various tools to display code changes between branches, between your commit, etc. also locally without the need for a webserver.
    E.g. I'm using "gitk", but there might be many others.

    But uploading to GitHub is preferred - not only for backup reasons, but also to allow later merging into master branch via pull request + review from my side.

    Best Regards, Thorsten.

  15. Hi,

    actually environment variables are "local" in your shell. Which means, if you open multiple shells you can set the variables to different values in order to work on multiple projects in parallel. Build objects are created locally in your app folder as well.

    Or you could create a small shell script which sets the variables before calling "make" - this way you could work from a single terminal.

    Or you quickly switch between the setups by sourcing one of the "source_me_*" files in the base directory: https://github.com/midibox/mios32

    Of course, it's also possible to create different GIT clones which makes sense if you work in separate branches for each activity.

    Best Regards, Thorsten.

  16. @Digineuralthanks for the info! I've to explore Dockerfile, it promises high potential :)

    @Phatlineunfortunately I don't understand the problem, I haven't provided the package as a "rar" file, and the binary works with various Linux installations that I tried so far. There seems to be something wrong with your OS installation (maybe you are using an expert system?), but I fear that I can't give you more hints.

    @Elektruckas long as you are the only Win10 user who has this problem with SD Card uploads I won't start to analyze this.

    MIOS Studio 2.4.8 is released now @ http://www.ucapps.de - let's see if additional users report problems; the legacy 2.4.6 files are still accessible from the same page to ensure that nobody is blocked by the progress (only 64bit systems supported anymore)

    Best Regards, Thorsten.

  17. 2 hours ago, Antichambre said:

    In general, this is good news because the latest version of XCODE no longer supports SVN. Maybe that's why you moved it.

    No, I moved because I noticed that your MCAN activity doesn't really fit with the subversion work flow anymore. ;)

    27 minutes ago, latigid on said:

    This was discussed elsewhere, but just to be clear: you (TK.) prefer to keep control of the master line and review all changes, and you will keep the same license terms as non-commercial for personal use only (no GPL/CC-BY etc.)? This is not a request for you to change anything you don't want to of course.

    yes

    Best Regards, Thorsten.

×
×
  • Create New...