TK.

inverting != mirroring You have to create your own LED_MATRIX_PATTERNs for 15 instead of 11 (or in the lre8x2 setup: 16) LEDs. Best Regards, Thorsten.

Related to this topic: Here a hint: with following perl script: while( <STDIN> ) { if( /^\s*#\s*NGL:\s*(.*)/ ) { print "$1\n"; } } you could simply *extract* NGL commands from a .NGC file. Example: # this is a .NGC file # we've some EVENT definitions here EVENT_xxx ... # and following commands should go into the .NGL file: # NGL: COND_LABEL octave # NGL: COND <28 "128'" # NGL: COND <40 " 64'" # NGL: COND <52 " 32'" # NGL: COND <64 " 16'" # NGL: COND <76 " 8'" # NGL: COND <88 " 4'" # NGL: COND <100 " 2'" # NGL: COND <112 " 1'" # NGL: COND <124 "1/2'" # NGL: COND_ELSE "???'" call: perl my_ngl_filter.pl < test.ngc > test.ngl and you are done! :smile: -> COND_LABEL octave COND <28 "128'" COND <40 " 64'" COND <52 " 32'" COND <64 " 16'" COND <76 " 8'" COND <88 " 4'" COND <100 " 2'" COND <112 " 1'" COND <124 "1/2'" COND_ELSE "???'" Best Regards, Thorsten.

Yes, especially because it would allow you to stream the output into different files. This would solve such a topic: Means: a single script could write into a .NGC, .NGL and even into a .NGR file. Best Regards, Thorsten.

Fine! :) Best Regards, Thorsten.

Sounds like an inverted selection. Are you using ULN2803 as sink drivers? Then you would have to use following configuration: DOUT_MATRIX n= 1 rows=8 inverted_sel=1 sr_dout_sel1= 7 sr_dout_sel2= 0 sr_dout_r1= 8 sr_dout_r2= 9 Or you are not using an ULN2803, but the polarity of the LEDs is wrong? Then try: DOUT_MATRIX n= 1 rows=8 inverted_sel=1 inverted_row=1 sr_dout_sel1= 7 sr_dout_sel2= 0 sr_dout_r1= 8 sr_dout_r2= 9 Best Regards, Thorsten.

In perl you could also work without printf E.g. if you would like to add some freetext, just write: print <<HERE # this section # will be print # out directly # e.g. you could write some EVENT_FOO ... EVENT_BAR ... # until here HERE; Inside such a section you could even insert variables (starting with $<name>) You wouldn't be able to do calculations inside such a section, but you could write: for($i=0; $i<16; ++$i) { my $id = $i + 1; my $key = $i + 36; print <<HERE EVENT_FOO id=$id type=NoteOn chn=1 key=$key HERE; } Best Regards, Thorsten.

No, too difficult due to various reasons. Best Regards, Thorsten.

I don't think that this is a better approach. You would have to latch a position with the ALL button, which means that in certain usecases you would have to turn off/on ALL multiple times which doesn't make the UI more efficient. We would also need a new marker which signals the latched position... However: Did you know, that you can change the purpose of the datawheel? Press SELECT, then move GP9 to select the datawheel function. With "StepView" you can use the datawheel to change the view instead of the cursor. And now read your proposal: Exactly this handling is possible when the Datawheel changes the StepView ;-) Best Regards, Thorsten.

I'm surprised that M4 still exists - I used it ca. 10 years ago for a selfwritten assembler (@work) to get the possibility for writing macros without enhancing the parser. I agree that it's useful. On the other hand: if you already go for special languages, why not writing a code generator in a high level language? This is industrial standard since several years. Here a simple example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmax72xx.ngc (the used perl script is embedded into comments) Best Regards, Thorsten.

Could this be related to the ADSR bug of the SID chip? What happens, if VCA Attack, Decay and Release are set to 0? (only Sustain should be > 0) - does it work properly with this setup? Best Regards, Thorsten.

Thanks for your feedback! :smile: The datawheel issue should be fixed now: http://www.ucapps.de/mios32/midibox_seq_v4_074_pre2.zip Best Regards, Thorsten.

This is on my TODO list... However, meanwhile something else for you: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmax72xx.ngc Please try it with this pre-release: http://www.ucapps.de/mios32/midibox_ng_v1_025_pre3.zip Best Regards, Thorsten.

I find this too cumbersome. With the current solution you are faster: move the starting point with the datawheel, move an encoder to define the end point and to set the ramp. Is this really worse than your proposed handling? With the current solution you can set a ramp over multiple step views, just try it! :smile: Keep in mind, that the step view can be quickly changed with the Fwd/Rwd buttons meanwhile. Best Regards, Thorsten.

Yes, this is for example how CC tracks are handled by MBSEQ V4 Lite: the first three tracks are used for (polyphonic) notes with the common 16th notes resolution, and the remaining tracks for PitchBender and CCs at 64th resolution (divider set to 4). This would lead to many inconsistencies which I don't like (e.g. special variations break the user interface at many places which is difficult to solve) It especially has to be considered, that the parameter memory is limited to 1024 bytes for each track. It won't be possible to allocate much more, because for 16 tracks this is already 25% of the available LPC1769 (and STM32) RAM. Of course, such extensions could be considered in a V5 version (if it ever will be started). However, here some stuff for testing: -> http://www.ucapps.de/mios32/midibox_seq_v4_074_pre1.zip From the ChangeLog: MIDIboxSEQ V4.074_pre1 ~~~~~~~~~~~~~~~~~~~~~~ o "SD Card connected" message not displayed after boot anymore, instead only when the SD Card is exchanged o whenever the ALL function is active, you can now directly select the steps which should be modified with the GP buttons (LEDs will show the selection pattern) o the ALL function has been enhanced: - press & hold the ALL button and move the encoder of the already selected step (marked with >...<) to change all steps to the same value (like before) - if ALL button not pushed (but active), move the encoder of the already selected step (marked with >...<) to change all step values relatively (like before) - NEW: if ALL button is active (regardless if pushed or not), and the encoder of an unselected step is moved, the editor will generate a ramp between the selected step and the moved encoder. This feature has been borrowed from Sequentix Cirklon - thanks for the inspiration! :-) The "selected step" can either be changed with the datawheel, or it will be changed if the ALL function isn't active (as before) I hope that the usage is ergonomic enough - in distance to the Cirklon the encoders have no push function, therefore this cumbersome way via the ALL function. Best Regards, Thorsten.

Cool! Good that I already considered the mirrored_row flag! :) Best Regards, Thorsten.

We would have the same problem with a MBSID V2 editor... ;) Best Regards, Thorsten.

When you search in the .NGC documentation for the keyword "nibble", you will find the appr. variables which allow to extract values on various ways: http://www.ucapps.de/midibox_ng_manual_ngc.html The ^dump feature won't work here, instead you've to extract the values with individual EVENT_RECEIVERs (unfortunately). This also means, that the max. value position which can be parsed on this way is limited, because the maximum stream length is 128 bytes, and each variable consumes 2 bytes. However, here a usage example for the case that these limitations are acceptable: EVENT_RECEIVER id=1 fwd_id=ENC:1 type=SysEx stream="0xf0 0x01 0x02 0x03 ^val_n2 ^val_n1" EVENT_RECEIVER id=2 fwd_id=ENC:2 type=SysEx stream="0xf0 0x01 0x02 0x03 ^ignore ^ignore ^val_n2 ^val_n1" EVENT_RECEIVER id=3 fwd_id=ENC:3 type=SysEx stream="0xf0 0x01 0x02 0x03 ^ignore ^ignore ^ignore ^ignore ^val_n2 ^val_n1" Tested with: f0 01 02 03 04 05 06 07 01 02 f7 The values 0x45, 0x67 and 0x12 will be correctly forwarded to ENC:1..ENC:3 BUT: you need a MBNG update, because previous versions didn't forward the value if the "stream" didn't end with 0xf7 (now the value is forwarded with 0xf7, or if the last byte in the stream matched) -> http://www.ucapps.de/mios32/midibox_ng_v1_025_pre2.zip Best Regards, Thorsten. P.S.: @Martijn - the implementation is: case MBNG_EVENT_SYSEX_VAR_VAL: match = 1; pool_item->value = (pool_item->value & 0xff80) | (midi_in & 0x7f); break; case MBNG_EVENT_SYSEX_VAR_VAL_H: match = 1; pool_item->value = (pool_item->value & 0xf07f) | (((u16)midi_in & 0x7f) << 7); break; case MBNG_EVENT_SYSEX_VAR_VAL_N1: match = 1; pool_item->value = (pool_item->value & 0xfff0) | (((u16)midi_in << 0) & 0x000f); break; case MBNG_EVENT_SYSEX_VAR_VAL_N2: match = 1; pool_item->value = (pool_item->value & 0xff0f) | (((u16)midi_in << 4) & 0x00f0); break; case MBNG_EVENT_SYSEX_VAR_VAL_N3: match = 1; pool_item->value = (pool_item->value & 0xf0ff) | (((u16)midi_in << 8) & 0x0f00); break; case MBNG_EVENT_SYSEX_VAR_VAL_N4: match = 1; pool_item->value = (pool_item->value & 0x0fff) | (((u16)midi_in << 12) & 0xf000); break;

I would propose to read the MIDIbox CV thread, which I linked earlier - it gives you a better insight into the possibilities, and it especially answers your questions! E.g. on MBCV each CV channel has a dedicated Arpeggiator, step Sequencer, two LFOs, one "normal" envelope and one multi-step envelope + a modulation matrix. 8 CV channels are supported by default, the achievable update rate is ca. 5 kHz as far as I remember. To give you a comparison: typical "modern" synths are working at 1 kHz update rate only. Btw.: I'm planning a "synth-like" control surface for MBCV as well... it just needs some time because so many other topics are on my TODO list... ;-) Best Regards, Thorsten.

Yes, I still have the Stribe controller, but I got rid of the idea to support it in MBNG, because - there is only a very limited number of people who got the first layout revision (like me), and it would require a special MAX72xx handling for which it's difficult to find a generic solution (and MBNG is a generic controller...) - the PIC based firmware implementation is working perfectly - I can't support newer Stribe layout revisions since I don't own the hardware for testing - if somebody really wants to use Stribe with a LPC17, he could port the PIC based firmware (it's written in C) Best Regards, Thorsten.

But this isn't the same. This Cirklon feature just changes the values of the steps based on a vector entry. This is a static change - and simple to implement. But as far as I understood Arkay, he requested a dynamic generation of value changes, with multiple events generated between the steps at high resolution. Like an envelope... and the start and end step should be free assignable. Means: if you set step #1 to 127, and step #16 to 0, remaining steps disabled (gate off), it should automatically sweep from 127 to 0 with 1 LSB resolution (128 CC events have to be generated) Meanwhile I had some more thoughts on this, but I don't see a solution which wouldn't dramatically affect the overall performance, or would lead to "hard to understand limitations". Just consider, that MBSEQ can handle up to 16*16=256 layers - and they all would have to generate individual envelopes for freely selectable steps... On the other hand: the way how it is realized in Cirklon would be straightforward and easy to add as some kind of "editor tool" Best Regards, Thorsten.

Thanks goes to Daemonik - he added this feature! :) Best Regards, Thorsten.

Well, the MAX72xx driver is implemented, but since I don't own exactly the same hardware like you, it will be difficult to find out a perfectly fitting integration into MBNG to cover your usecase. How many MAX72xx chips are in your Tascam controller, and how many digits are connected? Best Regards, Thorsten.

alright - with this pre-release the Inc00Speed_Dec40Speed should work correctly. http://www.ucapps.de/mios32/midibox_ng_v1_025_pre1.zip Best Regards, Thorsten.

Yes, this mode probably needs some adjustments, the calculation for the incrementer doesn't look right. Is the Inc01_Dec41 mode working at your side? It's almost the same, just only the speed isn't considered. If it doesn't work: could you please find out, which CC values are sent exactly by your controller? Best Regards, Thorsten.