Subpatch: 16 step sequencer

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

#21

+1 for that, i think that would be quite easy to implement and could unveil several mysteries

#22

There is a thread already discussing potential execution order strategies. Just cross-referencing...

#23

Yeah, order of execution is not first thing you dive into :smile: But now getting much deeper into Axoloti and kind of noticing for REALLY precise stuff it is neccesary to take into consideration.

Yes EXACTLY :smile: I have run in to this many times; first build patch which looks like utter chaos and THEN try to clean up.. CLeaning up often changes patch with out adding or removing anything. Only thing tampered with is the order of execution and it changes things :smile:

#24

yeah, perhaps we should consolidate these into a single 'execution order' discussion, I suspect they will come up frequently, as its going to be the most common 'bug' in advanced patches.
I could do with improving the help pages on this, needs a bit more 'meat' to it....

one other observation...
I think the object/wire metaphor encourages you to think of wires as flowing data, and I consciously have to stop this thinking in Axoloti.
(in Max/pd/Reaktor, due to be being event driven, its closer to reality, though still has its pitfalls)

In Axoloti wires have no influence on the order thing are processed in, Axoloti processes objects one at a time, in the order they are on the canvas.
if you remember this, then this usually makes things pretty obvious, but sometimes I do visually find it 'counter intuitive'

I think, perhaps the numbering scheme might work if it was context sensitive.
i.e. if you highlighted an object, and then it number the execution path from there, this also opens up a really nice metaphor for feedback
e.g. number the chain black on white for the same exec cycle, and white on black for the next execution cycle..... the white on black will often be the 'bugs' in the code :smile:

#25

Yeah sure. A button that shows order of execution by numbers would be great. So you always can get a visual on your signal flow.

#26

Hey @Sputnki, how do I patch an incoming MIDI clock (from a drum machine, connected to the MIDI in din in the axoloti) to drive your sequencer16? I am currently driving your seq16 with a square LFO, but what if I wanted this to synch to a drum machine? Thanks!

#27

I think you should check @DrJustice sequencer, is far mor advanced and lighter than mine (and has midi sync)
My sequencer reads incoming trigger pulses, so you should derive a trigger pulse from midi/in clock 24ppq, maybe using divremc and then logic/change

#28

Thanks, i changed the sequencer but I still am unsure how to do this. The drj/seq/stepseq_16_pitch, for example, has an out for pitch only. I need also a gate (boolean signal) generated from the midi clock to trigger the synth.

#29

Check his example patches! They are in contrib/patches folder, and are quite explicative.
His sequencer is really a lot deep, and if you learn how to use it, it can become a truly powerful tool.

Load one seq_clk_sync (you have to learn how to use it, of course) and use it as a source for gate and "position"

#30

Thanks, [edit] I just found out how the clock source can be selected. Cheers!

#31

No idea if already in discussion, a "single" sequence input and a "next" output could make the patch cascade-able, which would be great if e.g. used with different step numbers. Logic combinations, gates, counters etc. between the patches could allow many melodic pattern alterations (which could be triggered e.g. from midi notes or events).
You also should make a tutorial how to make such great patches! Thanks

#32

Hey @Sputnki :slight_smile:

I really like the muxer 16 you have made. I use it a lot, mostly K-rate version.

Today I tried using the S-rate version, but that one doesnt work. I get this error. I have been lookin in the code, but unfortunatly I can not find any errors to fix....

Could you please take a look at it and tell me what you think?

Actually I think also think the ones for filenames also doesnt work. I get same error for both of them:

Users/jakobskouborg/Documents/axoloti/build/xpatch.cpp:77:62: error: expected ';' before numeric constant
case 10: outlet_o[buffer_index]= inlet_i1[buffer_index]0;break;
^
/Users/jakobskouborg/Documents/axoloti/build/xpatch.cpp:78:62: error: expected ';' before numeric constant
case 11: outlet_o[buffer_index]= inlet_i1[buffer_index]1;break;
^
/Users/jakobskouborg/Documents/axoloti/build/xpatch.cpp:79:62: error: expected ';' before numeric constant
case 12: outlet_o[buffer_index]= inlet_i1[buffer_index]2;break;
^
/Users/jakobskouborg/Documents/axoloti/build/xpatch.cpp:80:62: error: expected ';' before numeric constant
case 13: outlet_o[buffer_index]= inlet_i1[buffer_index]3;break;
^
/Users/jakobskouborg/Documents/axoloti/build/xpatch.cpp:81:62: error: expected ';' before numeric constant
case 14: outlet_o[buffer_index]= inlet_i1[buffer_index]4;break;
^
/Users/jakobskouborg/Documents/axoloti/build/xpatch.cpp:82:62: error: expected ';' before numeric constant
case 15: outlet_o[buffer_index]= inlet_i1[buffer_index]5;break;
^
/Users/jakobskouborg/Documents/axoloti/build/xpatch.cpp:83:62: error: expected ';' before numeric constant
default: outlet_o[buffer_index]= inlet_i1[buffer_index]5;break;
^
make: *** [/Users/jakobskouborg/Documents/axoloti/build/xpatch.bin] Error 1
shell task failed, exit value: 2
Compiling patch failed ( untitled )

Any ideas?

THanks, Jaffa

#33

Jakob did those objects, i made a very complicated mux system for the sequencer that relied only on factory objects.
Did you try looking in the community library if anyone did some mux 16 object?

#34

Ahh you mean Alex. Sorry I didnt watch the thread careful enough.

@alex Did you test the muxer 16 that you have created in S-rate version?

I have used it a lot at K-rate and that works, but the S-rate version doesnt work. I cant seem to locate the error. See the error I posted a few posts ago.

Jaffa

#35

Woa! Can this be used as an arpeggiator?

#36

I guess you can, it will be qute awkward to use as a midi arpeggiator, though.