TK.

Yes, that's exactly the purpose of the root note :) You are now able to transpose from the track layer w/o the usage of an additional loopback track. Best Regards, Thorsten.

Hi, thanks for pointing this out! The table was correct, the schematic wrong. It's corrected now: http://www.ucapps.de/midibox_seq/mbseq_v4_dio_wilba_layout.pdf Best Regards, Thorsten.

The enhancements of the last months are now officially available (and documented): MIDIboxSEQ V4.092 ~~~~~~~~~~~~~~~~~ o new parameter layers for track specific root note and scale Root selection strategy: if Root is assigned to any parameter layer of a track, the layer can either select the global root selection ("Glb") or set the root note for each step explicitely. The global root selection is configured in the FX->Scale page, it's either "Keyb" (for MIDI keyboard entry) or C, C#, ... B The local root selection is C, C#, ... B Notes and Chords will be transposed accordingly if the track is in Normal mode (and not in Transpose or Arpeggiator mode) Similar for Scale: it can override the globally configured scale of the FX->Scale page for each step. o new drum configurations: 4*16/2*64, 4*16/2*128, 4*16/1*256 o new configuration option in Track Mode page: "Note Last/First" Allows to specify, if the transposer should take the last or first played note (previously it always played the last note) o new configuration option in Track Mode page: "STrg" (Step Trigger). If activated, 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. o individual steps of CC, PitchBender, Program Change and Aftertouch layers can now be disabled so that they won't play. Turn the encoder to the rightmost position (value 128) Also the init value has been changed: for these layers, the steps are now disabled by default. For CCs please change the init value by yourself in the UTIL->OPT page (option #12: Initial CC value) o new behaviour of CLEAR button in recording mode: it clears only the selected step (instead of the entire pattern). During live recording it will clear the "played" steps while the button is pressed. o new CC functions which can be configured in MIDI->ExtCtrl. page: o Play/Stop: allows to assign the PLAY button to a CC o Record: allows to assign the RECORD button to a CC o new option in Groove page: Sync Allows to sync the groove to the global reference step (RefS) or to the local track step o fixed G# transpose Best Regards, Thorsten.

See core/seq_chord.c: up to 6 notes, up to 6 chars. In the step display I will print the first 4 chars, this should be considered while naming the chords. Yes, just provide the table in C format so that I can directly take over w/o translation Best Regards, Thorsten.

That's exactly the intention: the work flow will be a bit different (hopefully more ergonomic), but I don't plan to add a new function which won't be accessible with the old frontpanel. Duo-LEDs won't be required, but if available, different colours will allow to show a bit more information. E.g. Step View: loop range could be highlighted. Track/Layers/Instruments: second LED could show muted parts Bookmarks: second LED could show already allocated bookmarks Mute will show muted and soloed tracks (*) (*) a track solo function is currently not available - if I add this feature, it will rely on a second colour, otherwise the handling will be too confusing if a certain track doesn't play and you don't know, if it's because of a mute, or because other track(s) is/are soloed. Best Regards, Thorsten.

I think that the new "selection button row" consisting of 16 buttons and duo-colour LEDs will be a big + :) The 8 buttons around the datawheel allow to assign a function to this row. The functions are: Step View Tracks Parameter Layer Trigger Layer (Drum) Instrument Track Mute (and evtl. Track Solo) Bookmark Song Phrase Especially for the first 5 functions will improve manual editing flow, having all 16 views/tracks/layers/instruments selectable in a dedicated button row should speed up switching. Here another picture which shows the function assignments to the new buttons: Feedback welcome! Best Regards, Thorsten.

yes

Such a configuration doesn't fit to the intended use case. Actually only a single bank is supported, and it's intended that all display elements have either an assigned EVENT for this bank, or that they are not assigned to any bank. Best Regards, Thorsten.

I checked this with LRE2x8 - the LED rings will be updated Or do you mean LED rings, which are assigned to various banks, but not to the selected bank? Then I guess that they won't show the updated value until the assigned bank will be selected. Best Regards, Thorsten.

Yes, since today this is possible again: Note that this will change the entire session, not only the .NGC file Which means that you've to duplicate the .NGR script Best Regards, Thorsten.

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,

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.

Just have a look into various .c files under mios32/STM32F4/ which configure IO pins. And then compare with the files under mios32/STM32F1/ Best Regards, Thorsten.

The load command is supported now! :) -> http://www.ucapps.de/mios32/midibox_ng_v1_036_pre3.zip 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 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.

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.

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.

Similar problem. But while thinking about possible solutions I got an idea, will come back to this tomorrow. Best Regards, Thorsten.

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.

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 any error message during the upload of the .NGC file? shows that all src_chn and dst_chn are disabled: no routing takes place Is this relevant for the test? Best Regards, Thorsten.

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 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.

We continue here:

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.

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.

Hi, I think that I found the problem, could you please try this version? -> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre9.zip Best Regards, Thorsten.