I have been giving this a lot of consideration lately, and I thought I had figured out a solid way to do a simple drum beat to start and then I would build up from there. I don’t like the randomness, which is all I have been able to achieve, other than having all drum sounds hit on the same beat. So I built this with the 16 step seq module, and as you can see, what I meant to happen is for a bass drum kick, then a rest, then a snare, and finally a cymbal, then repeat. I’m still learning, and I’m not sure yet about the best way to do things, but this seemed more clever and home built than routing sound in from another app for my drums, but I am starting to think that may be all I am able to do, at least until I can figure out how best to imitate a drum beat like I would set up on the MIDI editor of LPX. I am sure there are modules in the library that can help with this dilemma, but using prebuilt patches is difficult for me because I have found a lot of them lacking documentation, or I find myself struggling to understand why the math expressions or routing of the signals used in the patch(es) make it do what it does. I don’t typically like to work with things I don’t fully understand. Can anyone offer help, advice or suggestions about how best to attack this situation? Thanks!
Drum Pattern Attempt.audulus (430.0 KB)
I’d recommend starting by making a strip of triggers for each drum sound. You can do this pretty easily with the seq 16 node or some mux nodes. You basically have toggles on each of the steps and you multiply the seq 16 output by the clock input so that you output a gate on triggered steps.
Drum Pattern Mutant.audulus (968.4 KB)
The Know Your Nodes videos on counters, switches, and clocks probably have some useful bits you can put to work making your Audulus masterpiece.
Thanks @robertsyrett! I have watched all the know your nodes videos a number of times, and I have learned a lot from them, however, I haven’t yet figured out how to use them all in my own patches, so I guess all the info hasn’t fully absorbed yet. So if I mux -> demux, and then do my routing to the drums I intend to hit, it should work then? Also, this is where my lack of the math understanding comes in - why do I have to multiply the output by the clock signal? There are so many different instances of math equations that make patches do all kinds of beautiful black magic wizard that I amazed and envious of others’ understanding, as I don’t yet understand, and even tried studying some of the basic trig functions and expressions you mentioned to me in our discussion, but I guess because I don’t understand where they are to be used or what the purpose they serve, I have trouble retaining the info. Anyway, back to the multiply of the clock thing, shouldn’t it be outputting a 1 or a 0 to begin with?
Oh also, do you happen to know why the expressions I used in the previous patch didn’t work? According to the logical analysis I did and then triple checked, there shouldn’t have been any overlap, and therefore, shouldn’t have been any drum hits simultaneously…perhaps there is something I missed or a concept with which I am not yet familiar, as far as the way the input signals or the way the seq16 works? If you don’t know, no worries, I’m just curious and eager to learn as much from this lesson as possible.
Yep, although having a sequencer for each gate input allows you strike all three on the same step. But if you wanted a knob that chose what happened on each step it might look like this
mux to demux demo.audulus (283.6 KB)
so that you are turning on and off the trigger. The on/off signal on its own would only trigger the drum when the gate went high.
unmultiplied demo.audulus (17.2 KB)
Probably the a<x<b ? 1 : 0 needed rephrasing for the syntax to be properly understood. a<b ? 1 : 0 is the same to the computer as a<b so we can ditch the if then else stuff. Next clarify a<x<b to something with ironclad operators (a<x)*(x<b).
Drum Pattern simplified logic.audulus (430.0 KB)
I synced some of the oscillators in the drum machine:
It restarts the oscillator with the gate. Otherwise the oscillator runs free and it will start at a random value when the envelope triggers.
There’s a button you can test to see if that may be part of the problem.
edit - added to simplified logic
Drum Pattern simplified logic sync.audulus (433.1 KB)
Re-did the logic different. With sync buttons inside drum machine.
edit
x>=0.333*x<0.666
- account for 0.333 exactly
Drum Pattern 3rd logic sync fix.audulus (434.5 KB)
- added clock width control so you can retrigger on the same drum type
Drum Pattern 3rd logic sync width.audulus (436.6 KB)
Numbers in Audulus are 32 bit floating point values. Watch out for rounding errors. Avoid checking for an exact value if possible. x>=0.333 is fine, but you could run into trouble with x==0.333. Also, the values displayed by the value node are not displayed at full precision. I’m not sure if they’re rounded or simply truncated, but it’s entirely possible to have two nodes displaying the same value that won’t evaluate to equal. Also watch out for the order of execution. Multiplication and division are higher priority than comparison operators so they will execute before the comparisons:
I think you probably meant (x>=0.333)*(x<0.666)
Hey thanks for the replies, everyone! This has helped me to learn a bit more. I hope to be able to problem solve my way through these kinds of things and build really neat tools like all of you have done/do currently. Someday… 