Jump to content

TK.

Administrators
  • Posts

    15,206
  • Joined

Posts posted by TK.

  1. Hi @sis.tm this is interesting! I noticed a similar effect some weeks ago, first download was incomplete. Since neither the bootloader, nor MIOS Studio have been changed, my conclusion was that it's either related to my USB Hub, or a MacOS update.

    Are you also using MacOS "Catalina" (10.15)?

    Best Regards, Thorsten.

  2. I think that you mis-interpreted the LFO function of MBSEQ

    To the configuration: once you store the "global setup" in the SAVE page, you could also edit the values directly with the edit function of MIOS File Browser (I think the file is called DEFAULT.CV2, search for it) - I'm doing the same, much faster :)

    Best Regards, Thorsten.

  3. 1 hour ago, sis.tm said:

    i uploaded the new hex file but when i start to press play on my midiphy now i get a hard fault at pc=0x08036200 . I am trying to find a way to download 0.95 again but i don't know how

    I need more input to help on this.

    Last time you tried v096_pre9, and this version seem to work at your side, right?

    Older versions are archived under: http://ucapps.de/mios32/backup/

    so, you could try the archived v096_pre9 again - is it crashing as well?

    And in case it is crashing (maybe because you are using a feature which wasn't tested by myself): which of the pre* versions doesn't cause the problem?

    Best Regards, Thorsten.

  4. 5 hours ago, monokinetic said:

    Using a fresh compile of master from Github to try out that amazing v4.96 feature set, I tried to set a track to control an AOUT using the LFO as mentioned recently. Indeed assigning the extra out sends the LFO to the AOUT, excellent another source of modulation!

    note that this is not really comparable with a real LFO - it's a LFO intended to send out MIDI events, and a typical resolution of MIDI is 1 mS -> means, higher frequency will appear very steppy!

    5 hours ago, monokinetic said:

    But on my set up (unipolar original AOUT) the output seemed weird. For example, when I first turn on the LFO effect, and set the output to sine I get a triangle. Then changing through the waveforms gave me just lower volume versions of the wave, it seems to be a saw. Having seen this on the scope, this made me go back and check the output via MIDI CC and it seems the same. If it helps, I have experimented with amp and offset. I expected that with both set to 64 I should see the full waveform, i.e. triangle going from 0 to 127. But what I see seems weird to me!

    I looked into the source code (that I wrote many years ago) - and you are right:

    Quote

    case SEQ_LFO_WAVEFORM_Sine: { // currently no real sine!

    Sine is a bipolar triangle, and triangle only used the positive range

    At the time I implemented this, I found this sufficient

    Best Regards, Thorsten.

  5. MIDIbox SEQ V4.096 has been officially released under http://www.ucapps.de/mios32_download.html

    ChangeLog:

    MIDIboxSEQ V4.096
    ~~~~~~~~~~~~~~~~~
    
       o Only for MBSEQV4+: support for up to 32 CV outputs (and corresponding gates).
         Means: up to 4 AOUT modules can be chained.
         Tested with MAX525 (and midiphy Eurorack Expander), but should also work with TLV5630 based AOUT_NG
         The additional CV outputs can be accessed with MIDI port CV2..4.
    
       o AOUT port has been renamed to CV1..CV4
    
       o Utility Page, GP Button #11 now changes to the CV Configuration Page
    
       o DOUT_1MS_TRIGGER in the MBSEQ_HW.V4 file has been replaced by a configurable trigger width which
         can be adjusted in the CV Configuration Page with GP13 now
    
       o Improved selection handling for midiphy frontpanel:
           - if you press&hold the Bookm/Step/Track/Param/Trigger/Instr/Mute or Phrase button, and then
             make a selection with SEL or GP buttons, the selection button will jump back to the previous
             function
           - if you press&release these buttons without a selection, the function stays active.
    
         Example: let's say the track selection is active.
         Press&Hold Param button, change to a new parameter layer, then release the Param button
         -> the selection buttons will jump back to track selection.
    
         If it's desired to permanently control the parameter layer with the selection buttons, just
         press&release the Param button.
    
       o It's now possible to customize the list of labels which are used during track/pattern
         name and category and drum selection. After booting the new firmware, following files
         will be created in the /PRESETS folder: TRKLABEL.V4P, TRKCATS.V4P and TRKDRUMS.V4P
    
         Edit these files with the MIOS File browser. Uploaded changes are immediately taken
         over.
    
         - TRKLABEL and TRKCATS: are used in MENU->EVNT, "Trk Inst.", "Edit Name" page
           (Use GP15 to select the Preset)
    
         - TRKDRUMS is used on the same page when a drum track is edited (instead of a
           track name we configure instrument names)
    
           Special treatment: TRKDRUMS.V4P also maps MIDI notes to the drum labels.
           Whenever a new preset drum is selected, the drum note will be changed accordingly.
           This allows you to fully customize drum maps.
    
           The first 16 drums are taken by default whenever a drum track is initialized, and the
           remaining drums in the list can be optionally selected to replace on of the 16
           drum instruments.
    
         - TRKLABEL and TRKCATS are also used when a pattern is saved
    
       o New option 9/33 allows to unmute tracks on pattern changes
    
       o New option 14/33 allows to change the steps of the current selected view only
    
       o the MIDI mixer can now send CC values to a bus.
         This especially allows to record CC changes (configure MENU->MIDI->Port accordingly
         so that it listens to the bus in Jam mode)
    
       o New parameter layer "Ctrl" allows to change track parameters as documented in
         the doc/mbseqv4_cc_implementation.txt table (previously this was only possible
         from a dedicated loopback track).
    
       o Recording function considers "Ctrl" layers as well if the assigned parameters
         are changed on the UI
    
       o CV Calibration in CV page: special handling for Hz/V curve
    
       o CV Calibration in CV page: press GP7 button to switch between bipolar/unipolar display
    
       o fixed "lost button mapping" issue if SD Card is removed
    
       o MBSEQV4+: fixed MIDI export crash

    Best Regards, Thorsten.

  6. Actually I wanted to provide SPI slave (see some postings above), so that the module can be connected to J28 instead of ENC28J60

    But a UART connection is available as well - and the baudrate is configurable by default.

    As long as you only need a point-to-point connection, UART is a good choice. But for accessing multiple ports (e.g. BLE and Apple MIDI) SPI would be better, because it considers multiple "cables".

    Best Regards, Thorsten.

    P.S.: in context of MBHP_MF_NG: only UART option will work, because SPI is already used for other purposes.

  7. It's available now.

    Works only with STM32F4 - in the SCS AOUT page, scroll a bit right so that you see the "Cali Offs Disp" items.

    Display should be set to "Bip."

    Change "Cali" to -5V, an offset will appear. This one can be increased up to 4095
    Following "Cali" points are -4V, -3V, -2V, .. 5V - offsets can be changed  between -2048 and 2047

    While changing the offsets, use a multimeter to check the result until value is matching.

    Best Regards, Thorsten.

  8. But it should work with EVENT_RECEIVER

    When we take following configuration:

    RESET_HW
    
    EVENT_RECEIVER id=1  type=SysEx  stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^ignore ^ignore ^ignore ^ignore ^dump 0xf7"
    
    EVENT_ENC id=1   hw_id=1  label="@(1:1:1)Prm1 @(1:1:2)%03d"    range=0:127  fwd_to_lcd=1  type=SysEx  stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x55 ^val ^chk_roland 0xf7"  syxdump_pos=1:0
    EVENT_ENC id=2   hw_id=2  label="@(1:6:1)Prm2 @(1:6:2)%03d"    range=0:127  fwd_to_lcd=1  type=SysEx  stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x56 ^val ^chk_roland 0xf7"  syxdump_pos=1:1
    EVENT_ENC id=3   hw_id=3  label="@(1:11:1)Prm3 @(1:11:2)%03d"  range=0:127  fwd_to_lcd=1  type=SysEx  stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x57 ^val ^chk_roland 0xf7"  syxdump_pos=1:2
    EVENT_ENC id=4   hw_id=4  label="@(1:16:1)Prm4 @(1:16:2)%03d"  range=0:127  fwd_to_lcd=1  type=SysEx  stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x58 ^val ^chk_roland 0xf7"  syxdump_pos=1:3

    and send (e.g. via the MIOS Studio SysEx window):

    f0 41 10 00 10 12 00 00 00 00 10 20 30 40 f7

    the LCD will show the expected values 016, 032, 048, 064

    It's important that the ^ignore statements in the receivers SysEx string will be replaced by concrete values, otherwise the receiver will respond on any matching SysEx strings which don't transfer the intended information.

    So, after 0x12, what is normally sent back by your synth if these 4 parameters are requested?

    Note also, that checksums are not relevant for receivers, therefore I just wrote 0xf7 after the ^dump

    Best Regards, Thorsten.

     

  9. Hi David,

    a feature that I recently implemented for MBSEQ would help here - and actually I already planned to integrate it into MBCV and MBNG as well: the calibration points.

    See apps/sequencers/midibox_seq_v4, search for AOUT_NUM_CALI_POINTS

    Would you like to add this by yourself, or should I do this?

    Best Regards, Thorsten.

  10. Short update: the ESP32 based MBHP_MF_NG can now communicate with BLEMIDI over Bluetooth, Apple MIDI over WIFI, and traditional MIDI via UART

    -> https://github.com/midibox/esp32-idf-mfdrv

    Still some work to do, but I think that this is a pretty good basis for other MIDIbox projects - special focus was on reliable SysEx transfers and routing between different MIDI interfaces.
    This major challenge is solved! :-)

    Best Regards, Thorsten.

  11. (I've to think about your proposal about "bulk operations" on the active flags (and maybe others...)

    To the problem: the reason, why the event doesn't update the LCD is because of the "0xf0" at the end of the SysEx strings, e.g.:
    EVENT_ENC id=1   hw_id=1  label="@(1:1:1)Prm1 @(1:1:2)%03d"    range=0:127  fwd_to_lcd=1  type=SysEx  stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x55 ^val ^chk_roland 0xf0"

    Just write 0xf7 instead, and the LCD will be refreshed, because this is what your synth will send.

    It could be, that the same typo already caused other side effects, also on your synth.

    Concerning the encoder value problem: check again with the updated definition, if it still happens I need a concrete configuration to test it at my side.

    Best Regards, Thorsten.

  12. This is definitely not the intended behaviour!

    I started to debug this at my side - the received values will be taken over as expected, but somehow they got lost (set to 0) *before* they are print out by the LCD.

    Need more time to debug this...

    Best Regards, Thorsten.

  13. While waiting for the PCB I worked on the "Apple MIDI" protocol which allows to transfer MIDI messages over WIFI (and Ethernet - known from this project: 

    As a second project I consider to create a universal "MIDI bridge" device for MIDIbox projects which supports UART, Bluetooth, WIFI and SPI, maybe also CAN.

    So, it can be connected via SPI port J28 to a MBHP_CORE_STM32/F4/LPC17 instead of the MBHP_ETH module, or alternatively via UART (e.g. also to PIC based projects) giving us wireless connections :)

    The latency is not so nice - expect ca. 5 mS + some jitter - it won't be really suitable for sending MIDI Notes, but it will be very nice for MIDI controllers.

    Another topic which needs to be explored: if the antenna is strong enough to send/receive in a metal case, like MIDIphy MBSEQ V4+

    Best Regards, Thorsten. 

  14. An interesting case - it seems that I never tested incoming SysEx streams while parsing ^chk_start - this was causing the endless loop and it's fixed now:

    -> http://www.ucapps.de/mios32/midibox_ng_v1_037_pre8.zip

    Note that with this change the EVENT_ENCs will update their value according to the specified SysEx stream.
    Which means, that the EVENT_RECEIVER is not required anymore.

    And the way it's currently used it causes a problem with EVENT_ENC id=2 (which picks up the checksum via syxdump_pos=1:1)

    So, just remove EVENT_RECEIVER and maybe also the syxdump_pos arguments - they are intended to pick up values from "patch dumps"

    Best Regards, Thorsten.

  15. There are some problems with this configuration:

    • syxdump_pos=1:x --- x starts counting from 0, not 1
      Means: with syxdump_pos=1:0 you should get the expected "25" of "f0 25 f7"
    • the value will be put into the first ENC event with ID 1, the second one with the same ID won't get the value
    • I think that you defined two events with the same ID since you wanted to print out something at a second line. This can also be done with a single event, just use the "@(lcd:x:y)" keyword
    • it makes sense to use "%3d" instead of "%d" to ensure that the decimal value (overwrites) 3 characters
    • by adding fwd_to_lcd=1 the received SysEx value will be displayed immediately

    So, just replace the 4 EVENT_ENC lines by following 2 lines:

    EVENT_ENC id=1   hw_id=1  fwd_to_lcd=1  lcd_pos=1:1:1   label="Prm1 @(1:1:2)%3d  "  range=0:127  syxdump_pos=1:0
    EVENT_ENC id=2   hw_id=2  fwd_to_lcd=1  lcd_pos=1:6:1   label="Prm2 @(1:6:2)%3d  "  range=0:127  syxdump_pos=1:1

    Best Regards, Thorsten.

×
×
  • Create New...