In teletype world we work in 16 bits, so I could see that being the “window”, with a parameter for an offset into a larger data set.
#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
- X is the maximum value
- Y is the minimum
- Z automatically scales to 1 octave
- 1 script advances R slightly
- CV 1 is pitch
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:
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 4
*nested* + less concepts: album + cellular automata sequencer (norns, Mac)
How do you all use random, chance, and accident?
thread 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
Initial Proposed Operators
CA.R 123 | select rule 123 CA 63 | set current value to 63 CA | get next value
Larger Data Set
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:
- Number of bits relative to MSb or LSb
- Number of words (16 bits) relative to MSB or LSB, i.e.: its window number
- This effectively limits the range of the offset, which might be musically limited
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.
(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.
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!