Subpatch: 16 step sequencer

#1

Hi everyone!
Today i patched a quite simple 16-step sequencer. It's almost ready to use (just connect to a few things and you're ready to go!) and has some really neat features: sequencer16.axs (19.3 KB)

You can see it in action in this simple patch: Sequencer demo.axp (16.9 KB) , you simply have to put both files in the same folder.

BASIC SETUP RULES - READ THIS

-Create 16 dial objects and connect them to the respective blue inlets (value 1-..-16), you'll need these to provide the desired control values.
-Connect the clock inlet to your clock source (a simple lfo can do the job). The sequencer will go one step forward for each clock tick.
-Connect the CV outlet to anything you want to sequence
-Set the desired sequence length on the respective selector (last step for a full 16 step sequence)

Features description:

Clock in: Pretty self explanatory, you must connect it if you want the sequencer to run.
Reset: Active on the rising edge of the clock, it is used to force the sequencer back to step 1 (or step 16 if you're on backwards mode)
It's strongly advised to use it, however the sequencer will run even without it.
Backwards: When used it forces the sequencer to go from step 16 to 1 (you can leave it disconnected)
Value 1-...-16: The 16 values to sequence. You can connnect these inlets to dial objects, but also to other fractional stuff. This kind of setup allows great freedom.

Current step: outputs an integer number (0-15) correspondent to the active step. You can connect it to a disp/ibar16 for a visual reference of the sequencer, but you can also use it to furthermore expand sequencing possibilities.
CV out: provides the sequenced values.
Trigger out: provides a trigger signal (a short pulse) sequenced from the respective selector
Gate out: provides a gate signal sequenced from the respective selector (a gate is 1 step long, while a pulse is just a few milliseconds)
Restart: provides a pulse when the sequence restarts

Manual step select: if you check it the sequencer will stop running and only the manually selected value will be outputted
Latch to trigger: you can use this to latch the CV value to the trigger sequencer. Only control values corresponding to trigger pulses will be outputted
Backwards reset mode: When the sequencer is in backwards mode and this is checked, the sequence will reset at step N, otherwise (not checked) the sequence will reset at step 16-N

Manual step: You can use this when manual step select button is checked to select the step you want to be outputted (useful for editing)
Trigger sequencer, gate sequencer: Self explanatory, see trigger out and gate out
Sequence length: You can use it to set the length of the sequence. This way you'll be able to use odd time signature

KNOWN ISSUES:
-Sometimes the sequencer starts from step 2 when axoloti is powered. You may want to restart it manually using the reset inlet.
-Backwards mode could present some oddities

Sputnki contributions
Feeding random pitches into a sel_fb_16?
#2

if you download 1.0.3, you will see i fixed this in the simple sequencers tutorial
attached a const/i (value 1) to a change, and the reset on the counter... and when you load it will start on step 1. (like a loadbang in max)

not sure I understand this, I think the simple sequencer is ok on this... but I'll take a look at your patch to see what you mean

#3

Yeah, i checked your tutorial and tried the same approach, however that did work as a standalone object but not as a subpatch (not sure why)
I also tried other workarounds, such as a flip flop object, but they did not work either. I guess the only working solution would be adding a specific loadbang alike object

The autoreset sends a pulse to the counter whenever the sequencer step exceeds the selected value. I should exclude this behaviour when in backwards mode

#4

we've been discussing both change and counters behaviour at initialisation time, but was too drastic a change to put in 1.0.3, need some time to think it through.

btw your patch does start on 1 for me smile

I also tested the loadbang trick, and indeed doesnt work, which indicates a small issue in subpatch initialisation which will have a look at.
Interesting though, I noticed if you add a +1 object in-between the const and change, it will actually work in a subpatch... the plot thickens.

#5

I updated the sequencer! There are new features such as a latch mode and i corrected the backwards mode issues!

#6

Thanks for the patch, this is very useful grinning

#7

Thank you good sir for this quite fabulous contraption! blush

Step Sequencer with external Input
#8

I like the idea, but somehow the controls do not match the triggers:

trigger 1 sends control 16 value.
when using 8steps: trigger 1 sends control 8, but sometimes control 9

#9

Are you basing on the visual feedback of the ibar object? In this case it could be just a matter of latency (which is not actually a problem of the patch)

I will do some experiments, however. Is the problem related to the trigger thing or does it happen also with the CV sequencer? Did you try moving the sequencer object around in the patch? Errors occur quite often due to the execution order of the patch.

I might also try patching another version of the sequencer, since this was just my second experiment with axoloti (and looking back i might have built something excessively big and complicated for a simple function), in fact building a sequencer from scratch takes just 3-4 objects, with this you have instead to do a lot of patching with dials and stuff

#10

I made my own version now. It also handles a few other issues
It looks similar, but is very different internally

https://raw.githubusercontent.com/allox/axoloti_library/master/sequencer_lx.axs

And made mux_16 object since it seems handy for this:
https://raw.githubusercontent.com/allox/axoloti_library/master/mux_16.axo

#11

thanks for this @Sputnki - decided to start fresh today and ended up with some pretty haunting results. loving all the sequencers that're available!

21216_newpatch.axp (16.1 KB)

#12

Could this be related to order of execution? This happened to me a few times after creating a chaotic patch and then trying to reorganising it. After moving the objects around, to organise, the order of execution had changed. But not sure about this at at all. It just struck me that it could be related.

Maybe try moving the subpatch around in the main patch and see what happens?

Was actually wondering how order of execution is processed when subpatches are in the patch. Does Axoloti load the whole subpatch and all the included objects before loading next object in the order?

#13

subpatches are executed using the same execution order as other objects. so, they are 'called' in the parent according to their position, then the entire subpatch is processed (using the same execution order principles within the patch), then the next object in the parent patch.

and yes, its very easy to get the ordering wrong... and often it doesn't matter, which makes it more tricky when it does :smile:

#14

Cool. That makes sense. Thanks.

Yeah I am not sure about it(order of execution) yet. I checked the tutorial 25. From looking at tut25(object nr 6 is moved only 1 step up and changes the output value of the whole chain of objects) there can be a huge difference from just moving the object one step up or down.

And that kind of makes me think even more that Alex issue could be releated to order of execution.

I guess if you have a really complex patch with a lot of objects it can be hard to troubleshoot order of execution. If it is order of execution related at all :smile:

Anyway, not worrying to much about it.

#15

Most of the time its not an issue...

probably the time it will catch out most, is when the patch first starts.
(the most likely errors, is you expect a value to have been calculated, but due to ordering, it hasn't... so it outlets are unexpectedly zero)

its always a bit tricky to do this with graphical programming environments (unlike text ones, wheres its obvious) ... if you look at Max,PD and Reaktor they all have similar complications.

#16

Yeah. I might have put it wrongly, it is not really an "issue". I guess everything in Axoloti has to be processed in some order. And it makes sense how it does it :smile:

#17

do you have a download for the counterV object? i dont have it and would love to give this sequencer a shot :]

#18

Yeah true. Last night I was doing a little bit of work on a wavetable editor and for that patch, order of executions is very important. moving around some objects has a a huge impact on the phase of the wavetable and how it is displayed in the scope.

Id say for a normal synth lalala thingy, I wouldnt worry about this, but if you are trying to build something very precise, order of execution is very important. And it is something that its necessary to get a little bit familiar with, cause it does matter way more than we think. But I guess it is not the first thing to worry about when getting an Axoloti, but if you are serious about patching, it is neceasrry to learn about it and be aware of how it impacts your patches.

#19

@alex

really cool :smile: Thanks. But I am having trouble with using the version of muxer 16.

Only blue and green versions seems to work. The red, the yellow and the one for using strings do not work.

Some time ago I tried fixing it but with no luck. Did anyone manage to get this working in all versions?

Thanks

#20

This is my experience too... it is actually very important for all kind of patches, but as you say when you start out usually you can 'get by'.

I did discuss this with @johannes the other day, its something where unfortunately there is a 'big step up', and where 'debugging' the patch can actually be pretty difficult at times (e.g. polyphonic patches).
its possible to imagine better debugging tools, but they are all pretty complex to implement... but perhaps one day.
also perhaps we can one day better visualise the chain, reaktor has a mode where it temporarily numbers the execution order, its not great but its something.
also perhaps enforced ordering might be another help, like 'trigger' in pd/max and 'order' in Reaktor

one thing Ive found, quite often I've introduced errors by trying to make my patches look nice,
the biggest culprit is centring objects in the vertical axis. you need to keep the title bars of the object aligned, otherwise you will significantly change the ordering.

the other thing I've been using more, is send objects, these allow you to keep things a bit tidier, whilst enforcing an ordering

anyway, an area that can be improved on , but probably few short-term wins/solutions...
Im sure @johannes has some ideas, and I will at some point mull over it for a bit.