Trig Conditions are awesome, and I must admit, much more flexible than I initially thought.
However, I can think of a few that I would love to see added :
Unrepeatable probability : just to ensure that they NEVER happen twice in a row. That option could be available for probabilities less than 50%.
Parameter lock probability : a chance that the parameter locks happen. It would be either all of them or none, of course.
if something chance related has logic like that, then its going to be predictable.
you already can spice things up with LFOs quite a bit.
square lfo in hold can mimic trig on/off, while random lfo can modulate speed of square lfo, for example. one downside is that you are giving up 2 lfos for this, but id imagine high uncertainty is most useful on short/percussive sounds, so it works out. (+ theres loopback for the crazy ones)
trigless trigs are basically that. you can plock something in the step prior, and set separate probability to it, ensuring that lenght is covering desired amount of consecutive steps.
Just adding some clarity (from MY perspective) here
this isn’t as simple to implement as it is to imagine … with what we have already … it implicitly needs a log/memory which it does not reference presently … the current trig evaluation is based upon bigger counters (bar number or last trig or last previous trig on lower track number) … small arrays basically, it’s not the same to have logs of a (number of) individual trig’s last states
parameter locks activation/deactivation would need a third state for a trig to be … i.e. on/off/part-on … but the means to evaluate/log are distinctly binary in implementation … so the trig itself can be on or off, again it’s an easy (and desirable) feature to envisage, but it’s a fundamental change in terms of how the whole TRC things is operating
It’s also quite flexible with exploits of the current tools, so it may be worth looking at what they can do rather than what is missing on first examination
doable/realistic ideas do get adopted, but i think it has to be a suggestion that when read it scans like there’s no downside, it’s elegant, consistent and useful and easy to incorporate and easy to exploit for the user etc
My main problem with % probability is it always feels the opposite of random and positive triggers clump together far more often than they spread out, limiting their use.
What I really want is two levels of(or stackable) conditions, then I could have one set on a regular 1/4 for instance and the other on a %, adding an extra trigger randomly but keeping some consistency.
I agree, things have to remain super clear and should not populate the UI too much. I’m certainly aware that there might also have technical limitations. Just brainstorming !
This can work, thanks. With the downside to sacrifice one step.
I think it works just as it should. But straight probability for each step is not always very musical indeed.
Do you think a 9% probability should go 20 passes with no trigger and then 5 in a row?. Big gaps are fine but the multiple consecutive hits shouldn’t happen anywhere near as often as they do with such low probability, pretty sure it would take an awful long time to roll the same number 5 times in a row with a 10 sided dice.
The ability to combine certain non-contradictory trig conditions, e.g, 7 of 8 with /fill. Currently you can’t have a step trigger as a /fill note and also have it as played as the 7 of 8 step which is a pretty silly limitation.
I’ve sometimes wished I could do the inverse of the N:N conditions, for example where 3:4 means play on every bar except the 4th.
And not really a trig condition, but I would love the ability to retrig conditionally. Not the same as mixing probability on a step with retrigs, but having a step play normally but retrig like 9% of the time or on any other trig condition. Maybe an extra parameter in the retrig menu so we could have the best of both worlds, for example a step happens only 2:4 and ratchets only every 8:8 or 9% or whatever.
Honestly I’d love to see Elektron introduce a new paradigm to their core sequencer algorithm. I recently acquired a Cirklon and while it doesn’t have straight up trig conditions, you can actually accomplish a lot of them through their aux event and accumulators concept. Not that I’d want to see that exact concept implemented in Elektron gear, but the idea of having advanced programmability via an event list available on a per step basis would be amazing. Things like alternate pitches happening at certain probabilities or conditions (e.g. a step set to C# that plays D# 17% of the time), ability to define either a range or discrete set of values for note, length, or velocity or hell - ANYTHING that the sequencer could choose randomly from or round-robin through (so you basically define a list of values for the step and then set if it’s random or sequential).
Sorry I guess I’ve gotten off topic in an on topic way? Should maybe move this to the Elektron all devices feature request thread.
I’m a little new to Elektron - finally caved-in and bought a Syntakt. Perhaps there’s alternative ways to achieve what I’d like to see? Let me know.
I would like to see:
‘A’ and ‘B’ parameter lock states that can be assigned independent Trig Conditions. e.g. ‘A’ could be ‘normal’ or unaffected, and ‘B’ a parameter lock only triggered on 8:8
Dominance/Probability assignment to ‘A’ or ‘B’ to prevent clashing of Trig Conditions; globally set and at the trig, with trig dominant over global.
I like this idea, would go a long way in spicing up a track with minimal means!
Seemingly simple request: I‘d like to be able to choose from all of the available trig conditions as default for a track. Right now, you can only set percent chances for a whole track. I would often love a quick solution if, for example, I want a track to just play every third bar. It’s not an exotic use case but takes some tedious programming right now that kills the live flow.
I sometimes want a whole track stretched across several bars to just play every third/fifth etc. time. As soon as you have longer tracks and length per track settings, you would have to set every trig to say 3:3 manually. And adjusting sequencer resolution also doesn’t work with much stuff because of maths etc.