MIDIbox SEQ V4 Release + Feedback

[TK.]

Regarding the quantisation, I think it's ok if it's known/documented in the manual as it is.

 

Alright, I will document this at the http://www.ucapps.de/midibox_seq_manual_ki.html page (which is currently empty ;-)

 

Sooner or later I will revise the code based on the features which have been integrated in the last months. Currently there is a lot of cumbersome "experimental" code which I added quick&dirty for evaluation purposes. Once I'm sure that the feature set is settled, it makes sense to think about a proper solution. :)

 

 

However, when you now use EDIT RECORDING, you can only record notes with length 1%, so you have to adjust the length by hand if you want to hear what you recorded. When you're recording a step, as long as you hold the key(s) down, the right LCD upper row shows "length 75%", but when you release, it changes to 1%.

 

This wasn't intended - should work with pre21

 

 

One more this that I found today, maybe it's intentional, but I thought I'd mention it: If you have set the Parameter Layer C button functioning to 'toggle' in the HW setup file, you can get into the following situation.

 

This option hasn't been considered, it should be fixed as well

 

Please try: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre21.zip

 

Best Regards, Thorsten.

[jjonas]

The fixes seem to be working now!

 

And I swear I'm not actively looking for these :-) but I noticed a problem with forwarding and recording the note C-6. Curiously it's only this one note!

 

I have my controller set to ch.1, and in the MIDI Router the settings for Node #1 are like this:

 

IN:IN1     ///      P/Chn: #1    ///     OUT P/Chn: Sel.Trk.

 

All other nodes have P/Chn. set to ---. With these settings note forwarding/recording works like this:

 

EDIT page: C-6 Fwd ok; other notes Fwd ok

EDIT RECORDING: C-6 Fwd and Rec ok; other notes Fwd and Rec ok

STEP RECORDING: C-6 Fwd ok, no Rec; other notes Fwd and Rec ok

 

If the router settings are like this:

 

IN:IN1     ///      P/Chn: ---    ///     OUT P/Chn: Sel.Trk.

 

...then:

 

EDIT page: C-6 No Fwd; other notes Fwd ok

EDIT RECORDING: C-6 Fwd and Rec ok; other notes Fwd and Rec ok

STEP RECORDING: C-6 No Fwd and no Rec; other notes Fwd and Rec ok

 

I tried only with ---, #2 and #3 for P/Chn., but I suspect it's the same with all settings but #1, which is the controller channel.

 

I'm not sure how exactly the Router settings should work, for example should there be any Fwd or Rec at all, with any notes, if P/Chn: is set to --- or some other channel than the one the controller is sending on..? Or does Sel.Trk override these settings?

[TK.]

Good that you even tested this part now! ;-)

C-6 is the remote key (configured in MBSEQ_HW.V4) which should neither be recorded, nor forwarded under all circumstances

This wasn't considered under all conditions after the last changes anymore.

 

So, please try this version:

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

 

All bus configurations have to be checked again for recording, transposer/arpeggiator and forwarding.

 

Best Regards, Thorsten.

[jjonas]

With Router settings IN:IN1, P/Chn: #1 (or All) and OUT P/Chn: Sel.Trk. (or #1, All, Track), with controller sending on ch.1, C-6 still gets forwarded with EDIT page, EDIT recording and STEP recording.

 

Edit: For the above I just tested my previous setup (described above). I haven't done any thorough testing, and it feels like it's a bit beyond what I'm used to with the seq (e.g. I'm not sure what exactly I should do if "all bus configurations" had to be checked), but I noticed that if DefaultPort (on the midi router page) is set to OUT1 (which feeds the synths) while IN P/Chn is #1 and OUT P/Chn is #1 (with controller sending on ch.1) pressing C-6 produces a hanging note.

 

I can test further, but I would need more detailed instructions. You must decide if writing the instructions is more work than checking it yourself :-)

Edited April 29, 2015 by jjonas

[TK.]

The MIDI router works independent from the remote access and "Play Live forwarding" method, and no filtering takes place here.

 

I'm not sure if this is really desired.

If you use a keyboard for recording, you should configure a bus in Rec mode, and activate forwarding in the Jam page.

 

Hanging notes can happen if you change the router configuration while notes are played - there is no protection measure against this.

 

Best Regards, Thorsten.

[jjonas]

I'm ok with the Remote function related behaviour, because I don't use it; in fact now that I realised it can be disabled in the HW file, I think I'll do that. Maybe someone who uses the function and knows how it should work (at least better than me) could debug it further.

[pawaga]

About the nth feature, I think there is a problem with drum tracks :

if i set a nth param on a step, it will work until another drum play on the same step.

[TK.]

Another special condition that I haven't considered... ;-)

 

Please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre23.zip

 

Best Regards, Thorsten.

[pawaga]

it works great now.

thanks a lot !

[TK.]

Great! :smile:

 

So - the final V4.088 is now available for download.

 

Changes:

MIDIboxSEQ V4.088
~~~~~~~~~~~~~~~~~

   o improved glide function for polyphonic steps

   o BLM16x16+X support for Mute and Solo
     The new functions are available at Extra Row Button #3 and #4
     (if a BLM16x8+X is connected, they replace Start/Stop at Extra Row Button #1 and #2)

     If Mute active: the extra column buttons mute/unmute tracks
     If Solo active: the extra column buttons solo/unsolo tracks

     LED Colour coding:
     - LED off: Track neither muted nor soloed
     - LED green: Track muted
     - LED yellow: Track soloed
     - LED red: Track muted and soloed - solo has higher priority, therefore track will be played

     Special Key combinations:
     - ALT+Mute clears all mutes
     - ALT+Solo clears all solos

   o added Robotizer Fx from Borfo

   o added LCD Screensaver.
     It will be active after 30 minutes by default.
     The time can be changed in the UTIL->OPT menu page.

   o added DETENTED4/DETENTED5 option for rotary encoders in MBSEQ_HW.V4 file

   o added new parameter layers "Nth1" and "Nth2" which trigger a special action 
     on each nth bar (Nth1) starting at the 1st bar, or after nth bars (Nth2).
     Following trigger conditions are available:
     - Pl (Play each nth bar)
     - Mu (Mute each nth bar)
     - Ac (Accent each nth bar)
     - Ro (Roll each nth bar)
     - Fx (enable Fx each nth bar)
     - Nx (don't enable Fx each nth bar)

   o combined Record and Live page to a new single "Jam" page with sub pages 
     to improve the overview and simplify the configuration.

   o added Live Pattern Recording to Jam page which can be used to play and record
     customizable arpeggiator sequences.
     Available in the Jam page (Utility->Jam->Ptn)
     See updated user manual for further information.

The new features are described (in a bit more detail) in the user manual:

http://www.ucapps.de/midibox_seq_manual_m.html

 

Best Regards, Thorsten.

[mfk]

Danke!

[latigid on]

Feature request: all 16 tracks can have their gates assigned to DOUT pins. I think at the moment just the AOUT + extras on "AOUT_16" can send them. I'm not sure how that would work with port assignments: can a gate be sent on both a MIDI channel and as a DOUT signal?

[TK.]

The next question will be to add CV outputs for channel 9..16 (which will require a lot of firmware changes), right? :-/

 

 

I'm not sure how that would work with port assignments: can a gate be sent on both a MIDI channel and as a DOUT signal?

 

you could use the Duplication Fx for this purpose

 

Best Regards, Thorsten.

[latigid on]

The next question will be to add CV outputs for channel 9..16 (which will require a lot of firmware changes), right? :-/

 

No extra CV needed :)

 

 

you could use the Duplication Fx for this purpose

 

Okay, but what's the best implementation? Assign all tracks to AOUT port, channels 1-16 with duplication for 8 channels to the respective MIDI ports? In this case there's nothing in the config file to assign the gates to the correct SR (AOUT 1-8 but not 9-16)

 

But isn't AOUT 16 already configured for extra gates with one sent for every MIDI note?

 

Going back the other way, using the respective ports with duplication to AOUT 16. But here wouldn't the gate respond only if it hit the correct MIDI note? Would there be a way to map all notes of a channel to a single note on AOUT 16 and thus the correct SR pin?

 

Many thanks,

[TK.]

The discussion gets confused - what is the actual use case for the 16 gates?

And how should the gates be handled for drum tracks, which has actually multiple gates (one for each drum instrument).

 

Best Regards, Thorsten.

[latigid on]

I think in combination with a BLM, having the ability for each track to send its own gate would be a powerful feature.

 

If a gate event is already defined in the SEQ then it would be great to assign this event to an arbitrary DOUT pin if it's possible. Even if this repurposes the 64 available gates/triggers on AOUT channel 16 gates -- I'm not sure if anyone is using this feature ( ?)

 

Many thanks,

Andy

[TK.]

More likely somebody will use the 64 gate/triggers and control them from one or more drum tracks (which can be nicely configured with the BLM) than sacrificing common tracks for this purpose.

 

Please don't get me wrong: such an option could be easily implemented into the firmware, and the configuration could be well hidden into a configuration file (or in the UTIL->Options page) in the hope that somebody (aside from you) will ever use it.

 

But somehow I haven't the feeling that this is a useful feature compared to existing possibilities. And actually I would prefer to spend some time to overwork the CV/gate channel assignment concept and come up with a more flexible solution instead of providing just another poorly conceived extension.

 

The current CV related possibilities are already too confusing and especially not scalable, as it turned out in various forum postings.

 

Best Regards, Thorsten.

[latigid on]

No worries, and there's no hurry for major changes 

 

This was my idea for a 2-3 rack unit front panel for the SEQ:

 

 

 

MBCV would be similar but with CV inputs and clock outputs for the right hand connectors.

[warpboy]

Hello ,

I'm testing the V.088 software version of the seq V4 . I'm working with sync for mute/unmute and pattern change.

I was adjusting G4T2 for sync to measure (divider menu) and after when I go back to the track mute/unmute page, there no more sync for this parameter...

I have to power off/power on the seq and sync mute/unmute work again for the 16 tracks...

 

I hope to be clear :whistle:

[mfk]

Ich habe einen komischen Fehler bei mir gefunden und hoffe, dass den jemand von Euch nachproduzieren kann, damit ich nicht nach Lötfehlern suchen muss:
V4, neuste Software.

Parameter Leyer = A oder C

wenn ich nun eine ander Taste* taste, springt Parameter Leyer nach ein paar Millisikunden auf B.

 

*nicht alle Tasten, aber beispielsweise bei ALL, FAST, MUTE, EDIT, MENU, STEP VIEW, EXIT, etc., nicht jedoch bei Taste 1-16

Irgend jemand eine Idee?

 

EDIT: Erstes Problem tritt gerade nicht immer auf; scheint demnach eher ein Lötfehler zu sein.

EDIT 2: Kann auch ein Pufferfehler gewesen sein. Ich habe den Seq. ein paar Minuten vom Netzt genommen. Das hat das Problem bis jetzt vollständig gelöst.

 

 

Dann habe ich noch ein anderes Problem:
Wenn ich ALL dauerhaft taste, sollten doch eigentlich alle Notenwerte beim Wert ändern synchron sein.
Bei mir passiert es ab und zu, dass nicht alle Steps mitziehen.
Ist das vielleicht irgend so ein Feature?

Edited June 5, 2015 by mfk

[TK.]

See also http://www.ucapps.de/midibox_seq_manual_fp.html - search for "ALL"

 

NEW since v4.074: if the 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.

 

Another possibility for this behaviour could be a lose contact on your ALL button, so that it isn't permanently active when you are pushing it. In this case values will only change with relative increments.

 

Best Regards, Thorsten.

[pawaga]

hi,

the "delay" layer is not recorded in live rec mode, so i tried something : I added this in seq_record.c, around line 472 :

              } else {
                    //handle the delay layer
                    // if a delay layer is present, record to it
                    u8 num_p_layers = SEQ_PAR_NumLayersGet(track);
                    u8 *layer_type_ptr = (u8 *) & tcc->lay_const[0 * 16];
                    int par_layer;
                    u8 instrument = 0;
                    u8 delay;

                    for (par_layer = 0; par_layer < num_p_layers; ++par_layer, ++layer_type_ptr) {
                        if (*layer_type_ptr == SEQ_PAR_Type_Delay) {
                            delay = (SEQ_BPM_TickGet() - t->rec_timestamp) / 4;
                            // not sure about the "/4", but give weird results if the delay val is too large
                            SEQ_PAR_Set(track, ui_selected_step, par_layer, instrument, delay );
                            break;
                        }
                    }
                }

 

it works but not very accurate...

Anyway , so far, i like it!

 

best regards

Patrice

[TK.]

Hi Partrice,
 
interesting hack! :smile:
 
The sequencer core calculates the resulting delay as:

t->bpm_tick_delay = (delay * t->step_length) / 96 

 
This explains why you had to divide by 4
 
The correct formula which also works with different clock dividers should be:

delay = ((SEQ_BPM_TickGet() - t->rec_timestamp) * 96) / t->step_length;
if( delay >= 96 ) delay -= 96; // because quantisation has put the event into the next step

(untested)
 
Best Regards, Thorsten.

[pawaga]

hello Thorsten,

thanks for your help, i understand now.

yes, i tested it and it work now for different clock dividers !

i also added the quantization :

 

                } else {
                    //handle the delay layer
                    // if a delay layer is present, record to it
                    u8 num_p_layers = SEQ_PAR_NumLayersGet(track);
                    u8 *layer_type_ptr = (u8 *) & tcc->lay_const[0 * 16];
                    int par_layer;
                    u8 instrument = 0;
                    u16 delay;
                                            
                    for (par_layer = 0; par_layer < num_p_layers; ++par_layer, ++layer_type_ptr) {
                        if (*layer_type_ptr == SEQ_PAR_Type_Delay) {
                            delay = ((SEQ_BPM_TickGet() - t->rec_timestamp ) * 96) / t->step_length;
                            if( delay >= 96 ) delay -= 96; // because quantisation has put the event into the next step
                            delay -= (delay * seq_record_quantize) / 100;//quantize it
                            SEQ_PAR_Set(track, ui_selected_step, par_layer, instrument, delay );
                            break;
                        }
                    }
                }

 

The next point i want to tackle is the pitch layer : discrete values are not very useful for that, it would be nice to glide values between two step...(for CCs as well)

 

best regards

Patrice

[latigid on]

Meanwhile, was there any progress with a new solution for gates? At some point I'd like to get a full SEQ breakout panel made and I wonder if I should implement space for 16 gate outs. (See previous page for a possible panel mock-up.)

 

Best regards,

Andy

 

 

More likely somebody will use the 64 gate/triggers and control them from one or more drum tracks (which can be nicely configured with the BLM) than sacrificing common tracks for this purpose.

 

Please don't get me wrong: such an option could be easily implemented into the firmware, and the configuration could be well hidden into a configuration file (or in the UTIL->Options page) in the hope that somebody (aside from you) will ever use it.

 

But somehow I haven't the feeling that this is a useful feature compared to existing possibilities. And actually I would prefer to spend some time to overwork the CV/gate channel assignment concept and come up with a more flexible solution instead of providing just another poorly conceived extension.

 

The current CV related possibilities are already too confusing and especially not scalable, as it turned out in various forum postings.

 

Best Regards, Thorsten.