#127

in case it is interesting, i updated the cabash sequencer (linked above)

algorithmically:

  • can set asymmetrical bound modes. this turns out have interesting possibilities; by fixing one side and wrapping the other, i’ve seen “stable” behavior on one side that “flows” off into a virtually infinite field on the other.

i think that pretty much brings this to “completion” in the sense that i can’t think of any other parameters you can really add to this (very simple) structure. i have few opinions to what params should/shouldn’t be included in a TT op. but a sliding output window of 16 cells seems like an obvious choice. probably don’t need full control over the bounds.

also added some features that have no little or no bearing on TT but do make this thing usable for computer music:

  • sends an OSC message on each update, containing the complete cell array. (sends to supercollider lang port on localhost, by default)

  • OSC destination, rule, bounds mode, bounds positions, and speed can be specified in a configuration file at startup (actually a lua script.)

  • added a “patterns” module that initializes the state with randomness, emptiness, single cell or other simple patterns in response to keypresses

if you want to use this code i’d just grab ca.h and ca.c. replace bool arrays with bit manipulation if reducing static memory by 8x is worth, um, 2-4 extra operations per cell, per update.

might try this thing at audio rate, with interpolation, as a massively multichannel oscillator.

3 Likes
#128

What’s the current status on the alias? Can I suggest that we hold off giving it one for now, especially if it’s a symbol. It’s easy to add an alias later, but it’s hard to take it away once it exists already.

3 Likes
#129

No alias yet.

@zebra amazing! I’ll start sewing this into teletype. Given how good CA mode has been for rhythms already, I look forward to these new edge modes.

2 Likes
#130

it seems CA.OFFSET has a wider use than fixed CA.WINDOW positions (which would be equivalent to CA.OFFSET with multiples of 16, right?)

the edge mode config seems awkward?

otherwise i’ll defer to those closest to this functionality (ie @zebra)

1 Like
#131

It follows the mode change syntax of the turtle fence mode, but I agree that it looks clumsy.

#132

cool, no problem then.

1 Like
#133

offset seems important and immediately useful. “scrubbing” the offset will give you immediate gratifiction.

bounds mode, i’m not so sure. main reason i made the standalone thing is to investigate. there are some possibilities in there but i dunno about parameterization. here are three options:

  1. no parameter: just fix the bounds to one behvavior. i’d suggest both fixed low for “classical” results.

  2. one parameter: have 9 (?) different settings for bounds:

  • wrap / wrap
  • wrap / lo
  • wrap / hi
  • lo / wrap
  • hi / wrap
  • lo / lo
  • lo / hi
  • hi / lo
  • hi / hi

or i guess just skip the symmetries / inversions and have wrap / wrap, lo / hi, lo/lo and lo / wrap.

  1. two parameters: 3 values each.
2 Likes
#134

gratifiction!

///////////////
(20ch)

2 Likes
#135

This one gets my vote.

1 Like
#136

Hmmmm…

If the total data set is N 16-bit ints, complete initialization of the population takes 2N commands, or a loop.

For example, with a 64 bit population,

L 0 3: CA.OFF * 16 I; CA 21845

Should there be a shortcut for this behaviour?

#137

i dunno, sure - i made these “pattern” commands in the cabash cause i thought they were convenient:

1 Like
#138

If I enter a value somewhere above 10,000 on CHAOS.R, the CV value will continue for about 4 or 5 triggers after hitting F10, after that the CV stops changing value.

If I then change from say CHAOS.R 12000 back to CHAOS.R 500 the CV remains silent until I go through a INIT and start over. I want to verify that I do indeed press F10 between value changes and that for values under 10k I don’t have any issue with CHAOS.R

#139

Just to confirm, has CA being spun out of CHAOS been put on hold?

1 Like
#140

caveat: i don’t generally contribute to the TT code, and specifically really have no time right now.

but since i am responsible for the algorithm i double checked with the simulator and it works as expected.

param value is clipped at 10000, setting it higher won’t do anything different.

these are chaotic iterated maps, their behaviors are sensitive to the initial state.

the default map is the logistic. it has degenerate single-value orbits for many initial state values and parameter values. in particular, setting the state to zero will cause it to output zero forever, regardless of the parameter value.

so my current best guess is that you are setting the state somewhere in your script (CHAOS N)

as ever, it is probably most helpful to post more of the script

my test is simply

CHAOS.R 10000   (or 12000 or whatever)
CHAOS
CHAOS
CHAOS
...

that has a very long orbit, as expected, with the default intial state value of… looks like 5000.

if i ever do CHAOS 0 then subsequent outputs will be zero as expected.

i can also get it to go to zero with some other state values and the param maxed. i think technically this shouldn’t happen in an ideal logistic map, but it’s not really surprising given that there is inevitable rounding error even using float32 for the internal state.

i don’t know about the decision re: separating CA and CHAOS. it is purely a matter of taste and usability but seems like a good idea. sounded like it was being pushed to a future point release which is perfectly reasonable.

#141

The extent of the script is this:

I: CHAOS.R 275 // 2.75
M: CV 1 CHAOS
1: TR.P 1

I have a clock in trigger input 1

So here are more details, I set CHAOS.R 10500
Teletype is no longer outputting CV.
I change CHAOS.R back to 275 but the CV will not restart, I wait…nothing
I try another value…nothing
I try INIT which apparently clears everything
I reenter the script and while the trigger is functioning I get nothing from the CV and am forced to power cycle the Teletype and everything else in my rack.
I reenter the script and set CHAOS.R 9500 and everything works as I would expect.
Set to CHAOS.R 9999 everything works
Set to CHAOS.R 10001 and then 10100 and things are fine
Set to CHAOS.R 10500 and again CV “dies”

Now, if I type INIT and go to script 1 and enter:
TR.P 1
CV 1 V 6

The CV changes on my oscillator. Seems like the CV is back to working order.

So I enter my script:

I: CHAOS.R 275 // 2.75
M: CV 1 CHAOS

And CV is non functioning, forced to power cycle.

#142

ok, thanks.

i see the problem. the bounds check on param for logistic is missing. my apologies!

(so param values >10k are not being clipped and are blowing up the algo. somehow i was checking things like 15000 which actually produces reasonable patterns, but 10001 is an exploder.)

if the op does blow up or get stuck in a steady state that you don’t like (which could well happen) the thing to do is to reset the state with something like CHAOS 5000 (anything nonzero will work.) you should not ever have to powercycle because of this, and the CV isn’t “dead” it’s just fallen into a repeating value.

@sliderule, i’m finding it non-trivial to figure out the current state of forks and branches in order to PR. but the fix is pretty trivial so here is a 2-line patch against catfact/chaos:

chaos_param_range_fix.patch (468 Bytes)

1 Like
#143

I’m trying to help with documentation and would like to understand the various algorithms regarding their x values, such as CHAOS x and CHAOS.R x.

What are the ranges of values per algorithm for CHAOS.R? Such as does the Henon map benefit from different values than the Cubic map?

Same with the CHAOS x values per algorithm?

#144

thanks for the help!

mathematically, the underlying ranges are:

for cubic / logistic, x in [-1, 1] and r in [3.0, 4)
for henon, x in [-1.5, 1.5], r in [1, 1.4]

in teletype code, the parameters are always in [0, 10000] and the state is always in [-10000, +10000]

the “true” param and state ranges are chosen kind of arbitrarily, such that the algos do more “interesting things” (e.g. long periodic orbits) than “boring things” (e.g. converge on a value and stay there), and they stay bounded instead of blowing up to +/- infinity.

for more details i must refer you to the many words i’ve written further up the thread.

1 Like
#145

Would you be willing to share for possible inclusion in the documentation the script you wrote for this piece called, “Grateful FM Jam?”

#146

I don’t think that I kept it. It was just an experiment and probably did not contain more than described in the post plus the usual stuff you need as some clock signal and CV/TR output operators, maybe a quantizing scene. I think I used a pattern filled with some scales around that time.

1 Like