NexStep Sequencer for the QuNexus and Live

[TheOtherSupport@KMI]

http://www.keithmcmillen.com/project-de ... 59-nexstep

We just released a nifty little sequencer for Ableton Live and the QuNexus. It's free, and all the files, scripts, docs are included at the link.

Enjoy!

[SenorBlasto]

I cant seem to get the velocity to work? It just send 127 everytime? Is it just me?

[TheOtherSupport@KMI]

Damn. You're right. You can scale it with a velocity effect in the meantime, but I have corrected the issue and a new download will be available shortly.

[TheOtherSupport@KMI]

Updated the device;

http://www.keithmcmillen.com/project-de ... 59-nexstep

[an3]

aamaazing !!!

could u add native support for start stop Mute and restart !!

u made my day

[TheOtherSupport@KMI]

I am totally willing to take new features/redesigns into consideration.
When you say native support, do you mean buttons for that on the QuNexus? Fitting all the functionality onto the qunexus was quite a challenge, and we can't really add any more interface options without removing some previous functionality.
I could easily add those features and have them be mappable via midi. You'd have to switch presets though to access them, or use two controllers.
Let me know your thoughts.

[an3]

true. but non native assigningalways give some kind of led issues.

i weas thinkin u can use the bend, oct, velo pressure tilt buttons.

also would it be hard to port this device to a single track melodic stepsequencer (in my case i use the qunexus for synths + cv). that would be rad

great work!

[TheSupport@KMI]

i weas thinkin u can use the bend, oct, velo pressure tilt buttons.

The problem with that is none of those buttons output MIDI (except the bend pad).

[bob]

hello there
I have some suggestions, maybe too much but I try
first, I think it would be better to sequence directly the selected clip in live. there was that device (http://www.maxforlive.com/library/devic ... -sequencer) which do this with the qwerty keyboard, I suppose it's possible with the qunexus. and it's far better to manage clips as patterns, like with the old groovebox, and more integrated within Live.

then for selecting the note to sequence, I suggest to use the Bend pad as a shift button : hold shift, select the note on the keyboard, release shift and then edit the sequence on the keyboard.
so there would be more note to use, and the black keys could be use to adjust the loop length parameter or the grid scale.

last, and maybe a more feeling question. as there are only 15 step on the qunexus keyboard, there is a "jump" to have the 16th step. you've put this jump on the first step, but it's no good to count the step easily. as we counting from the first, we need it.
I think it would be better to put the jump on the "stop" pad (2nd G#) as the 13th step. it would a little more easy like this I think.

with all of that, it would be far more ergonomic to stepsequencing, but maybe more difficult to program.
I hope you will understand those point of view

[TheOtherSupport@KMI]

@bob

While I appreciate the input and suggestions, most of what you are requesting would be a shift away from certain design choices we made, and are not likely to be considered. The use of the bend pas as a shift button is a great idea though, and something that I will try to get implemented. As far as what we would like to control with the shift mode, that will have to be decided.

Writing the notes to clips would be possible, but I personally don't see a huge advantage. If you want to record the sequence into a clip, it's really simple. For my workflow, writing directly to a clip doesn't have any distinct advantages. I would like to incorporate some sort of preset system, for switching patterns (perhaps THAT is what the shift button will do).

Selecting the note to sequence can be done from the device's UI, and I don't think it would be a huge time saver to implement on the fly note selection.

we debated on using a different key for the extra step, and the one we chose seemed to be the most logical. The wrap around from the last white key to the last black key was too far, and we didn't want the jump to be in the middle of the sequence (as you suggested with the G#).