Jump to content

MIDIbox SEQ V4 Release + Feedback


Recommended Posts

Posted

<<maybe this post is best here>>

Hello guys,

I was thinking about the chord handling in the SEQ V4. and have some suggestions for a future version (or for the v4plus).  Currently we need a root note track (into a bus) and a chord track (being transposed from the bus) in order to properly play a chord progressions.   But we also have multiple parameter layers in many track types, one of which is 'note' and another one of which is 'chord'.    

We do have 256 step/ 4 parameter / 8 trigger  and 128/8/8 chord track already, but are there use cases for the additional parameter layers?  Now suppose the note in parameter layer A would transpose the chord in parameter layer B (layers C and D could still hold velocity and length info).  Maybe then even parameter layer E could hold arpeggiator information, so that everything would be on one track!   We would have a great overview editing such tracks in layer view. I  guess not many people make longer-than-256-position chords progressions. 

I gave it a try of course, set up a 256/4/8 chord track, changed par A to note par B to chord, but then it plays both the note and the chord with root C.   Maybe if there is another parameter type 'root'  that feeds the chord type? I don't know the implications of such change for the software architecture, and if it is possible at all, but I think this approach might simplify the chords handling in the SEQ V4.

'll be happy to hear your ideas about my suggestions, whether it makes sense, whether it is possible at all etc.

Posted

Yes thank you TK,

That might be an excellent solution, I would really like to try that and help testing.  

If the root note parameter would work as a local transpose for the chord on another parameter layer, that would in fact create a chord track, as in Cubase and other daws. If also the arpeggiator information could make it into a parameter layer, then everything would be bundled into a single track.  I guess that would make quite a powerful feature.

 

 

Posted (edited)

Thank you TK for your quick action!! Unfortunately it does not yet do what i expected.  I will try to explain what I did and what I expected:

I made a very short sequence with par layer A = root and par layer B = Chord.  Four steps only; root C and chord A/3 (major) on step 1 and root D and chord a/3 (minor) on step 3.  I expected that this would output C-2 E-2 G-2 on step 1 (which it did)  and D-2 F-2 A-2 on step 3 (the minor chord with root D). But on step 3 I also get C-2 E-2 -G-2.   So apparently, somehow the root info does not affect the chord.  Or maybe I havent set it up right?

Edited by EsotericLabs
Posted

This was related to a stupid mistake that I introduced during the last changes before pushing the release button :-/

Here a new version:
-> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre2.zip

Meanwhile I also added a more detailed description to the ChangeLog:

   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.

Best Regards, Thorsten.

Posted

Excellent, it works!

Some notes:  I set up a 128/8/8 note track with one note, one root, one chord parameter layer.  The note layer is apparently necessary to send a trigger, without it, no chord is played.  i put c-3 in and it is correctly transposed to d in step 3 by the root note layer and chorded to Dm in the chord layer. When i put a c-4 note in, it is a higher octave root note in the chords.

I noticed though that the chord naming in the upper line of the right lcd is a bit 'off' . i have chords A/3 in step 1 and a/3 in step 3, both from the original chord set.  They are both displayed as Maj6/2 however and empty steps 2 and 4 say Min10/1. I'd expect Major I and minor I in 1 and 3 and none in 2 and 4. 

The chord track feature is excellent though!  I will play a bit more with it, see what happens when I send this one through a bus into an euclidian bass pattern and/or an arpeggiator track.

Posted

Great idea to use such a track to transpose/arpeggiate other tracks :)

I'm surprised that a note layer is required to play a chord. I also can't reproduce the chord display issue at my side.
Could you please send me an example pattern where you notice this?

You can store the pattern into a file from the EVENT->Pattern page

Best Regards, Thorsten.

Posted (edited)

Hello TK,

Thanks for looking into this.  I found that the chord track does not really need a note, but a gate trigger. Previously, I had been switching notes (and gates with that on & off).  If I go into edit -> Trg view, i can switch chord playing on & off with the gate trigger, which makes sense! No note layer needed indeed.

The chord display issue is still here though: I have chords A/3 a/2 a/3 A/3 on G1T1 of the attached zipped session. In edit->step view; the right lcd says (above encoders 11 & 12)  Maj.II/0  Maj.8/0  Root/0 Maj.6/0.   This seems strange to me; both A/3 chords are major I and a/2 and a/3 should be minor I, according to the dox and the source code. 

Testsession.zip

Edited by EsotericLabs
Posted (edited)

And maybe, if you feel like programming, I have another suggestion, now for the drum tracks.  

At the moment, there are about 7 types of drum tracks with one or two parameter layers, one or two trigger layers and 4, 8 or 16 drum instruments.  Maximum length is 256 steps with one trigger, one parameter and four drums instruments.  That is actually quite long, especially if you consider that the Nth1 and Nth2 can add quite some variety with fills, accents, crashes and stuff. They can be programmed into a 32 or 64 step sequence, and being played only every 2nd, 4th or whatever time. The difference between Nth1 and Nth2 is very nice.

I would argue there is a use case for more than two parameter layers in drum tracks: e.g. an  Nth1 layer, an Nth2 layer, a Roll and something else. It is easy to add or change a line in seq_ui_trkevnt.c to allow more parameter layers; but then there is a UI issue: In the Track Event mode, drum tracks have fixed type positions for LayA and  LayB.  

Note tracks, however, have different handling of parameter layers with encoder 9 for selecting layers A-H and encoder 10 for what each layer controls.  If the drum tracks would have the same parameter layer type handling as all other track types, that would add some more flexibility. I gave it a try in Eclipse, but could not get it working properly. 

Edited by EsotericLabs
Posted

Alright, the problem with the chord display was, that it actually always displayed a label based on the first layer (and not the selected layer). This is fixed now.
-> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre3.zip

I also added the support for 4 parameter layers in drum tracks.

The implementation wasn't so difficult.
Would be nice if you could help testing (also the other layer modes to ensure that I haven't corrupted something)

Best Regards, Thorsten.

Posted (edited)

Testcase in testsession2.

  • G1T1 is a chord track that sends C Am Dm G into bus1 with parA root & pad B chord.  
  • G1T2 is a bassline from the euclidian generator, with only c-3 notes, transposed from bus1.
  • G1T3 is arpeggiated from bus 1 with a simple 3+0 2+0 1+0 2+0 repeating pattern
  • G1T4 is drum part (4*16/2*64) with 16 instruments (4 used)  with rolls, Nth1 and Nth2. 

First test results:

  • in G1T1 the chord display issue is solved. 
  • in G1T2 something special is going on with the transposed bassline. In order to stay in tune, it must be transposed +5 semitones. And when you changes e.g. the second chord from a/2 to b/2, that also affects the bassline. It seems to make sense when the bassline takes the first note of the chord for transposition (which is the fifth and not the root). This is plausible, because the arpeggiator plays the root at 3+0 and the fifth at 1+0. Maybe the arpeggiator could be tweaked so that in root position chords 1+0 = root and 3+0 = fifth?
  • G1T3 the arpeggiated track works like a charm.
  • G1T4 the four parameter layer drum track type works great .
  • I've also tested some of the existing types of drum track (2*64/2*128; 8 instruments). Gate, accent (triggers) and Roll  & Nth1 all seem to work just as before. Same with (128/2*128; 8 instruments) with gate, accent and roll.
  • I've added some extra drum track types (4*32+2*128; 8 instr. and 4*64+2*256;4) (i'm tweaking for my 2 synth 4 drum instrument Novation Circuit) -they work too!  Ive tested the 4*64;2*256 4 instrument track with Nth1, Roll and Prob - no issues.

Thank you so much, TK, this is already a great feature. Any more testing you want?

Testsession2.zip

seq_ui_trkevnt.c

Edited by EsotericLabs
Posted
On 2.11.2016 at 10:51 PM, TK. said:

added to wish list for MBSEQV4+

Best Regards, Thorsten.

Thanks! And some more suggestions:

 

- "No value" for CC layers. At the moment, it's always a value from 0 to 127. As there is only one trigger, this leads to problems when using lots of CC layers. EG: I configured a track as 16 CC layers, recorded tons of automation into all the layers via knobs from a controller. As there is only one trigger layer, triggers are subsequently set to "on" on all steps. I start tweaking a new knob, the CC gets automatically selected and recorded into a free layer (which is obviously an awesome feature). Initial value is 0. In a 4 bar pattern, I want to only change the value twice, say long decay for two bars, short for the other two bars. This doesn't work, as I would need to continuously slightly wiggle the knob for the two bars at the long position, so it overwrites all the "0" values, then the same again for the short decay setting. Alternatively, a separate linked trigger layer for each parameter layer would solve that, too, and also allow for proper independent polyphonic note-recording.

 

-Add a way to turn Live Jam REC on / off via MIDI / assign to a button with LED. I guess as the whole Live Recording functionality was only added later on, we have the situation that this might be one of the very few sequencers without a dedicated RECord button! It would be really handy to either map it to an external MIDI controller (eg to use via a pedal – works great on the MPCs) or just to a less used CS button. Best something with a LED, so we always know when it's on.

-Change of the behaviour of the clear key to spot erase (I might have proposed this before). Right now, functionality is like this:

  • Clr: clears the parameter/trigger layers, or the whole track. The behaviour of this function can be configured in the UTIL->OPT page

Personally, I would find it far preferable if this would work something like this: With the sequencer running and in Live Rec Mode, while you hold down the Clear button, the  values of the selected Trig / Parameter layer will get erased as the steps play. This would allow for really easy fixing of mistakes without having to identify the step to be deleted and then manually doing it. On the MPC, you can even hold clear when in Overdub mode and then tap the pad or hold the key of your controller to spot erase.

 

-By default disabling the groove feature for all subidivisions except 16ths. I don't know, but I don't assume there is too many people that want to have every other of their bar-long pad notes with swing ... And as soon as you start using lopback tracks to switch around the subdivisions, this gets even worse, as it messes with the timing. Say I switch from a 16th subdiv to 8ths, then the timing for every even-numbered 8th note is different to before.

 

Thanks! Everybody feel free to tell me that this is all already implemented and I just don't know about it!

Posted

Alright, here some updates:
-> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre5.zip
/edit: corrected to newer link

   o new drum configurations: 4*16/2*64, 4*16/1*128, 4*16/1*256

   o new track mode configuration option: "Note"
     Allows to specify, if the transposer should take the last or first
     played note (previously it always played the last note)

   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 the selected step only (not the entire pattern).
     During live recording it will clear the "played" steps so long the
     button is pressed.

   o new CC functions which can be configured in MIDI->ExtCtrl.:
     o Play/Stop: allows to assign the PLAY button to a CC
     o Record: allows to assign the RECORD button to a CC

@EsotericLabs: thanks a lot for testing!
G1T2 was playing the last note of the note stack. Since G1T1 played a chord into the transposer but, it was off the root note.
In the new version you are able to specify that the first note should be played.
Select Track #2, change to the MODE page and press GP button #9

@u-link:

- request #1 implemented (I also needed it ;-)
- request #2 was already implemented (there is a BUTTON_RECORD and LED_RECORD option in the MBSEQ_HW.V4 file, please update your file according to the templates under hwcfg/*)
However, Play/Stop and Record can now also controlled via CC (e.g. to control these functions from a foot switch)
- request #3: implemented (yes, it makes sense)


- request #4: statement & question:
I'm using custom groove patterns to vary the velocity, here I would like to control each 16th
In addition, since groove patterns can be applied globally, you want to define them independent of the track divider

However, what I could add is an option which allows to synchronize the groove pattern to the track step instead of the global step. Would this satisfy your request?

Best Regards, Thorsten.

Posted (edited)
13 minutes ago, TK. said:


- request #4: statement & question:
I'm using custom groove patterns to vary the velocity, here I would like to control each 16th
In addition, since groove patterns can be applied globally, you want to define them independent of the track divider

However, what I could add is an option which allows to synchronize the groove pattern to the track step instead of the global step. Would this satisfy your request?

Wow, that was quick! Thanks a lot, I will try it out asap, hopefully tomorrow. You are of course right, if you use groove patterns for velocity control, you want to keep it. I never did that up to now. What about keeping velocity control, but automatically ditching swing for non-standard (ie: non-16ths) sub div? While I am not sure I understand your suggestion correctly, I don't think it would do the trick. Imagine two tracks with different sub div sending to the same receiver, this would still lead to flams, no?

 

Edited by u-link
Posted (edited)

TK, you're amazing!

I will test the new note mode, for sure.  I also like remote cc control over stop and play very much, for working with a foot controller.  And of course, I will also try the other new functions....

for drum tracks, there are 1024 bytes for parameters and 2048 bits for triggers , is that correct? Less instruments allow longer parameter and trigger patterns, is my understanding correct?

 

Edited by EsotericLabs
Posted
1 hour ago, u-link said:

Wow, that was quick! Thanks a lot, I will try it out asap, hopefully tomorrow. You are of course right, if you use groove patterns for velocity control, you want to keep it. I never did that up to now. What about keeping velocity control, but automatically ditching swing for non-standard (ie: non-16ths) sub div? While I am not sure I understand your suggestion correctly, I don't think it would do the trick. Imagine two tracks with different sub div sending to the same receiver, this would still lead to flams, no?

You've to enable the "sync to track" option for both tracks, and they have to run with the same divider, then it will work! :)

Here the new version:
-> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre5.zip

21 minutes ago, EsotericLabs said:

for drum tracks, there are 1024 bytes for parameters and 2048 bits for triggers , is that correct? Less instruments allow longer parameter and trigger patterns, is my understanding correct?

You are right, I corrected the max. trigger layer lengths of the two additional drum modes that you introduced accordingly in pre5

Best Regards, Thorsten.

Posted (edited)

The note in the track mode works excellently, I am very happy with that. I'll notice @jjonas and see if we can update the beginners guide with the new system. It is much easier now to use the chord feature. 

I'm only not sure if the new drum track types are correctly in: 

  • 4*16 + 2*64 and 4*16 + 1*128 are correct for 16 instruments i think
  • seq_ui_trkevnt.c line 140 has a 4*16 + 1*256, 16 instruments drum track type, but that would have 4096 trigger step bits. If it is 8 instruments, there is room for 4*32 parameter steps if i understand correctly.
  • Two drum track types in the  code seem to double with others; e.g.  line 146  with 141 and line 147 with 144.
  • This could be a useful drum track type for Novation Circuit owners.: { SEQ_EVENT_MODE_Drum,     4,          64,        2,         256,     4 }. It has only 4 drum instruments and 2 synth, but is is a very nice affordable groove box to go with the SEQ. But I can also recompile a special edition  for myself, no problem.
Edited by EsotericLabs
Posted

Synced pattern changes should work again with this version:
-> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre7.zip

Background why this happened: last week I analyzed the stack usage and found out, that in worst case a stack overrun could happen while playing MIDI events or operating with the CS. I gave the appr. tasks more memory, and reduced memory for the pattern handler. By doing so, I overlooked that during a pattern change more memory will be allocated than expected.

With the last changes the pattern task became obsolete, giving more memory for the other tasks (and a bit more memory for additional features :)

I hope that with pre7 everything is working like before (or even better ;-)

Best Regards, Thorsten.

Posted

I like the refined concepts on chords and drum tracks!

 

Considering my previous request:

On 16/01/2016 at 5:21 PM, latigid on said:

Idea: track length LIMIT parameter. Accessible on the length page either before or after LOOP.

When programming in longer non-4/4 sequences I quickly get lost within the multiples of 16. What if the active 16 step view was limited to a selectable value (optional of course)? E.g. in "6/8" time with a length of 24, limited to 12 steps. Step view 1 gives 1-12, Step view 2 gives 13-24. To keep within the SEQ hierarchy, this would necessarily reduce the available number of steps of a track.

 

I think this can be worked-around by using a SKIP trigger layer, so I will give this a go and see how easy the handling is.

 

 

 

  • Like 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...