Jump to content

MBSEQ CC/Velocity Automation Question


Arkay
 Share

Recommended Posts

Hi All,

 

Hoping someone can tell me how or if this is possible with the mbseqv4.

 

I'm wanting to know if I can set a start position and value of a CC# for instance and have the sequencer generate accurate values at each step up to and including an end position and value that I also set.

 

Say I have a 128 beat long pattern over which I'd like to do a filter sweep,.  Can I set a cutoff filter at say a start value of 10 on beat 1, and an end value of 100 on beat 128, and have the sequencer fill in beats 2 thru 127 with generated values gradually stepped between my start and end thresholds?.  Or I may want a pattern to fade out over 20 beats stating at beat 44.  Can I have the sequencer do the hard work for me?

 

This could be used for filter sweeps, easy bass/snare drum rolls using velocity, useful for panning stereo sweeps etc. steps 0-16 gradually increasing from left to center, steps 17-31 gradually from center to right etc etc, copy/paste and repeat for steps 32- 64.

 

Secondly, can this be done across multiple patterns.  i.e.  If I wanted to arrange filter automation across multiple patterns in song mode can it be done and if so how?  Not that I've really progressed to song mode yet anyway but curious minds want to know :smile:

 

Still getting my head around the power and usability of this wicked machine.  I'd love to see many many more tutorials and/or videos on it's usage. More so people using it to create (start to finish), rather than the end creations only. A dedicated "how to use" forum would be great for anyone wanting to post tutorials on funky things they've learned to do on the MBSeq too (but I guess that is another thread altogether).

 

What has me thinking like this is the many graphical DAWs that allow a user to simply draw a filter curve or velocity curve (or line), via mouse on screen across a pattern or even multiple patterns.  Setting A/B points with interpolation in between would be a fast way of adding such?  Then again perhaps I'm thinking about this in all the wrong ways too.  Happy to be set straight ;)

 

It'd also be smart if the value changes are less frequent than the number of steps required then the CC#'s are only put in where required rather than at every step.  No point sending values of 99,99,99,99,100,100,100,100 etc over 8 steps when you could send 99,nothing,nothing,nothing,100,nothing,nothing,nothing etc... Reducing the amount of midi traffic.  

 

Any and all suggestions very much appreciated.

 

Cheers,

 

Arkay.

Edited by Arkay
Link to comment
Share on other sites

I know exactly what you mean, it's on my wishlist as well! :smile:

But it needs a lot of work in the sequencer engine, therefore it isn't available yet.

 

But here a hot tip for the case that you would like to do some experiments with CC sweeps: use the "Extra CC" option of the LFO with a high resolution (96 ppqn upwards)

By changing the Waveform, Amplitude, Phase, Steps and Reset parameter you can realize very cool sweep patterns automatically.

And you can change LFO parameters interactively while the sequencer is running.

The same can be applied to velocity as well!

 

The additional CC function (which isn't implemented yet) will work like an envelope instead, resp. it will interpolate entered and activated values (regardless if velocity, CC, pitchbender, etc...).

Like the LFO, it will allow to set a ppqn rate which defines, how many updates are generated between the steps.

 

However, please try the LFO - it's already very useful!

 

Best Regards, Thorsten.

Link to comment
Share on other sites

TK.,

 

Thanks for a very detailed response as always!  I'll check out the LFO and eagerly await the additions at a later stage.  Love the suggested way of implementing it too.  Will make it far more useful than the linear way I'd suggested in that first post.

 

Also great to know that I haven't gone mad and it wasn't sitting in front of me the whole time :D

 

Awesome work you do!!

 

Thanks again.

 

Cheers,

 

Arkay.

Edited by Arkay
Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

T.K.,

I see what you mean by the dynamic changes and that would be an awesome addition but I also understand why the logic to achieve that is soo much more complex.

The static/circlon way would also be of great use. If those pre programmed steps can then be all raised or lowered simultaneously and globally across the track like the circlon then that provides a "live" aspect to it's usefulness.

The only other option that I presently see (besides the LFO which works awesome BTW), is to manually edit each step via encoders which is cumbersome.

The lfo is great, but is more aimed at continued wavy automation. An editor based solution allows specific ramps to be used, without manually completing each step, but also allows for irregular shaped envelopes. The lfo with a sine wave for instance will give you a nice phase via the amplitude of the wave, but if I wanted to construct a:

0 to 29 step rise over 128 values

then a sharp drop down to 50 over the next 30 steps

then a further drop to 10 over the next 40 steps

it wouldn't be possible via lfo and the only way would be by manually adjusting the values of every step throughout the pattern (100 edits) when in reality 3 "ramp edits" are all that could be required:

start 0 end 29 range 0-128

start 30 end 59 range 128-50

start 60 end 100 range 50-10

I absolutely love the idea of the high resolution sweep via higher ppqn but that only matters for the use case when the number of gate steps is less than the range of sweep steps required. I do see the complexity in implementation and possibly even issues with understanding and obviousness of what is going on to the end user from a UI perspective.

In reality if a user needs a higher resolution sweep there's nothing stopping them from using a higher resolution for the entire track and then distributing the cc ramps via the same static edit methods. i.e. Setting a start/value and end/value pair and having the editor generate the static steps in between, at what ever resolution the entire track runs at.

Obviously large sweeps over small distances would result in low res audible jumps. In that case I probably wouldn't do it. This function is really of use over longer periods. Like increasing the velocity of a snare from 0 to 100 over 32 steps for a long snare roll for instance. Without the ramp function the end user must calculate the size of the increase per step manually and then input that velocity data to 32 steps, one at a time.

Possibly a different way would be to change how the sequencer presently works and have a highest ppqn effects track that always runs along side the standard note data in a track when the track contains cc data. i.e. The effects track is always at the maximum resolution and any statically made ramp type edits would automatically yield the smoothest changes between two endpoints. Allow a max of 4 cc numbers per effects track and remove the notion of tracks with gate and cc data combined. So a pattern is either just note date at it's specified ppqn, or note data + a 384ppqn effects track. That might not be practical from a speed perspective, just thinking out loud.

I think straight ramp (vector) generation between two points would be a great addition as a time saver, especially if it's easy to implement, that's a win/win :)

If it could be made to extend past a single track in song mode, then even better!

The higher res methods could be a longer term goal?

Cheers,

Arkay.

Edited by Arkay
Link to comment
Share on other sites

In reality if a user needs a higher resolution sweep there's nothing stopping them from using a higher resolution for the entire track

 

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

 

 

 

Possibly a different way would be to change how the sequencer presently works and have a highest ppqn effects track that always runs along side the standard note data in a track when the track contains cc data.

 

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.

Link to comment
Share on other sites

I am yet to try this, but perhaps the usage could be changed to: hold the ALL button, select two GP buttons, moving the corresponding step encoder will start the ramp fill.

 

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?

 

 

There could be a problem if you used steps outside 1-16 though.

 

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.

Link to comment
Share on other sites

T.K.

Man your are quick :) You sure there's not three of you working on all the things you do!!!

I'm out at present but will be trying this out as soon as I get home.

Handling sounds fine and I doubt I'll be able to come up with anything more ergonomic but won't know till I try it.

Initially I'd thought of a shift like function i.e. Hold select, press a step or tweak encoder to set step start position and initial value, release select, navigate to end position via whatever method user chooses, hold select, press the final step or tweak it's encoder to set the end step and final value, release select. Which seems logical to me. But so does what you've already done ;)

Awesome work!

Cheers,

Arkay.

Edited by Arkay
Link to comment
Share on other sites

Just tried it out.  That's awesome and so quick to edit what I needed to do.  Implementation is obvious and works really well.  

 

e.g. for those reading the thread if say you want to sweep to a midpoint in a pattern you can set the active step to 64 (midpoint of a 128 step pattern), then set step 0 and 128 to a value of 0 and you've got a perfect 0-128-0 ramp peaking in the middle of the pattern.

 

A 32 beat drumroll is as simple as selecting step 0, velocity 0, hitting "all", then changing step 32 to 100.

 

I think I found a bug though.

 

With the all button depressed if you scroll from position one through to position 17 and greater using the main encoder the display doesn't switch to the next set of 16 steps unless you hit the ff button to force the jump. i.e. if you use the main encoder to scroll through a display boundary the display isn't following the step selection.

 

You can see by the value next to the cc# that the steps are correct but the display remains static only showing the 16 steps you could see when "all" was selected unless ff/rew are used.  As a result if you scroll all the way to the end of a 128 note pattern via the encoder, changing the 16'th encoder results in you editing step 16, not step 128.  To see step 128 you'd either have to ff to it or turn all off.

 

Loving the functionality already.  Thanks for implementing this T.K.!

 

Cheers,

 

Arkay.

Edited by Arkay
Link to comment
Share on other sites

T.K.

 

Yep.  All fixed.  Thanks!

 

One final suggestion.  At present after you set the the active step the only way to get to another inactive step is via ff/rew.  It seems a little unintuitive that you can't scroll to the final step with the datawheel and then adjust it's value with it's specific encoder.

 

Just wondering if this might make more sense:

 

1. scroll to the step you wish to be the active step, denoted by > <  (all button currently off)

2. turn all on (locking in active step)

3. scroll to the final position via datawheel or ff/rew

4. adjust value with encoder (triggering ramp between active step and inactive step being modified).

5. turn all off to complete.

 

That way you can still scroll around the pattern with the datawheel without changing the selected active step.

 

Would this have any unwanted side effects with the all function itself?

 

Cheers,

 

Arkay.

Link to comment
Share on other sites

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:

 

 

At present after you set the the active step the only way to get to another inactive step is via ff/rew.

...

That way you can still scroll around the pattern with the datawheel without changing the selected active step.

 

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: 

 

 

1. scroll to the step you wish to be the active step, denoted by > <  (all button currently off)

2. turn all on (locking in active step)

3. scroll to the final position via datawheel or ff/rew

4. adjust value with encoder (triggering ramp between active step and inactive step being modified).

5. turn all off to complete.

 

Exactly this handling is possible when the Datawheel changes the StepView ;-)

 

Best Regards, Thorsten.

Link to comment
Share on other sites

T.K.

 

I did find the ability to change the function of the datawheel today while I was messing with the new functionality!

 

Happy to go with your suggestion above and thanks for the effort and the mods :)

 

Cheers,

 

Arkay.

Link to comment
Share on other sites

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

×
×
  • Create New...