Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. V4.089 has been released! From the ChangeLog:

    MIDIboxSEQ V4.089
    ~~~~~~~~~~~~~~~~~
    
       o added DIN testmode which can be enabled from the MIOS terminal with the
         "set din_testmode on" command to display button and encoder movements.
    
       o added "Roll Gate" as new optional trigger layer assignment.
         It gates the Roll or Roll2 value which is configured in a parameter layer.
    
       o Euclid Generator: parameter layer into which the pattern will be copied
         now selectable.
         Velocity/Accent will only be changed if the first parameter layer is selected.
    
       o it's now possible to quickly duplicate the steps of a track:
         press&hold COPY and press the PASTE button
    
       o Groove page: by default, groove configuration changes are applied on all tracks now.
         It's possible to select a "local groove" by pressing GP7 button in the groove page.
    
       o BPM page: it's now possible to configure an output delay for each MIDI port.
         (positive and negative delays are supported - this is currently an experimental feature!)
    
       o fixed NoteOff in Jam Forwarding mode if FTS, Limit or Humanizer is enabled
    
       o NOTE: due to a RAM capacity issue, the UNDO function is currently not available
         for the LPC17 firmware
    

    Best Regards, Thorsten.

  2. It took me around two days (ca. 15 hours) - at the first day I soldered 1N4148 diodes and LEDs, and at the second day the remaining parts. Over time I became faster with SMD soldering, but still ensured that parts are correctly aligned - especially for the LEDs it's important that they sit flat on the PCB, otherwise later they could illuminate in different directions so that you won't see a combined colour through the affected silicon pads later.
    Therefore the important hint: always solder only 1 pin (tacking), align the part, then solder the remaining pin(s), otherwise you can't fix the position anymore without desoldering the part! This way I tacked one row of LEDs, fixed the positions (when necessary), and then soldered the second pin. The same for any other part - it brings a little bit variety in the boring soldering process ;-)

    To the colours: In difference to Andys proposal I took blue as "colour 2" (right side of the bottom PCB) and green as "colour 1" for the left side, but this was my personal preference. Don't worry, the firmware allows to swap colors if you are unhappy with your initial decision! :)

    For the extra row/column and shift button I took red as "colour 1", and blue as "colour 2" again.

    Therefore (and I only write this as an important reminder for the case that somebody wants to do the same) I had to swap the resistor networks: 220 Ohm for the green/red LEDs (RN3, 7, 11, 15, 19) and 56 Ohm for the blue LEDs (RN4, 8, 12, 16, 20)

    Best Regards, Thorsten.

  3. In pre7 I added a bugfix for MAPs with duplicated values to cover Bartosz' use case; see also http://midibox.org/forums/topic/19535-encoder-and-maps-problem-bug and http://svnmios.midibox.org/comp.php?repname=svn.mios32&compare[]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2F%402174&compare[]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2F%402153

    Could you please give me a downstripped .NGC file (and/or .NGR in addition) which demonstrates your intention? It could be that due to the changes a new way has to be found.

    Best Regards, Thorsten.

  4. A new BLM has been born :grin:

    blm16x16+x_1.jpg

    blm16x16+x_2.jpg

    blm16x16+x_3.jpg

    Very nice to build, no big troubleshooting required if you are careful enough and don't forget a solder joint or create an unintended short.

    Andy deserves great respect for his sophisticated design, this is really professional work and sets a new DIY standard!
    Although the BLM16x16+X project is 5 years old meanwhile, you still can't buy a device with 290 buttons and duo-colour LEDs - you can only build it by yourself - and it has never been easier! :wink:

    Best Regards, Thorsten.

  5. question: is it possible with ram .ngr to write something to scale data in efficient way?

    like "if Ain=x send midi pitchbend=y" in one direction and "if pitchbend=y send Aout=x" in other direction

    should be 1024 (9bit) x2 (in and out) x 8 (pitchbend fader) =16384 line of code for my usecase...

    doable 

    no, IF/ELSE is the wrong approach for this purpose, and the RAM is limited to 16k ;-)

    But in future I could provide a special command which allows to scale during runtime based on an interpolated curve with n number of nodes. This would consume some additional execution time, but it should be fast enough on a STM32F4 - the memory consumption is then dramatically reduced.

    In general it's an advantage of the .NGR approach that special commands and mechanisms could be provided in future.
    Sooner or later I will clean-up the source code to simplify the integration of new commands (I've to improve it anyhow, because currently we've too much quick&dirty spaghetti code)

    Best Regards, Thorsten.

  6. To a) The Midi Keyboard is attached, running and the midibox also connected to MIOS studio. After the .NGC script is loaded, the assigned note on DOUT pin is low. But as soon as I hit the first key, using either the midi keyboard or the soft keyboard of the MIOS studio, the DOUT pin goes high and stays when I release the key. The only way to get it low again is to press the C-2 key (lowest in the scale) once. After that, the note on event acts as it should and only goes high as long as the key is pressed

    could you please determine with the "show id DOUT:1" command the values between the different states?
    I could imagine, that this is a side effect caused by the snapshot function

    To b) Except for the delay, this is what I wrote into the .NGR file. But for good measure, I copied your code and replaced mine to err out typers. The ^section == 0 gets executed (I checked with a "Hello World" to the LCD) but the show pool command in MIOS studio shows only zeros for all inputs. As soon as I move a pot, the actual value of this pot is shown if I do show pool again. I tried to switch the pot mode to direct instead of parallax but this does not change anything.

    Meanwhile I know the reason: after reset the MBNG firmware will wait for 2 seconds until controllers will be enabled. This is to ensure that SD Card content has been read, and voltages are settled.

    Could you please increase the delay to 2500 mS?

    if ^section == 0
      # wait until all values have been scanned (consider 2 seconds startup delay + a little bit margin)
      delay_ms 2500
      
      # now capture the AINSER values
      exec_meta RetrieveAinserValues
    endif

    Best Regards, Thorsten.

     

  7. Potential use cases which didn't work properly in the past, but should be possible now:

    Also this issue should be solved now: http://midibox.org/forums/topic/19477-problem-with-keys-and-runsection-command/

    Best Regards, Thorsten.

  8. Today I also noticed the case that the file won't be stored if the core generates a lot of MIDI traffic via the same USB channel.

    The connection wasn't failing though, but I think it's a problem with the communication scheme used by the file browser, it isn't robust against "foreign MIDI traffic".
    Needs some time to work this out!

    Best Regards, Thorsten.

  9. Hi,

    in the last months multiple users requested faster execution of .NGR run scripts to cover their use cases. The only way to achieve this is the execution from RAM, and in order to ensure that even the execution of long and complex scripts is possible, the NGR commands have to be compressed (resp. I call it "tokenized")

    In the last two days I developed a solution for this request - it was a nice programming challenge (although I hate the immense amount of required spaghetti code to cover all options - next time I will use a code generator... ;-)

    Typically scripts are now executed in much less than 1 mS, which means that it's finally possible to use them for timing critical operations!

    Only drawback: this feature is only supported for MBHP_CORE_STM32F4, because the other cores don't have enough RAM available - they are executing the script directly from SD Card like before.

    Here the current version:
    http://www.ucapps.de/mios32/midibox_ng_v1_033_pre14.zip

    It would be helpful if users could help me with the testing by running their existing .NGR files, and maybe also enhancing the files for realtime processing.
    Any feedback is welcome! :)

    Best Regards, Thorsten.

  10. Great that we finally solved this mysterious issue! :)

    a) always have a "note on" event staying on, when I hit a key on the midi keyboard attached for the first time after restart. It stays on until I hit the lowest note of the keyboard once. I already tried to set another dout pin to rule out an overflow of the DIO matrix scan pattern, but get the same effect.

    you mean, that you attach the keyboard during runtime, or is it already connected while the .NGC script is loaded?

    b) why my .NGR script always only writes 0s into the .NGS file during startup. I do have to slightly turn every single knob once to get the AINSER values and output them to the AOUTS. So I was not able to test the parallax mode yet. However, I haven't implemented a menue with a manual dump and load snapshot command.

    You've to capture the AINSER values once they have been scanned.

    This can be done from the .NGR file:

    if ^section == 0
      # wait until all values have been scanned (should be after >= 50 mS)
      delay_ms 50
      
      # now capture the AINSER values
      exec_meta RetrieveAinserValues
    endif
    

    Best Regards, Thorsten. 

  11. Thanks! For me it's clear now (although it's still a hypothesis - I haven't doublechecked yet - but I'm very sure ;-):
    it seems to be related to a software bug indeed!

    EVENT_AINSER forwards the value to CV; the AINSER event has some custom flags:

      struct {
        u16 ain_mode:4; // mbng_event_ain_mode_t
        u16 ain_sensor_mode:4;  // mbng_event_ain_sensor_mode_t
      } AINSER;

    and CV has some custom flags as well - they will be shared with the same variable:

      struct {
        u16 fwd_gate_to_dout_pin:9;
        u16 cv_inverted:1;
        u16 cv_hz_v:1;
        u16 cv_gate_inverted:1;
      } CV;

    You are using a special ain_mode in your configuration: parallax.

    The corresponding value for this mode is 4

    From MBNG_CV_NotifyReceivedValue():

          if( item->custom_flags.CV.fwd_gate_to_dout_pin ) {
            if( debug_verbose_level >= DEBUG_VERBOSE_LEVEL_INFO ) {
              DEBUG_MSG("-> Setting DOUT Pin #%d=%d\n", item->custom_flags.CV.fwd_gate_to_dout_pin-1, gate_value);
            }       
            MIOS32_DOUT_PinSet(item->custom_flags.CV.fwd_gate_to_dout_pin-1, gate_value);
          }

    Which means: custom_flags.AINSER.ain_mode=4 will turn into custom_flags.CV.fwd_gate_to_dout_pin
    And therefore MBNG_CV_NotifyReceivedValue() could set DOUT pin 1.D3 to 0 under certain cirumstances (value=0), with the result that the row selection pattern will be influenced!

    Now I've to find a way how to handle the shared custom_flags for the case that values are forwarded.
    Currently I think that it's safe to clear the flags before forwarding under the assumption, that the receiver will handle them as "passive".

    Could you please check this "blind" (untested) change?
    -> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre12.zip

    Best Regards, Thorsten.

  12. Ok, we are coming closer to the root cause! :)

    Next tests with AOUT and AINSER enabled

    1) remove the fwd_id=CV:x statements from EVENT_AINSER - problem still occurs?

    2) remove the fwd_id=LED:x statements from EVENT_BUTTON - problem still occurs?

    Best Regards, Thorsten.

  13. Hi Andy,

    meanwhile I've an idea under which conditions this behaviour could be observed (although I've no idea how this could happen with your configuration): if a LED (DOUT) function overwrites the pins at DOUT #1, D7..D0, the matrix row selection pattern would be falsified so that a single row could trigger multiple button events, and turn on multiple LEDs of the same row.

    In order to check if this hypothesis is the reason for the problems, I added a new debug command "show douts", which should output:

    [351689.954] Page  0: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.954] Page  1: bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.954] Page  2: df 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.956] Page  3: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.956] Page  4: f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.958] Page  5: fb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.958] Page  6: fd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.960] Page  7: fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.960] Page  8: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.961] Page  9: bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.962] Page 10: df 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.963] Page 11: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.964] Page 12: f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.965] Page 13: fb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.965] Page 14: fd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.966] Page 15: fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.967] Page 16: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.968] Page 17: bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.969] Page 18: df 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.970] Page 19: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.971] Page 20: f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.972] Page 21: fb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.972] Page 22: fd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.973] Page 23: fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.974] Page 24: 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.975] Page 25: bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.976] Page 26: df 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.977] Page 27: ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.978] Page 28: f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.979] Page 29: fb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.979] Page 30: fd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [351689.981] Page 31: fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    

    So, we've 32 pages which are cycled with each SRIO update, and the first column (which corresponds to a matrix row) shows the output pattern of the SRIO cycle.

    We should see 8 times the sequence 7f bf df ef f7 fb fd fe (which is nothing else than a running-zero, here the binary representation: 01111111 10111111 11011111 11101111 11110111 11111011 11111101 11111110)

    Could you please run following firmware version:
    http://www.ucapps.de/mios32/midibox_ng_v1_033_pre11.zip

    Wait until random events are triggered, and then enter the "show douts" command.
    Check if you see four times the value sequence that I explained above, if you notice a different value please let me know
    (Note that MIOS terminal output can be copy&pasted, just select multiple lines and right-click on the lines)

     

    Additional experiment (now considering more the HW side): 

    What happens if you disable the AINSER (configuration) command, what happens when you disable the AOUT (configuration) command, what happens when you disable both?

    And last but not least: do you have a .NGR file, and what is the content?

    Best Regards, Thorsten.

     

×
×
  • Create New...