Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. Such features are currently not provided.

    The big question: is the usage of variables really the right approach? What if you want to control both synths from a single control surface?

    Or would it be better to provide new .NGR commands which allow to change the channel and port assignment for each event?

    Best Regards, Thorsten,

  2. Hi Andy,

    some notes: the file structure can be determined by reading the code in MBNG_FILE_S_Write http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fsrc%2Fmbng_file_s.c

    The file header stores the file positions of the 128 possible snapshots

    And the snapshot sections store

    • the event id
    • the event value
    • the "secondary" event value

    for each event

    The snapshot feature can only work correctly if:

    • no new events are added anymore
    • event ids are not changed

    So - whenever you are adding events or changing the purpose of event ids, the .NGS file has to be removed, and it has to be created again (unfortunately... there is no automatic "migration" available yet)

    If this isn't the problem, a debugging hint: enter "set debug on" in MIOS terminal and check the messages while a snapshot is loaded

    Best Regards, Thorsten.

     

  3. The load command is supported now! :)

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

    On 22.12.2016 at 7:07 PM, FantomXR said:

    But I have another question: I have some LED-rings here and I'd like to use one of these LEDs as status-LED for the switch of the encoder. I configured the encoder like this:

    Problem understood - but MBNG currently doesn't allow to remove a LED from the pattern.
    There is currently no solution/workaround for this use case

    On 28.12.2016 at 3:01 PM, FantomXR said:

    I have a question regarding banks:
    I have my workstation set up with different banks (see the other thread Story of keyboard build). The idea was, to assign the banks to different controllers in my live-host on my computer. So f.e. the first bank controls the volumes, the second bank controls the drawbars, etc.
    Now it's the case, that every patch in my live-host contains different settings for drawbars and volumes of course and when I select this patch all these values are send out by the live-host to the MIDIbox. The "problem" is that the MIDIbox only listens to that bank, that is selected and the other banks do not change their values. Is there a workaround for that so that the MIDIbox listens on all banks for value-changes?

    The event will take over the value, regardless if it's defined in the selected bank or not (otherwise this feature wouldn't make much sense... ;-)

    Are you using the set_lock command in your .NGR script?
    This command would allow to lock the value so that it can't be overwritten from an incoming MIDI message.

    Best Regards, Thorsten.

     

  4. On 26.12.2016 at 9:51 PM, y2k_kushaal said:

    heys guys can I select MORE THAN 8 channels with this module? like banks ? if yes then how to select it? program it?

    No -- MBHP_MF_NG is only intended as a "slave device", either for a DAW, or for MIDIbox NG (which allows you to define banks, allows to assign any kind of MIDI event - including SysEx, allows to store/restore snapshots, etc)

    Best Regards, Thorsten.

  5. Hi,

    just to make it clear: not so much will change, I will continue the support and development like in the last 2..3 years, means: with ca. 20 days per year.
    But I will focus this instead of introducing new MIDIbox projects or forking existing HW/SW projects by myself.

    The license might also be more relaxed in future, but this will be announced in a separate thread in some days (please no discussion in this thread, it's too early)

    I continued the discussion about a new MBSEQ frontpanel with Andy today, be prepared for a great new solution - no, there won't be an integrated BLM4x16, but the frontpanel will look fresh and useful :) 

    Best Regards, Thorsten.

  6. Hi Chris,

    from the source code:

              DEBUG_MSG("[MBNG_FILE_R:%d] ERROR: the LOAD command is not supported anymore!", line); // let's see if somebody really needs this...

    It will be difficult to provide a solution because of conceptial changes, how the NGR script is parsed and executed.
    There is no replacement
    So - it can take some time until a solution will be available again

    Best Regards, Thorsten.

  7. Works at my side, tested with:

    EVENT_KB id=1  type=NoteOn chn=1 key=any use_key_number=1 range=0:127  lcd_pos=1:1:1 label="Note %n" kb_transpose=0 ports=00000100000000000000
    Quote

    Instead, I always have KB output on USB1 as monitored by MIOS Studio, as well as on MIDI out 1.

    any error message during the upload of the .NGC file?

    Quote

    These are my router settings:

    shows that all src_chn and dst_chn are disabled: no routing takes place

    Is this relevant for the test?

    Best Regards, Thorsten.

  8. Before providing this option on a comfortable way (eg. via bootloader for all apps), it would be nice if you could configure and rebuilt the applications by yourself.

    The configuration has to be done in mios32_config.h, e.g. add following #define statements to set all MIDI interfaces to 312.5k baud:

    #define MIOS32_UART0_BAUDRATE 312500
    #define MIOS32_UART1_BAUDRATE 312500
    #define MIOS32_UART2_BAUDRATE 312500
    #define MIOS32_UART3_BAUDRATE 312500

    And if you have some time, it would be interesting to know at which baudrate MIDI transfers become instable.
    Up to 10 MBit are supported; this won't work through an optocoupler anymore, but should work with a direct eletrical connection.

    With higher speeds the RX buffer has to be increased, otherwise we run into potential data loss issues.

    By default, 64 bytes are allocated for each MIDI IN, which can bridge ca. 20 mS at normal baudrate, and ca. 2 mS at 10x faster baudrate (as proposed above) - should still be enough for a common MIOS application.

    But for the case that you notice data loss, try higher values. Max. supported size is 255 bytes (and not 256 as somebody could assume)

    #define MIOS32_UART_RX_BUFFER_SIZE 255
    Quote

    My use case (moving fader) will be to have up to 4 core connected to a master which can handle routing from MIDI to USB (or RTPM) to have a single USB (or ethernet) cable to run 4 MCU/HUI instance (like 4 MF_NG hooked to one core). All core running NG.

    You've to try out if the higher MIDI rate improves the overall performance, and you've to find the sweet spot.
    With higher speeds also the performance of your computer, operating system and DAW become relevant.

    I'm very interested on reports before providing this as a general configuration option for "common users".

    Best Regards, Thorsten.

  9. Hi Chris,

    there is no alternative solution for the physical connection, but if speed does matter: I could easily provide an option to increase the baudrate.

    E.g. 10 times faster, which would mean that MIDI events are sent within 100 uS instead of 1 mS

    Best Regards, Thorsten.

  10. No changes are required for the hardware, but there are software optimizations which might require a better hardware setup, such as buffer ICs for the LCD control signals which are shared between multiple displays.

    Major optimizations in universal/app_lcd.c:

    • APP_LCD_ExtPort_SerDataShift: add more "stretch" operations to slow down the serial clock
    • APP_LCD_ExtPort_UpdateSRs: strobes J28.WS, you could duplicate APP_LCD_ExtPort_PinSet(2, 0) to stretch the pulse
    • APP_LCD_Data: uses APP_LCD_PollUnbusy(2500), was APP_LCD_PollUnbusy(10000) before - maybe a timeout happens with this low cycle number?

    If software modifications are not successful, please give more details about your hardware setup. This could bring up ideas for improvements.

    Best Regards, Thorsten.

  11. It's implemented now, please try it out - works fine at my side! :)

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

       o new track mode configuration option: "STrg" (Step Trigger)
         In this mode, the step progression will be controlled from the transposer
         bus, hence it can either be triggered from a loopback track or from an 
         external MIDI device (MIDI keyboard, sequencer, etc.)
         Note that each track can be assigned to a dedicated transpose bus
         (4 busses are available), this allows to control 4 independent step progressions
         for all 16 tracks.
    

    Best Regards, Thorsten.

  12. Hi,

    I'm glad that you like the device! :)

    It's possible to configure the MIDI notes which are sent by the drum instruments: enter the MENU->Event page, select the drum instrument with encoder #11, and change the note with encoder #12.

    E.g. the first instrument (BD) will output C-1 by default, which is in the 4th octave. Lower octaves are C-0, c-1 and c-2, whereas c-2 can't be played because it's note number 0 (interpreted as "no note" by MBSEQ)

     Best Regards, Thorsten.

  13. 12 hours ago, latigid on said:

    Well, we could consider an encoder that scans through and illuminates the 4th row ;-) 

    The same way how the MB808 UI is working.
    Please believe me, the encoder usage for track selection wasn't a good idea, I wouldn't do this again...

    Quote

    these buttons are essentially the four track groups, no?

    No, the BLM buttons have to switch between BLM sections, and the purpose of a section depends on the BLM mode.
    If BLM displays the gates of a track, the BLM buttons would switch between track groups.
    If BLM displays a drum grid, the BLM buttons would switch between trigger layer (resp. drum instrument) sections
    etc...

    Quote

    If tracks were handled on an encoder, then in BLM mode an encoder could scroll through the groups, even using lower resolution if too waggly.

    You could use the jogwheel for this purpose.
    The function of the datawheel is already configurable, press&hold EDIT, push GP7 to switch between the functions.
    Additional functions could be assigned to the jogwheel in future.

    Quote

    Can we think about modes a bit more? At the moment, GP buttons are used to trigger steps on the selected layer of a track. Will this be retained, or are triggers only actioned in BLM mode? If the latter, then this allows the menus to be accessed without pressing MENU first. 

    You are right, that this topic needs more planning.

    Some functions that I "brainstormed" yesterday might be redundant, such as the mute button that you pointed out.

    Trigger steps are selectable in BLM drum grid mode - again a conflict with your "TPM", an additional handling could lead to too much confusion.

    I would prefer the following approach:

    - show different layout options (how many buttons could be added to the jogwheel section)
    - then we've to start to write a specification for button assignments and usage, this could be done in the Wiki

    The only way to get a "big picture" and to work out the details to find the best layout.

    Best Regards, Thorsten.

  14. 2 minutes ago, latigid on said:

    There is still space to the left of each 8*4 section -- my thought was to include pads for three (or maybe four) encoders/buttons, and make the PCBs roughly the same dimensions as LCDs/OLEDs. I would recommend only the left-most encoders be installed, in order not to have height conflicts in the middle. Then, as the original idea started, tracks, parameter layers and trigger layers would be accessed via encoders. Wouldn't the handling be better than a multi-mode 4th row?

    No, encoder are worse than buttons.

    Buttons can be operated almost "blindly", encoders require visual focus to the display and could sometimes select an unintended track if not operated careful enough.

    I noticed this on the MB808 frontpanel - no fun!

    Quote

    Wouldn't the handling be better than a multi-mode 4th row? Plus, it frees the 4th row buttons for currently unused or future functions. 

    I would prefer to select tracks, mutes, parameter and trigger layers with the 4th row

    By providing another button to select the bookmark (BM) function the user could store and restore any kind of other function (see documentation, bookmarks are very powerful, since they not only allow to switch to pages, but also to select tracks, mutes, etc...)

    Quote

    The "track encoder" would shift the "track group" in BLM mode -- I believe that's how it works for the current 16*4 BLM.

    Too waggly usage, not useful in live situations!

    Quote

    Buttons, or even a "data encoder" if the jog/shuttle isn't included, could then be put in the middle, or on the outside. In fact, the "jog/shuttle carrier" could be placed where it suits -- in the middle, on the side, or left out. But it was certainly my idea to include more buttons on this PCB. :) I will try to make the HW as flexible as possible, but it's very important to hear implementation ideas.

    For me such a big jogwheel in the middle doesn't look nice.

    Better to place it at the right lower corner, and some buttons below.
    Probably you've to provide an alternative frontpanel for lefthanded users

    Quote

    One thing I like about the current setup is it constrains track selection to one part of the interface. Using the GP buttons or 4th row is a nice implementation and very logical with 16 parameters, but makes one search across the whole interface for the correct track.

    Buttons should be labeled... by giving generic labels 1/A, 2/B, 3/C, ... users will quickly learn the position and sooner or later operate without focusing the labels anymore...

    Best Regards, Thorsten.

  15. You are right, this is a documentation error: we are counting from left (USB1 is the leftmost digit)
    Meanwhile corrected at my website

    To the actual issue: are you sure that the MIDI output is working at all?

    You could test it with following terminal command:

    ngr send CC OUT1 1 1 127

    This should send CC#1 with value 127 over channel 1

    Doublecheck with:

    ngr send CC USB1 1 1 127

    to ensure that the command itself is working...

    Best Regards, Thorsten.

     

  16. Hi Chris,

    I confirm that this can be confusing: encoders define a default matrix pattern, other events won't, hence no pattern is displayed.

    If you add "led_matrix_pattern=1" to EVENT_AINSER it will work

    With the next version all events will get this default assignment

    Best Regards, Thorsten.

×
×
  • Create New...