ok i’ll give it a shot…
logistic, cubic, and henon modes operate internally on bipolar floating point values; the first two use [-1, 1] and henon uses [-1.5, 1.5]. so their output needs to be rescaled to be useful in the fixed-point numerical universe of teletype.
the actual output range at any given time is dependent on the intitial state and the parameter settings. these are chaotic functions and so the whole point is that i can’t easily tell you what a given output range will be for a given configuration. but i can guarantee that as implemented, they will always be in [-10000, 10000].
for cubic/logistic i can prove that this range will never be exceeded, and that there are many orbits that closely approach those bounds. the henon is a tougher analytical nut to crack, and i am sort of eyeballing it and hard-clipping the output if it exceeds those bounds.
if you use low param values for logistic and cubic, you will see pretty steady output values for logistic, and steadily oscillating output values for cubic. cubic will change sign on each iteration; logistic will always have the sign of its initial value ( i think?) ed: no! i was wrong. i think logistic always blows up to -inf if initial state is negative. @sliderule this should be fixed in the implementation; clamp negative initial values to zero.
for henon it’s a bit more complicated (check out that crazy bifurcation map.)
why does only the cellular automata offer a 1:1 relationship between input values (0-255) and output values (0-255)?
because unlike the others, the CA algorithm doesn’t operate on floating point numbers. it actually operates on binary arrays for both the state and the parameter. in this implementation i’ve encoded these as bits in an integer (which is standard practice.) we could of course decide to scale them but i think it’s more useful not to. this way, if you understand how the structure works, you can get specific behaviors by setting known rule and state values.
and if we get bitwise operators, then you will be able to map individual states of the CA (bits in the output) to gates. which IMO is a really awesome musical application of this mathematical structure.
please see here for background on 1d binary CA (also called elementary CA):
http://mathworld.wolfram.com/ElementaryCellularAutomaton.html
It would be nice to have the range starting at 3.0 to include the first branch on the logistic and cubic maps
ok, here’s the line to change:
[ https://github.com/burnsauce/teletype/blob/chaos/src/chaos.c#L50 ]
I find it a bit hard to guess where on the logistic map (i.e. the Feigenbaum digram) I am. Is there some easy maths to calculate this?
i don’t think so. that’s why determining the behaviors of iterative functions like this, directly led to the birth of numerical modelling. analytically, we can show things about the output bounds and the phase space (inductively), but it’s hard to predict a specific orbit without just calculating it.
the equations are simple, so it’s pretty easy to calculate where you end up after N iterations from any given starting configuration, with just a few lines of code in any programming environment. i guess that’s what i’d do.
so given that, i agree that it would be nice to always have a simple relationship between the fixed-point and internal representation of state and parameter.
i should point out that even small differences and errors in floating point implementation will lead to big differences in the orbit results. in numerical modelling work i’ve often seen significant discrepancies between different platforms. i think in this case it might be especially extreme if we are compiling with -mfast-float or such.
which is just to say, you can make a python one-liner to estimate the orbit for a given [state, param] value. but don’t be surprised if the estimate diverges from the TT implementation; it does not necessarily imply a programming error.
I see that the resolution is much higher now but I liked the 275 = 2.75 ratio you first suggested.
in my PR i took the liberty of applying an arbitrary scale to the parameters, as is done to the state. this is necessary if you want multiple algorithms, because they require diferent parameter ranges - setting alpha to 3.5 in a henon map will just blow it up.
and there are many other functions that could be added. a fun one i neglected to mention is the gingerbreadman. also a general LCG might be handy.
if you want the parameters to be literal then i think you have no choice but to split the algorithms into different operators.
i am not really a teletype user or even a eurorack user, so i bow out of the discussion when it gets to fine points of usability and syntactic preferences. that said:
- i would maybe argue that CA should be a separate op since as pointed out, it’s very different structurally.
- IMHO, a resolution of 0.01 on the parameter value for the maps, is insufficient to explore the coolness of closely-neihboring orbits.
