Also, 999 is sometimes getting set as the N value in line 1 of your pattern. Maybe rework the script so that it is never set by getting the pattern value and then checking it. I like using negative numbers for rests so I can check them using GTE.
Here’s an idea where probability would be that we would or wouldn’t execute the rest of the script. I didn’t test this, so let me know how it goes.
PARAM.SCALE 1 100
PROB PARAM: BREAK
A PN.NEXT 0
IF GTE A 0: JF.VOX 1 N A V X
ELSE: JF.VOX 1 N 0 V 0
thank you! love the negative values as rests. i wanted to change a few things:
i changed BREAK, which was stopping the script altogether, to just bring the voice’s voltage to 0 so that the sequence would continue uninterrupted, the voice just wouldn’t sound. more like adding rests than stopping the sequence.
changed the scale to 0-50
added another sequence that was inversely affected by PARAM, so that when one voice was mostly rests the other was mostly notes.
PARAM.SCALE 0 50
PROB PARAM: X 0
A PN.NEXT 0
IF GTE A 0: JF.VOX 1 N A V X
ELSE: JF.VOX 1 N 0 V 0
X 4
PROB SUB 50 PARAM: Y 0
B PN.NEXT 1
IF GTE B 0: JF.VOX 2 N B V Y
ELSE: JF.VOX 2 N 0 V 0
Y 4
i think i’m going to post a recording in the JT Explorations thread shortly!
That’s a really good idea! (or has given me a good idea if its not what you are getting at) You’re kind of cross-fading between sequences based on the probability that a value would come from one sequence or the other.
when setting up teletype to run slowly shifting percussion trigs, is it better to program everything into the pattern tracker, or is there some combination of EVERY, DEL, SKIP, etc that i can use to get a note to play only on certain intervals? e.g. mostly offbeats, such as within a given 16-beat bar, only on the second-to-last (15th) beat. or only every X, such as 17 or 31 beats across two 16-beat bars. and in some of those cases, TOSS a coin to decide the probability that it plays at all on that beat, or even if it’ll play on a small RRAND of possible beats/times.
the idea behind this teletype percussion, which backs a steadier/grounded set of 4/4-ish beats playing via meadowphysics, is continual tiny organic variations over time. i’m having some trouble doing it all in a reasonable amount of script lines; i’m wondering if it’s just better to program a basic pattern in the tracker, and then do the more complicated probability & time-shift logic in scripts.
if this was done in renoise, i’d use dozens of individual arbitrary-length bars+patterns to manually program in every little variation, but teletype needs a different approach. i also want to be continually surprised, just a little bit, by constrained random variation.
On Teletype I usually prefer building rhythms via logic (and maybe random) over entering them manually.
Here’s one I just threw together:
M:
A % + 1 A 16; B 0
L 0 3: $ 1
PROB B: TR.P 1
1:
T * 5 - 4 I
B + B * T BGET A I
Each beat has a different probability of triggering (0% to 50%) based on which bits are set in the beat count, with the weight more on least significant bits to spread out the pattern. You could change the “5” to change the overall probability as well as the weighting, or subtract a bit from B, or whatever
can someone help me understand how to use XOR with teletype?
my goal is to have scripts 1 + 2 pulsing outputs 1 + 2, but run a manual gate into script 3 to on/off XOR logic between the two scripts. the XOR result should determine whether or not output 2 fires a trigger.
haven’t used logic stuff in TT before. any help wrapping my head around it is much appreciated
TR 2 will pulse if TR 1’s output is low. the problem i’m running into is that this script and TR 1 are being clocked at the same rate - so this script needs to be slightly delayed in order to catch TR 1 in a high state. as it is, when the XOR script is run seems to check in right before TR1 goes high, so it returns 0. to double check this i manually set TR 1 to 1 and ran the script - it worked as expected.
any ideas on how to do this without using a delay? i’d prefer to keep timing as solid as possible as this is part of a rhythm generator idea…
Sounds like you’re close. To avoid delaying the rhythm, maybe create a variable to set, delay, and reset in one of the trigger scripts. The delay will depend on how many milliseconds you can work with in your tempo and it can be longer than the pulse time. Here’s a rough idea (not at my teletype):
A 1
TR.P 1
DEL 40: A 0
Then check the A variable in the other script instead of the TR output.
The other thing that is interesting is that the XOR op is an alias for an equality test, which in this case really simplifies how you can look at it.
Thanks for the help. Unfortunately it’s not that variable A needs to stay at 1 longer, it’s that it needs to be set to 1 right before my second script checks it’s state. It seems that even though both the setting and the checking are happening simultaneously, the setting actually happens right after the check. Sorry if that’s confusing - having trouble finding the right way to word all this…
Can you describe the trigger source and how it is triggering scripts 1 and 2? Same time always or different? The trigger source would also complicate things too since the actual trigger signal could vary by a small number of milliseconds. As @jlmitch5 is saying - a race condition (I like that idea of calling the script from the other script).
Maybe you could put some of the logic together in script 1 and use script 2 and 3 to set variables that would be evaluated in the right order.
Basically the triggers may come in at microscopically different times (or maybe the code for detecting doesn’t necessarily process things in exactly the order they come in—batching things may allow for performance gains based on how it is architected.
If you are relying on one clock source and explicitly call things synchronously, the chances of this sort of race condition is a lot less.
This is good in that we know that script 1 and 2 are triggered consistently. The behavior should always be the same.
You could experiment with setting that A variable to 1 right before calling one of the scripts in the EVERY line, then delay and set it back to 0. This way you should have more control over the order.
this is basically the equivalent to running a clock divider into a XOR logic gate, yeah? TR.1 + 2 should alternate pulses?
yeah i’ll have to look into that.
this is just a piece of a larger “controlled random” scene i’m working on that involves multiple divided clocks all running some IF logic on stored patterns, which then are XOR’d to each other to prevent them from stepping on each other… so there’s a lot going on already
i’m testing this XOR logic in isolation with the hopes of landing on the most minimal, efficient implementation.
as i understand - since i’m already using IF statements, i can’t double that up with a delay, yeah? using most of my scripts so i can’t split IF and DELAY very easily.
The surprising thing to me about the XOR op is that it is an alias for the ‘not equal’ op.
NE x y
This means that it might not give you what you’re looking for in alternating behavior where exclusive or would usually mean ‘one or the other, but not both’. I think you’d have to add an XOR check to script 2 and maybe a 2nd variable to get this alternating logic since script 2 should check if trigger 1 is active.
i think i follow what you’re saying - but in my case i want the slower clocks to have priority. so for example the 1/4 note channel will never be stopped by the 1/8th note channel and the 1/8th note channel will never be stopped by the 1/16th note channel, etc.
