Jump to content

TK.

Administrators
  • Posts

    15,246
  • Joined

Posts posted by TK.

  1. I remember that I never created new sequences on the RM1x and only used the preset patterns or sequenced the synth part with Cakewalk (a "DAW" running under Windows). And then I noticed that with a simple MB64 based sequencer I was able to work out interesting sequences much faster - this motivated me to add more and more features to the firmware, with the result that I created a dedicated sequencer with optimized UI - MBSEQ V2 was born: http://www.ucapps.de/midibox_seq_v2.html

    Best Regards, Thorsten.

  2. @monokinetic yes it should be possible without much effort to activate the same functions for MBCV (and MBNG) - will check this the next days

    @latigid on an optional enter button to confirm entries is not considered in the firmware and also not so easy to implement (too many changes at too many places) - I also wouldn’t use it by myself, therefore it won’t be supported.

    Best Regards, Thorsten.

  3. Finally v4.095 is available with a lot of christmas presents as found in the wishlist of many people :)

    MIDIboxSEQ V4.095
    ~~~~~~~~~~~~~~~~~
    
       o support for midiphy Frontpanel.
         The appr. HW configuration file can be found under
         hwcfg/midiphy_lh/MBSEQ_HW.V4 and hwcfg/midiphy_rh/MBSEQ_HW.V4
    
       o introduced first "MBSEQV4+" function.
         MIDIbox SEQ V4+ is a special firmware variant for the STM32F4 core.
         It offers additional memory and/or CPU hungry functions which can't be implemented
         for STM32F1 or LPC17 due to resource limitations.
         These special functions are marked with "V4+" in future.
    
       o V4+: implemented CC layers for drum tracks.
         The CC numbers are statically assigned for all tracks of the session.
         They can be changed in the Options page (item 20/26)
    
       o trigger/layer edit views now also supported for drum tracks
    
       o reference step for pattern changes now works indpendent from reference step used for sync-to-measure
    
       o PATTERN page: pattern is switched immediately if SELECT button is pressed, regardless of
         the pattern change synchronisation option.
    
       o OPTIONS page: new option "Print and Modify Steps w/o changing Gate".
         If enabled: note values will always be print regardless if they are played or not.
         Changing a note value won't automatically enable the gate
    
       o OPTIONS page: new option "Print Notes with transposed value".
         Enabled by default (due to change in V4.093), can be optionally disabled now.
    
       o OPTIONS page: new option "Swap LED colours" (relevant for Wilba and midiphy Frontpanels)
    
       o OPTIONS page: new option "Invert Mute LEDs"
    
       o OPTIONS page: new TPD option "BPM" and "BPM with Beat": prints tempo value and optionally flashes to measure/beat
    
       o OPTIONS page: new TPD option "Logo" and "Logo with Beat": prints a 16x8 logo and optionally flashes to measure/beat
         There are individual logos for each session which can be edited in the MBSEQ_C.V4 file.
         If you don't find "TpdLogoLine" items there (because you are using an older session) just trigger the "Save" function
    
       o AOUT: MIDI Channel 9..12/13..15 now set the gate pins #1/3/5/7 as documented (previously it was #1/2/3/4 due to a code translation error)
         New: gate pins #2/4/6/8 are now set whenever the velocity is >100.
         This way the pins can be used as an accent trigger
    
       o V4+ AOUT: support for AOUT channel calibration.
         In the CV configuration menu, turn GP ENC #7 until 0V/1V/2V/.../Max will be visible.
         Calibrate the offset of the target value with ENC #8.
         Press GP #8 to cycle between min/0/max offset of the calibration point.
         Each V has a dedicated calibration value which can be configured this way, the output will be interpolated accordingly.
         Note that with exiting the CV configuration menu the calibration values are stored on SD Card in the MBSEQ_GC.V4 file
         (-> CV_Cali <cv-counting-from-0>).
         You could backup/set/restore the values from there if required.
         To reset all calibration values: delete all CV_Cali items in MBSEQ_GC.V4, store the file and enter "reset" in MIOS terminal.
    
       o Bugfix for permanently cleared notes if live recording is used after previous step recording
    
       o ProgramChange Layer: steps now disabled by default when the track is cleared
    
       o Whenever a track or parameter layer is unmuted, it will be automatically selected
         This option can now be disabled in the OPTIONS page (item 9/29)
    
       o new terminal command "lcd" allows to display a temporary message from on LCD from
         an external device via SysEx
    
       o encoder buttons can now be assigned in the MBSEQ_HW.V4 file (currently hardcoded to FAST function)
    
       o STM32F4 board: orange LED shows SD Card available, red LED any received MIDI IN, blue LED any transmitted MIDI OUT
    
       o experimental: terminal command "backup" creates a .tar file of the entire SD card.
         Whenever "backup" is entered, a new bak<incremented-number>.tar file will be created.
         This file can be downloaded from MIOS Studio (might take a lot of time!) or from a computer by
         plugging the SD Card into a SD Card reader.
         .tar files can be unpacked with "tar xfv <filename>" or with other decompression tools (might be 
         already installed on your computer by default)
    
       o experimental (might be optional in future): show measure and pattern step position in main screen
    

    Best Regards, Thorsten.

  4. Very very cool! :)

    Can't wait to get more time for MIDIbox again (in some days...) to continue with my build based on Peters superb tutorial :)

     Will also release the firmware after some trial runs (and maybe some V4+ specific add-ons)

    Best Regards, Thorsten.

  5. Development Queue overflow... %-)

    Your input won't get lost, but I think that I've to consolidate the ideas and request if still valid based on my proposals once I find the time to think about the implementation...

    @Rio: thanks! :)

    @beautyofdecay_ I added an experimental AOUT calibration feature:

     

       o V4+ AOUT: support for AOUT channel calibration.
         In the CV configuration menu, turn GP ENC #7 until 0V/1V/2V/.../Max will be visible.
         Calibrate the offset of the target value with ENC #8.
         Each V has a dedicated calibration value which can be configured this way, the output will be interpolated accordingly.
         Note that with exiting the CV configuration menu the calibration values are stored on SD Card in the MBSEQ_GC.V4 file
         (-> CV_Cali <cv-counting-from-0>).
         You could backup/set/restore the values from there if required.
         To reset all calibration values: delete all CV_Cali items in MBSEQ_GC.V4, store the file and enter "reset" in MIOS terminal.
    

    Please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_095_pre13.zip

    Does it work at your side?

    Best Regards, Thorsten.

  6. The MIDIbox NG application has such an interpolation routine which could be re-used for calibration purposes in MBSEQ.

    However, I'm a bit surprised that a SW based calibration is required.
    Which AOUT module are you using?
    And how big is the deviation compared to the ideal curve within the 1V segments?

    Best Regards, Thorsten.

  7. Just got a flashback: this is actually a known issue and I thought that I fixed this some years ago... somehow the change didn't find it's way into the repository.

    I updated mios32/LPC17xx/mios32_board.c, please update your repository

    Best Regards, Thorsten.

  8. There are good reasons why I decided to use an UART based MIDI interface for interconnections:

    • universal approach, easy to setup from a (PC) and easy to connect to other cores
    • MIDI messages are buffered via FIFOs, this relaxes the MIOS32 application requirement. E.g. it could prioritize the handling of other tasks and doesn't need to frequently poll for incoming messages to avoid information loss. By default the FIFOs are dimensioned with 64bytes, which means that we can bridge up to 20 mS
    • no need to program special interface communication handlers -> less troublesome & no special knowledge required
    • MIDI cable can be up to 10m
    • optocouplers decouple the noisy MF voltage from the MIOS32 core, this improves EMC
    • level-shifting 3.3V to 5V part of the physical MIDI interface

    So, if you are searching for alternative interfaces, they all have cons

    • you have to learn how to program such interfaces. I won't have so much time to help you on this... you've to find your own way
    • the MBNB_MF_NG firmware is programmed in assembly language which is difficult to enhance for people who never did this before
    • all IO pins of the MBHP_MF_NG module are allocated, for a different interface you've not only program a new firmware, you also have to change the circuit

    Possible interfaces:

    SPI

    Cons:

    • no programming example available for MIOS8
    • requires 4 IO pins (RC3, RC4, RC5, RA5)
      MBHP_MF_NG circuit has to be modified. But especially RA5 does hurt, since this is an analog input (actually a killer argument)
    • no programming via MIDI possible anymore, you've to use a PIC programmer instead
    • actually more valuable than MIDI ports, since only 3 SPI interface ports exist on a typical MIOS32 core. One (J8/9) is allocated for SRIO, another one (J16) for SD Card and Ethernet at 3.3V level, another one (J19) is free, but typically used for AOUT/AINSER, etc... However, if SPI, than you would either have to sacrifice J8/9 (-> no SRIO), or J19 (-> probably unusued in your application? But couldn't be used for all applications, so: only a dedicated solution for your purposes)
    • MIOS32 core has to frequently service the SPI to avoid message loss
    • programming will be much more complicated

    I2C

    Cons: 

    • requires 2 IO pins (RC3, RC4)
      MBHP_MF_NG circuit has to be modified
    • no programming via MIDI possible anymore, you've to use a PIC programmer instead
    • MIOS32 core has to frequently service the I2C
      I2C overhead higher than for other interfaces, will slow down your application and/or result into message loss
    • programming will be much more complicated

    CAN

    Cons:

    • requires different PIC chip (e.g. PIC18F4685)
    • requires 2 IO pins (RB2, RB3)
      MBHP_MF_NG circuit has to be modified
    • MIOS32 core has to frequently service the CAN interface.
      Similar to I2C and SPI there is a high risk for message loss if this isn't done frequently
    • programming will be most complicated compared to other interfaces

    Best Regards, Thorsten.

×
×
  • Create New...