Hi all, another little unit for y’all. This is a very simple eight step sample trig sequencer. I think it’s been done before, but this is my personal stab at it for Firmware 0.4
The unit does come at a cost of around 45% CPU usage, which I think is a lot (and probably means that it’s better done with a separate module). Especially because I had hoped to use several of these to get some interesting rhythms going. It’s just a whole bunch of VCA’s and bump scanners. Luckily the routing of 0.4 brings some advantages in terms of re-using signals and routing the sample to several mixer channels at once. Anyway, I would LOVE to hear some feedback, especially if there are routing and CPU improvements to be made!
Usage is pretty straight forward: There are two custom controls up front labeled “clock” and “reset”. That should be self-explanatory. Then there are 8 toggle controls that turn a step on/off. Any custom sample can be attached to the sequencer when you jump one layer down and hit “Enter” on the “Select sample” unit. That’s it. Have fun!!
Another version of this unit, without the sample player. So this is just a trigger generating unit you can place anywhere you need it. TrigSeq-8_adsr.unit (79.4 KB)
In an attempt to reduce CPU usage I got rid of the slew limiters I needed for the sample player, but then I needed to add ADSR units to generate as short as possible triggers. In cases like this (where you need many instances of one unit) it would be great to know which units have a bigger impact on the CPU. I remember there was a discussion about this somewhere… Oh yes, this one? UNIT DSP Usage Chart or better way to show DSP usage
Would @joe know this by any chance? For example, Slew limiter or ADSR unit, which one is heavier on the CPU?
I think the cheapest way to create triggers is with a Comparator. I think Joe made one and there is a comparator in every gate control. Each comparator has a settable threshold or you can use offsets for dynamic control of the triggering threshold. Triggers created by comparators are 1 sample in length.
The basic idea is to set the trigger thresholds for each comparator progressively higher such that each triggers at the correct time when driven by the output of the internal counter. The trickiest one is the first step which actually needs to trigger when the counter wraps (i.e. falls) back to zero.
That is amazing. I just used your unit as a template to build an 8 trigger version and it’s not even 13% CPU usage! That does give perspectives. Only problem I have with this guy is the last step is not triggering for some reason. In the counter I have a gain of 0.125 but I can only get the comparator to trigger up to around 0.85, any higher and there is no reaction. That’s the second before last step so 7 and 8 are either triggering at the same time, or 8 is not triggering at all. Any idea why that could be? 8_triggers.unit (45.6 KB)
However, your description above does not match at all what was wrong with it. Step 8 was fine. It was the steps 2 through 7 that were acting inconsistently because you set the threshold on those steps to exactly a multiple of 0.125. You need to make each threshold just slightly lower than the target counter value (say by 0.05) so you are guaranteed to go through the threshold and get triggered.
TLDR: The Compare unit triggers when the input is greater than the threshold, not greater than or equal.
Aah, yes that makes sense. Thanks a bunch for taking a look at this. I realize this is not actually your job, and I should really not compromise development time! But still it’s such an amazing opportunity to learn from the source of truth himself Thanks!!
I find debugging a unit harder than it could be because of jumping back and forth between settings and unit, subchains and so forth, as opposed to looking at a script where all the data is right in front of you. Maybe I should get into bespoke unit programming. Oh dear
Anyway, folks: the most CPU efficient and working 8 step trigger unit is here 8 step Trig Sequencer unit and all credit goes to @odevices This is v0.4.11 and CPU at around 13%.
EDIT: I’m still testing the unit and so far results are a tad inconsistent. Let’s put the definite 8 trigger sequencer on hold for now and keep debugging
After some more testing and tweaking parameters I think this unit is a wrap. The threshold parameter is the most important part and there were some values that didn’t stick leading to unregistered steps. Now every step triggers correctly as far as I can tell, and yes still at a wonderfully frugal 13%.
One important point if you’re going to use several of these units or sync it up with other stuff, is don’t forget to use the reset input. The tempo will always be right, but the starting point seems absolutely arbitrary, so just connect both reset input to one and the same trigger, fire it once and you’re good to go (or connect it to a global clock divided by eight).
Without further ado, the definite 8 step sequencer for v0.4.11 8_triggers.unit (45.3 KB)
Not sure if you mean something like this? I just hit record while I was toying around with two of these 8 triggers sequencers for snare and kick with two melodic sequences from O_c. The lightweight-ness of the trigger sequencer is great because now I can have two of them + a complex oscillator + delay and I’m still only at 59% so it’s very manageable.
Haha, maybe I should give it a go. Although this trigger thing would be a stretch I think as a first experience Is it like that though? Do you feel like you have a good overview of the patch in the lua? Debugging is still going back and forth in the ER-301 of course.
Yeah, I’d say so. Some of it is a factor of using good naming conventions, comments as needed, and of course just being familiar with the SDK.
The biggest challenge of the middle layer, I’d say, is that you can’t really inspect any of your internal signals - they’re all hidden away. Once you deploy to the 301, you can only see the unit output, unless you temporarily re-code it to connect some interim signal to the output for troubleshooting.
I would start with something super simple that you can prototype 100% in the UI layer and get working, and then convert that to a bespoke unit. That way you at least know you have all the right bits and pieces and they’re connected up right.
Yes I am sure I want to continue this old conversation, thank you Discourse. The reason being, a whole while back @Joe slipped his bespoke lua version of this unit to me, under the table, full of helpful comments on how he built it, as a way to nudge me on the way to build my own bespoke units (how sweet is that!). I wanted to share it when I had something to show for myself, and when I made a proper demo video for it, but it’s been months and I procrastinated, so right now I just want people to use this very cool little tool in their patches. And I will do a demo, and get to lua programming when I get there. Only credit to me is for naming it Punchcard and putting it in a folder with a fresh init.lua. Thanks for this Joe, I’m using it quite often actually.
This is the library, you can put it in your libs folder in the ER-301 folder on your sd-card and the unit will show up in a new category “sequencers”.