A basic CHAOS script:
#I
CHAOS.R 9500
Y 10000
X 0
M BPM 240
#M
A CHAOS
X MAX X A
Y MIN Y A
Z SCALE Y X 12 24 A
CV 1 N Z
TR.P 1
#1
CHAOS.R + CHAOS.R 1
Y 10000
X 0
Notes:
I just noticed that changing CHAOS.ALG might let CHAOS crash until reboot.
I did not experience this with the test built from the CHAOS thread.
Could you be more specific? Maybe a list of commands required to reproduce the behaviour, and what the behaviour actually is? What do you mean by crash?
This is the script:
M:
CV 1 CHAOS
When I change CHAOS.ALG between 0 and 3 on live screen at some point CHAOS does not output any values anymore. Changing to different algorithms has no effect then either.
EDIT: I just found that while altering CHAOS.R then has no effect either, manually inserting a new CHAOS value brings it back to life. Maybe it is somehow settling at zero and then just stays there?
What do you mean by this? Note that 0 is a value.
It’s reasonable in many cases that if the current CHAOS value is 0, then the next one will also be 0.
Yes, it might be outputting zero but how will I know if it is zero or nil?
What do you mean, ‘nil’?
Maybe we should take this conversation to the CHAOS thread.
I picked this up somewhere and thought it was something in computer language:
nil is the object that means “there is no object”
If you see a 0, it’s a 0. CHAOS always returns a value.
If you want to know why CHAOS(0) = 0 for some values of ALG and R, check the CHAOS thread.
Put another way, Teletype commands that reduce to numbers produce numbers. Commands that do not do not, e.g.: TR.P 1.
CHAOS reduces to a value.
think i see the problem in the alg setter and will do a PR for it
Don’t bother. That might not be the right repo. A bug has already been fixed, unless the problem is in chaos.c.
Won’t be able to fix this until tonight, out for the day.
it is in chaos.c. algo setter should call scale_values, otherwise the new algo runs with inappropriate value/param ranges. i made a PR.
out for the day.
of course, no rush. its stormy here and the power went out for a couple hours. nature break!
@Leverkusen Thanks for alerting us to the CHAOS.ALG bug, it’s fixed in Alpha 3.
Cool-ass rhythm generator:
#I
CHAOS.ALG 3
CHAOS.R 25
CHAOS 63
M 125
#M
A CHAOS
IF BGET A 0: TR.P 1
IF BGET A 1: TR.P 2
IF BGET A 2: TR.P 3
IF BGET A 3: TR.P 4thread recategorized to Development
@zebra: Thanks much for the explanation! Good thing is I can ride this elevator (and read the linked Wikipedia articles) over and over, until I will eventually get it…
The CA is easier to understand for me. Some questions:
When you say “wrapped”, you mean that the leftmost of its 8 cells has a neighbour to its left which is the rightmost of its 8 cells? So that if I want to calculate the next state of the leftmost cell, I have to look at the current states of cells 8, 1, and 2. Correct?
If it would be “unwrapped”, then there is nothing to the left of cell 1. Is it then always assumed (on calculating the next state of cell 1) that to the left of cell 1 and to the right of cell 8 there is always value 0?
I plan to procrastinate the USB Disk Mode interface to spin out CA fro CHAOS tomorrow.
CA.R 123 | select rule 123
CA 63 | set current value to 63
CA | get next value
We can make the set wider, but on teletype, we’ll only be able to access 16 of them at a time, as we use 16 bit integers. What’s musically most useful? 64 cells (= 4 x 16 bit)?
To support windowed operation on a larger data set, we will need to allow the user to access the offset of the window, either as:
For example,
CA.OFFSET 17 | set window offset to 17 bits from MSb position
--- OR ----
CA.WINDOW 3 | get current value at window 3
Additionally, using a window means we need an access operator that does not iterate
CA | get current windowed value
CA.NEXT | get and store next iteration
Who likes the idea of configuring edge mode between WRAP, ZERO, and ONE?
CA.WRAP 1 | set wrap at edge on | looks clumsy, but
CA.ONE 1 | set '1' at edges on | follows paradigm
CA.ZERO 1 | set '0' at edges on |
If we had to prefer one of the behaviours, which one would be most useful?
i took the mildly ridiculous step of making a little c program to do interactive ascii animations of elementary CA. (i want to include these structures in a New Thing anyways.)
you can change the rule, boundary positions, boundary modes, and (partially) the state. might be helpful in getting a feel for the range of things this structure can generate and what parameters would be useful.
[ https://github.com/catfact/cabash/ ]
(ed: oh i guess its linux only now until/unless i work around lack of posix clocks)
some point this week i’ll add OSC bindings and maybe libmonome bindings to make it actually usable for music. and certainly something to save and recall states. maybe other tweaks.
i’d also like try asymmetrical bound modes actually, and add some functions to clear state, set random state, set simple patterns (like a single active cell or an euclidean pattern.)
BTW, i’m not advocating this for inclusion in teletype, just posting in case anyone is interested. if it were considered useful for TT, the relveant functionality is encapsulated by ca.h, ca.c (this includes the features proposed above.) it is not implemented in a very memory-efficient way - cell states are bool arrays instead of bitfields - but that’s easy enough to modify.
Very nice!
Let me know when you’re ‘done’ with it, and I’ll integrate it into teletype.
Or make a PR against my master with those two files added and I’ll start work on the operator code in a local branch.
Heeeey! I thought we were a team!
To spite us both, I did nothing yesterday. 
(Interesting news cycles make me unproductive)