Jump to content

TK.

Administrators
  • Posts

    15,205
  • Joined

Posts posted by TK.

  1. The EVENTs which are controlled via NGR script shouldn't be assigned to a bank, otherwise concurrent changes on the "active" flag will happen.

    Therefore just write:

    # select tone 1-2 and trigger NGR script
    MAP1 1 2
    EVENT_BUTTON id=35  hw_id=35 range=map1 button_mode=Toggle type=meta meta=RunSection:1
    
    # select bank and trigger NGR script
    EVENT_BUTTON id=36 hw_id=36 type=Meta meta=CycleBank meta=RunSection:1 button_mode=OnOnly
    
    # dummies to define bank1/2
    # can be removed if banks are defined for other events (not controlled from NGR script)
    EVENT_BUTTON id=3001 bank=1
    EVENT_BUTTON id=3002 bank=2
    
    
    ### First page
    EVENT_ENC id=1   hw_id=1  lcd_pos=1:1:1   label="1_1%B "
    EVENT_ENC id=2   hw_id=1  lcd_pos=1:1:1   label="1_2%B "
    EVENT_ENC id=3   hw_id=2  lcd_pos=1:6:1   label="2_1%B "
    EVENT_ENC id=4   hw_id=2  lcd_pos=1:6:1   label="2_2%B "
    
    ### Second page
    EVENT_ENC id=5   hw_id=1  lcd_pos=1:1:1   label="9_1%B "
    EVENT_ENC id=6   hw_id=1  lcd_pos=1:1:1   label="9_2%B "
    EVENT_ENC id=7   hw_id=2  lcd_pos=1:6:1   label="A_1%B "
    EVENT_ENC id=8   hw_id=2  lcd_pos=1:6:1   label="A_2%B "

    And in the NGR script I noticed some wrong "endif" statements.
    "elsif" will only work for the previous "if" condition if you don't terminate it with "endif":

    ### First page of parameters
    if ^bank == 1
        LOG "First Bank"
        ### tone 1
        if (id)BUTTON:35 == 1
            set_active (id)ENC:1 1
            set_active (id)ENC:2 0
            set_active (id)ENC:3 1
            set_active (id)ENC:4 0
            set_active (id)ENC:5 0
            set_active (id)ENC:6 0
            set_active (id)ENC:7 0
            set_active (id)ENC:8 0
        ### tone 2
        elsif (id)BUTTON:35 == 2
            set_active (id)ENC:1 0
            set_active (id)ENC:2 1
            set_active (id)ENC:3 0
            set_active (id)ENC:4 1
            set_active (id)ENC:5 0
            set_active (id)ENC:6 0
            set_active (id)ENC:7 0
            set_active (id)ENC:8 0
        endif
    
    ### Second page of parameters
    elsif ^bank == 2
        LOG "Second Bank"
        ### tone 1
        if (id)BUTTON:35 == 1
            set_active (id)ENC:1 0
            set_active (id)ENC:2 0
            set_active (id)ENC:3 0
            set_active (id)ENC:4 0
            set_active (id)ENC:5 1
            set_active (id)ENC:6 0
            set_active (id)ENC:7 1
            set_active (id)ENC:8 0
        ### tone 2
        elsif (id)BUTTON:35 == 2
            set_active (id)ENC:1 0
            set_active (id)ENC:2 0
            set_active (id)ENC:3 0
            set_active (id)ENC:4 0
            set_active (id)ENC:5 0
            set_active (id)ENC:6 1
            set_active (id)ENC:7 0
            set_active (id)ENC:8 1
        endif
    endif
    exit

    With these changes it works at my side :)

    Best Regards, Thorsten. 

  2. Hi,

    if_equal will match the EVENT value, not the bank, therefore this function won't help for the intended purpose.

    For complex banking schemes I introduced the NGR command "set_active", where the script can activate/deactivate EVENTs based on your own rules.

    E.g. following example shows how to activate/deactivate based on the variable ^bank:

    https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/multibnk.ngc
    https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/multibnk.ngr

    In your case, you would add BUTTON:33 with an additional "if" condition to activate/deactivate (id)ENC:1 and (id)ENC:2 

    It will result into a very long NGR script - but it should work (and should be fast enough)

    Best Regards, Thorsten.

  3. I can't recommend this solution; it only transfers via a serial protocol, which then has to be converted by a computer into MIDI messages - this is error prone.

    Today we would prefer the BLE MIDI protocol, which is natively supported by many operating systems, and considers special MIDI features such as continuous SysEx streams.
    And this is possible with a simple ESP32 controller, which is available for the same (or less) price - and on top of this WiFi should be possible as well.

    Best Regards, Thorsten.

  4. And never forget: from a loopback track it's possible to control sequencer parameters of another track, here the corresponding parameter numbers: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/doc/mbseqv4_cc_implementation.txt

    And while I was writing this, I remembered that I wanted to make this function also available from a parameter layer.

    Here it is: http://www.ucapps.de/mios32/midibox_seq_v4_096_pre10.zip

    Quote

       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)

    E.g. in the Event configuration page, I assigned Par. Layer E to Ctrl: Echo Rep. and Layer F to Ctrl: EchoFB.V - and it works: with each step a new value can be set, or previous setting will be kept if "---" is selected (turn encoder full-right)

    Best Regards, Thorsten.

  5. 19 hours ago, Zam said:

    Ok ! don't know what is the agenda or if any major MFNG update is on the road (which I can help on by the way...)

    Good question! Currently it's mainly a learning vehicle for me to explore a new microcontroller and corresponding software.

    And now I'm also learning KiCad to enter the schematic (and maybe also the Adapter PCB) - currently only for my own interest.

    If you would like to play with the project as well, you are welcome of course! :)
    I will bring it at least to a state that others can use an adapter board on their existing MBHP_MF_NG, can connect via traditional MIDI but also Bluetooth and maybe also (later) rtp MIDI, but I can't promisse anything else.

    And at this point in time it especially needs "real life testing" before it's build by others.

    19 hours ago, Zam said:

    I suggest to factor at least 10 the clock in case of hybrid system (analog close to or in the fader...)

    let say 312.5kHz , which correspond to 256 speed level (you have room over 64...) also a value over 192kHz (HD audio)

    I mean If it's easy don't hesitate to change this...

    Was worth a try: I used 200kHz and it works like 20kHz - don't see a big difference on the motor handling itself - but probably in an analog system:

    20 kHz:

    fadermove_pwm_20khz.png.0d11e8299774454c

    200kHz:

    fadermove_pwm_200khz.png.2ce7255970bfffe

    The "noise" that we see here comes from the higher ADC resolution (faders are scanned at 12bit instead of 10bit) and messy ground on my vero board - this should become better with a PCB.

    But it doesn't impact the smooth movements.

    Of course, most interesting would be if it works so smooth like your 89MotionN: 

     

    At least I see a potential cost benefit ;-)

    Best Regards, Thorsten.

  6. Hi Tim,

    there is a metronome function which sends MIDI Notes, by default C#1 on Beat and Measure to Channel #10 of the default port (a GM compatible sound module would output the typical metronome sound).
    This can be configured at the Options page under 17/33

    I think that this is sufficient.

    By enabling the Audio DAC, MBSEQ would be unnecessarily (over)loaded by outputting the wavestream.
    There is also not enough RAM available for such a feature (the remaining RAM should be saved for future features)

    Best Regards, Thorsten.

     

  7. 3 hours ago, Zam said:

    That's interesting, what is the max possible clock speed ?

    Depends on the desired resolution for the duty cycle. The timers are clocked at 80 MHz
    Means: with 20 kHz we could have 4000 different "speed levels" (but actually I'm currently only using 64 speed levels, which is sufficient)

    3 hours ago, Antichambre said:

    Is it possible to do not pair the two devices and create a network with it? If a device can broadcast to several others devices and also receive(merge) from them too?
    Is there a kind of receiving state or meter, to be able to manage the distance between the devices?

    At least I know that MacOS and iOS don't allow this. If I take the device with one computer, it appears as "offline" on the other (and vice versa). Seems to be intended, that only a point-to-point connection is allowed.

    Yes, there should be some kind of meter available, here a link to the driver documentation: https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/bluetooth/

    Best Regards, Thorsten.

  8. Should be possible -> https://github.com/lathoub/Arduino-AppleMIDI-Library

    Good progress at my side: I'm now able to control motorfaders, and the accuracy is much better than ever before, because dedicated PWM outputs are used (which are normally intended to fade LEDs), clocked at non-audible 20kHz range.

    Some work is still required to get it compatible with MBHP_MF_NG, but maybe I can show the difference in 1..2 days via video.

    My test setup: a NodeMCU hooked on the MBHP_MF_NG board with a quick&dirty adapter board, communicating via Bluetooth (the MIDI sockets are currently not used - unfortunately ESP32 pins are not 5V tolerant)

    mbhp_mf_ng_with_esp32.thumb.jpeg.0a87382

    Best Regards, Thorsten.

  9. Could you please provide a link to the details?

    Here an example how text messages can be received and forwarded to a LCD:

    EVENT_RECEIVER id=  1 \
                   type=SysEx stream="0xf0 0x11 0x22 0x33 0x44 ^cursor ^txt"

    A more complex example (defining individual cursor positions) in the Logic Control Template:

    # LCD Messages
    # Note: we use ^txt56 instead of ^txt, so that the cursor will jump 
    #       to the next line after the 56th character has been reached
    #       Use map=1 to map the cursor positions over a 2x80 LCD
    EVENT_RECEIVER id=  5 \
                   type=SysEx stream="0xf0 0x00 0x00 0x66 ^dev 0x12 ^cursor ^txt56" \
                   range=map1
    
    # X cursor positions are defined in MAP1
    # spread message over two 2x40 LCDs
    MAP1   2  3  4  5  6  7  8 \
          12 13 14 15 16 17 18 \
          22 23 24 25 26 27 28 \
          32 33 34 35 36 37 38 \
          42 43 44 45 46 47 48 \
          52 53 54 55 56 57 58 \
          62 63 64 65 66 67 68 \
          72 73 74 75 76 77 78
    

    If this doesn't work for you, I might add an firmware enhancement - but in this case I need concrete information about the content of the SysEx string.

    Best Regards, Thorsten.

  10. No, I won't have the time for a fully adaption to MIOS32, especially considering incompatibilities, missing resources and last but not least, potential additional user support which I can't give thereafter.

    And concerning bootloader: the native solution of the ESP32 ecosystem is working well, no real need for an adaption.

    Therefore I provide the projects "as is" and independent from MIOS32 - but you will find some things known from MIOS32 later, and the projects will be somehow integrated into the MIDIbox platform - but please don't expect so much "flawless compatibility" that we know from MBHP_CORE_STM32/MBHP_CORE_LPC17/MBHP_CORE_STM32F4...

    Times have changed, today powerful DIY platforms are already available, so that it makes sense to adapt to the workflow of the corresponding users - I'm flexible and see the possibility to reduce efforts at my side ;-)

    Best Regards, Thorsten.

  11. Winter time is DIY time - and this year I decided to explore the capabilities of the ESP32 platform.

    There might be synergies with MIOS32, but I'm very sure that I won't fully integrate this Microcontroller into the MIOS32 ecosystem --- this hasn't been considered 10 years ago when I started with the 32bit platform, and it would take too much time to make everything compatible (with many compromises - e.g. no native USB support, and we know that this is important for best performance!)

    However, I think that ESP32 is a pretty good companion device to a STM32F4, hence potential candidate for future MIDIbox enhancements.

    E.g. the NodeMCU ESP32 available at Reichelt for 10 EUR supports Dual-Core (!) @240 MHz with WiFi and Bluetooth, 512k RAM, 4MB external Flash, incl. USB programmer on PCB - compare this with a PIC18F*! ;-)

    I started with Bluetooth, and the result can be found here: https://github.com/midibox/esp32-idf-blemidi

    This so called "BLE MIDI" service should work with any OS which supports this protocol. So far only tested on MacOS and iOS... but it should also work with Linux and Win10.

    This will be the basis for further experiments at my side - I'm able to communicate with the device via MIOS Studio. :-)

    (however, application download has to be done with the ESP32 ecosystem - means: the appr. esptool.py based bootloader)

    In future also a WiFi connections as demonstrated in Pedalino might be possible, but I'm not there yet - focus is on the application itself, knowing that the MIDI interface options won't be so fast like known from the STM32F4 based platform.

    E.g. how accurate can we control a Motorfader with the PWM LED outputs of a ESP32? :doubt:
    If it works, it could be connected like a MBHP_MF_NG module via traditional UART based MIDI to a MIDIbox NG.

    And will it be possible to control a SRIO chain?
    Might be interesting for a future BLM16x16+X with (only) optional WiFi and Bluetooth connects.

    Best Regards, Thorsten.

×
×
  • Create New...