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
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
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 
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.
I updated the sequencer! There are new features such as a latch mode and i corrected the backwards mode issues!
Thank you good sir for this quite fabulous contraption! 
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
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
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
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)
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?
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
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
Anyway, not worrying to much about it.
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.
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
do you have a download for the counterV object? i dont have it and would love to give this sequencer a shot :]
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.
really cool 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
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.
+1 for that, i think that would be quite easy to implement and could unveil several mysteries
