Jump to content

TK.

Administrators
 View Profile  See their activity

  • Posts

    15,205

  • Joined

 Content Type 

Posts posted by TK.

  2. understanding the .ngc code

    in MIDIbox NG

    Posted

    Hi,

    finally found time to go through this thread... ;-)

    First of all: the SysEx string contains an "illegal" value: 0xE0
    Values >= 80 should not be sent, because they will be interpreted as a new MIDI status.

    Second: you could simply toggle between the two values 0x10 and 0x01, and insert it into the SysEx string via ^val: 

    EVENT_BUTTON id=1 range=0x10:0x01 button_mode=toggle type=SysEx stream="0xf0 0x00 0x01 0x16 0x10 0x18 ^val 0xf7"

    Best Regards, Thorsten. 

  3. MIDIbox SEQ V4 Release + Feedback

    in MIDIbox SEQ

    Posted

    @lp1977thanks for the information! Problems are understood and fixed in:

    http://www.ucapps.de/mios32/midibox_seq_v4_096_pre8.zip

    @sis.tmjust tried at my side, it works!
    (and sometimes I'm surprised what can be done without special consideration in the sources ;-)

    • assign track to CV
    • in LFO page, set the ExtraCC# to 16..23
      16 will send to CV channel #1, 17 to channel #2, etc - which means: with the CC number you can address the CV channel you would like to use as LFO output

    Best Regards, Thorsten.

  6. midiphy SEQ v4+

    in MIDIbox SEQ

    Posted

    On 21.10.2019 at 6:33 AM, studio nebula said:

    If the LEDs were driven directly by the 74HC595 shift register, whose outputs are very close to the supply voltage, then the current through the LED would be (5 - 2)V / 47ohms = 63.8mA. This is higher than the 50mA maximum current stated on the data sheet for the red LED, and much higher than the 20mA typical current used for most of the LED's specifications. The same is true of the current through the green and blue LEDs, although the difference is not as dramatic: 34mA calculated current vs. the 30mA maximum stated on the sheet.

    This isn't correct, see also the SN74HC595DR datasheet: http://www.ti.com/lit/ds/symlink/sn74hc595.pdf

    Output drive current is 6 mA, which means in other words: you've to add an internal resistance of ca. 800 Ohm to the calculation.

    This could be doublechecked by clamping an output to ground, and measuring the current draw while the pin is set to logic-1.

    Best Regards, Thorsten.

  7. midiphy Eurorack Expander Modules

    in MIDIbox SEQ

    Posted

    That's the reason why I haven't listed J10A/B in my requirements list - it's just important to have a standard control surface (SCS), otherwise applications won't be re-usable.

    The 6 buttons + encoder could also be connected to an on-board DIN SR, connected to J9 as the first SR in the chain.

    Would be happy to evaluate it.

    Best Regards, Thorsten.

     

  9. midiphy Eurorack Expander Modules

    in MIDIbox SEQ

    Posted

    Must-have requirements:

    • STM32F407VG (1MB flash)
    • SCS with 6 buttons, 1 encoder and 1 GLCD (so that we can also use the display as a scope)
    • 1 MIDI IN, 1 MIDI OUT
    • USB Device
    • SD Card
    • SRIO (J8/9)
    • J19 for AOUT
    • 50mm depth
    • HP doesn't matter as long as it still fits into the Pod40X case together with the Expander modules

    Optional:

    • up to 3 additional MIDI IN/OUT (could also be provided as an optional module)
    • USB Host
    • 4 on-board LEDs
    • Audio-DAC

    Potential extension modules:

    • SRIO based encoder/ledring modules
    • AINSER64 module (with at least 8, but maybe 3x8 INs?) - inputs should be buffered, protected and maybe also amplified and level-shifted for +/- 5V

    Such a module could also cover MBNG for script based processing.

    Best Regards, Thorsten.

  11. midiphy Eurorack Expander Modules

    in MIDIbox SEQ

    Posted

    A downstripped MBHP_CORE_STM32F4 module in Eurorack format would be nice-to-have as an alternative solution to the Euroreceiver - maybe with a SCS (6 buttons, encoder, display) - this would allow to run MBCV which gives us a lot of LFOs, Envelopes, sequencers, modulation matrices, etc.

    Best Regards, Thorsten. 

  16. Please help me to understand how the NG app works internally

    in MIDIbox NG

    Posted

    As mentioned by Christian, there was no special reason why assigned DIN and DOUT SR #9 to the DIO function.

    I thought this might be better in case you would like to add more physical SRs in future, no need to change the IDs again until you reach #9. If you don't like this, you could also use SR #3, but not SR #1 or SR #2, because these positions are already allocated by the scan matrix.

    Btw.: the most simple way to find out the hw_ids is to enter "set debug on" in the MIOS terminal, then trigger the buttons and observe the debug messages in the terminal (doesn't work with LEDs of course, but if you know the button position, you can easily conclude on the LED position)

    Best Regards, Thorsten. 

  18. Please help me to understand how the NG app works internally

    in MIDIbox NG

    Posted

    Yes, there is a conflict with the shift register assignments.

    Try this one: 

    # now enable DIOs (0 = input / 1 = output)
DIO  port=J5AB  emu_din_sr=9  emu_dout_sr=9  output_mask=01010000

# button events (DIN SR1 pins are assigned to hw_id=65/67)
EVENT_BUTTON id=65  hw_id=65 type=CC chn=1 cc=16 range=0:127  fwd_id=LED:66
EVENT_BUTTON id=67  hw_id=67 type=CC chn=1 cc=17 range=0:127  fwd_id=LED:68
#EVENT_BUTTON id=65  hw_id=65 type=Meta  meta=RunSection:1  button_mode=OnOnly
#EVENT_BUTTON id=67  hw_id=67 type=Meta  meta=RunSection:2  button_mode=OnOnly

# LED events (DOUT SR1 pins are assigned to hw_id=66/68)
EVENT_LED    id=66  hw_id=66 type=CC chn=1 cc=16 range=0:127
EVENT_LED    id=68  hw_id=68 type=CC chn=1 cc=17 range=0:127

    Best Regards, Thorsten.

  20. Please help me to understand how the NG app works internally

    in MIDIbox NG

    Posted

    No, don't worry, outputs are protected against shorts internally.

    Just tried your configuration, it works after changing fwd_id=LED:3 to fwd_id=LED:2 (we always forward to a hw_id) 

    RESET_HW

# J5A PORT SETUP
# J5.A0 -> octave up switch
# J5.A1 -> octave up LED
# J5.A2 -> octave down switch
# J5.A3 -> octave down LED

# now enable DIOs (0 = input / 1 = output)
DIO  port=J5AB  emu_din_sr=1  emu_dout_sr=1  output_mask=01010000

# button events (DIN SR1 pins are assigned to hw_id=1/3)
EVENT_BUTTON id=1  hw_id=1  type=CC chn=1 cc=16 range=0:127  fwd_id=LED:2
EVENT_BUTTON id=2  hw_id=3  type=CC chn=1 cc=17 range=0:127  fwd_id=LED:4

# LED events (DOUT SR1 pins are assigned to hw_id=2/4)
EVENT_LED    id=3  hw_id=2  type=CC chn=1 cc=16 range=0:127
EVENT_LED    id=4  hw_id=4  type=CC chn=1 cc=17 range=0:127

    As you can see, I also added "RESET_HW" to ensure that previous settings are undone.

    The LEDs shouldn't be dimmed.

    Best Regards, Thorsten.

  22. MIDIbox SEQ V4 Release + Feedback

    in MIDIbox SEQ

    Posted

    Based on my experiences with MB808 the trigger width is crucial, therefore I can fully understand Andrews request that a digital option is desired.

    The "pipeline based approach" is working fine, we can now adjust the width from 0 (=off -> gate function) to 10 mS 

       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

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

    It would be great if everybody could help to test this new firmware version, regardless if the new CV features are used or not (I hope that nothing else is broken!)

    I would like to create a final v4_096 release, because v4_095 is from last december, and it started to smell! ;-)

    Best Regards, Thorsten.

  24. Please help me to understand how the NG app works internally

    in MIDIbox NG

    Posted

    New version can now be found here: http://www.ucapps.de/mios32/midibox_ng_v1_037_pre4.zip

    It's now possible to mix input and outputs on a single port as shown in this example: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/diocfg_3.ngc

    And J5 is supported as well (called J5AB) - it's even possible to mix digital with analog functions -> https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/diocfg_4.ngc

    In your case, please keep the analog pins disabled

    Best Regards, Thorsten.

  25. MIDIbox SEQ V4 Release + Feedback

    in MIDIbox SEQ

    Posted

    4 minutes ago, latigid on said:

    Wow, amazing! Are the CVs distributed out on J19, so the same RC1 channel or is RC2 used as well to double the transfer rate? What is the maximum data rate?

    The data update rate is only 35 uS for all 4 modules, so no need to make it more complicated :)
    That's also the reason why I enabled all 32 channels by default, it doesn't make a big difference.
    Using a second CS line wouldn't help, because SPI transfer time would have to be consumed anyhow.
     

    Quote

    Is there a functional way to use all 32 CVs with only 16 tracks? Polyphonic tracks?

    With channel 9-13 you can route note and velocity value to two CV outs - in this case you need all 32 outputs.
    But you can also route CCs of a track to the CV outs (starting at CC#16 as far as I remember...)

    Quote

    Is it possible to set (or preset) the drum trigger length to something longer? This is already available for the clocks but I couldn't see an easy way to do it for triggers.

    Actually I looked into this, but there is a technical problem.
    The 64 drum triggers are currently cleared with each SRIO update cycle, this was very pragmatic and effective and especially doesn't consume resources (counters) and CPU time (processing the counters)

    For individual delays I would have to implement counters for each trigger, and this is very costly.

    And for a single delay we would potentially run into the problem, that each mS a new trigger could reset the counter, leading to "stretched signals" for all triggers for which the configured time already passed...

    Best Regards, Thorsten.

×
×
  • Create New...