==> 2ndmoon.txt <== 2nd moon like a ghost moon fake 2nd moon of the earth somehow adding 3 body problem? or just another set of cycles/phase for that moon ==> aaronTalks.txt <== Jun 17 you have an abstract space that has so many paremeters (axis) that your black box can output - you can count the number of things (good to know) given that you have these things - what subset of these things are recognizably unique similarity metrics - given 2 beats how similar are they? how distiguishable are your beat patterns? then you need to answer the question of scale typically noise functions have a domain in which they don't repeat perlin noise endlessly good at very broad level of scale, things change very slowly the upside is it feels like you're going on this great journey - under saturation you don't want to give away everything your algorithm can do at once but also the downside of doing this is people might not see the changes because they're too slowly a single beat changes in the beat every day time step coherency uniform distribution of random junk is boring day to day level you want some sort of coherency between step to step there's a gradient with white noise you quickly saturate the whole range // whenever I call rand try using perlin noise instead // ==> algoCombos.txt <== How will algos be put together? 2 copies of the same alg seems not as great as 2 different algos? maybe this is a question for when I can experiment with seperate clocks ==> bigpicture.txt <== generic rtc based module with lots of different firmware etc ==> boardManufacturing.txt <== // Options # Arduino Nano - cheap - already know it works - good libraries available easily - how to use for SMD? - how to use with SMD RTC? - sketchy sourcing from china/aliexpress # atmega38 SMD - cheap(?) (not sure if cheaper than assembled nano) - works directly with SMD components - probably good libraries available - no extra fluff - need to construct ram/eeprom? ==> calibrateClock.txt <== clock calibration simply use the code from the set sketch that grabs time from the computer (assuming that you don't need to run IDE to use this) either have it run on startup to check if the answer isn't null and if it isn't, set (some sort of try catch for that) or have a button that you hold to go into 'clock setting' mode in the manual - if the day is wrong, you can do that but keep in mind the drift of when a day starts - ie 12am, 2am, 3am, etc. //// have a switch you can switch, then a website you turn on the switch before turning on the module then connect a eurorack cable to your computer the site communicates the current time over serial or just over a series of blips that communicate the time could do something simple like giving year, date, hour each one expressed as a series of short blips, with a long one in between real easiest is prob setting up a long var that is seconds since 2000 as a binary number then the thing communicates binary - maybe with a long pulse in between In calibration mode an LED lights up when its calibrated Note - this setup would also forgoe the need for a USB port, so things could be SMD // ==> chaosNotes.txt <== Chaos 3 body problem shows basic novel chaos chaos is a system/equation that isn't solveable by calculating for positions at a given point you can simulate it by moving step wise and calculating instant to instant, but not accurately calculate broad scope solution - this is because of exponential growth of initial 'error' in the equation/system [perhaps initial introduction of of initial compounding error is a key step here ... in other words, emergence] lots of things in the natural world/around are chaotic // CHAOS vs RANDOM a chaotic process is: *predictable during the short term* the next step can be determined from the current step (randomness is not predictable during the short term) "randomness and chaos are two different things, but they have a lot in common" how do we tell the difference between randomness and chaos Is the external exciting force regular? Chaos typically has associated with it a parameter that you can adjust, where some values produce regular behavior, and some values produce chaotic behavior Chaotic systems generally have some rules to them - some bounds if we look at specific points ie in the 2 pendulum problem, the location of the inner pendulum only at the peak of the outer pendulum, you get a more specific pattern graphed within the bounds, making that strange swirly shape this is called a strange attractor that shape is a fractal (the geometric expression of chaos) it's a self repeating shape that makes itself as you zoom in nature is also full of objects that have fractal characteristics looking for fractals is a good way to find chaotic systems vs random systems (random systems won't be a fractal) // the fractal pattern over time moves and then also repeats itself (returns to center) [not sure if repeats to be actually the same] self similarity comes from a sort of structural folding - stretching and folding of the space makes it a fractal // faucet example starts out with small period drips (period is amount of time before a pattern repeats) as this period doubles and doubles, the period gets so large that you essentially lose the construct of periodicity // chaotic electrical circuits there are very simple chaotic electrical circuits most audio feedback isn't chaotic - it's a periodic linear oscillation (because the amp is set up to be linear) introduction of a nonlinear component can create chaos (something as simple as a diode) // for eurorack - creating chaos by introducing that compounding variable drift maybe even before the 'start' date of the system ie using past time variables and extrapolating them out to present, introducing exponential drift ==> codeArchitecture.txt <== Making a generator class class takes global inputs like slop, max rand length etc., and also what algorithm to use then in the class algorithms are their own methods (or a switch in a big method) but in that method, when it comes time to actually play a note - you call the outputNote() method, and that method contains all the code for doing slop, etc. / for lunar length modulation use nonlinear curves on input ==> counter.txt <== Mechanical counter like odomoter with really high number it's counting to when its maxxed out, it resets, and the behaviour of the thing changes max step length gets longer clocks behave differently - divided/multiplied somehow? kind of like inscryption acts actually - you thought the whole thing was one thing but now its another, like it or not different behaviors cycle over time kind of like a tomagochi as well // using nokia display different graphics and such for uses ie you get prompted when you turn on from different times 'wednesday' 'moon cycle 2' with different animations and such hiring someone good with animation to do the animations one button for screen that swaps view 1 - status w/ day/date/moon cycle/year cycle 2 - current rhythm with box and x notation like op1, and showing current step etc. // one seven segment display, different segment for each day of the wee - guide is written on module\ having a purely random module/mode that I test my module beside to see if the randomness is readable ==> display.txt <== Using pillbox m t w th f s s LEDS you could see all the positions of the weights etc one for the year one for the months one for the days visual clock over time show lunar cycle moon shape expressive but non readable picture on the front that's a guide that you reference manually for lunar cycle showing the earth with the moon rotating around it then an inset map of the moon phase - showing time of day on the earth, and the earth going around the sun // rgb LED red, orange, yellow, green, blue, purple, white (full) for all the stages of the moon - maybe new moon is no light could also do 8 (or 7 not counting new mooon?) LEDs with transluscent panel wheel with moon cycles on it in a window (w led behind?) // two collums of LEDS, one for days of the week, other for moon cycles (7 and 8 respectively) (this is in the empty space above/below the 4 inputs (2 clocks, 2 outputs) the moon cycles and days would get underlit by leds (they would be transluscent etchings in a plastic panel maybe 2 different colors of LED - moon phases should def be white ^this would imply that those 2 measurements are by far and away the 2 most important on the module (what does that mean for design?) rgb LEDs could note the passage of time IE the moon is white, then red, then green etc. - maybe just from white to red is cool - noting a long sequence like the passage of a calendar year or many moon cycles etc. "many moons ago" maye one side is moon sequence, other side is multifunctional ie theres lots of different categories and the rgb shows the position of each - or blinking? weekday could change color when you haven't used today's rhythm yet - maybe something blinks colors for long term usage go roygbiv in order // Bottom line is OLED is the best way to communicate information about time things happening over long periods - rgb LEDs good too, but more opaque (maybe that's cool/fine) - changing colors over time could be nice OLEd different status modes - button to switch between them and check different stats we don't care about or even want to show lots of info/tell exactly what the module is doing - but oled allows to let the player know that there are things changing on longer timescales - a sort of omg moment of like - oh that little graphic in the corner isn't static forever, it's changing over time - gimmick addition could be the magnifying glass, connected somewhere on the board to a little anchor or zippy pull out thing the necessary time scales to know are things change every day things change every moon cycle things change from moon cycle to moon cycle led strips communicate that, oled communicates that, analog stuff struggles if I could find goddamn analog counters like on an odometer that could be awesome to have a bunch of little two digit odometers all in a row top to bottom with little symbols next to each one and they are moving slowly and out of phase with each other - would have to drive like 5 motors though - maybe just 5 pwm pins and who friekin cares best case scenario is no screens, no LEDs, all 3 levels of information communicated All of the analog options are pretty dope but probably don't communicate enough information ever - ==> eepromwrites.txt <== vars only have 100k writes - each - so maybe it's ok if some become unreliable only writing when you reach a milestone local variable - ie only write every 100 triggers or 500, so there's way fewer writes probably shouldn't worry about eeprom right now anyway ==> gimmick.txt <== It's a gimmick unless there's breadth of content the base content needs to be interesting AND the real time stuff needs to be interesting you can't rely on tradition, mechanics, etc. ==> halfMeasureAvoidance.txt <== some modules seem to make the thousand bowls of oatmeal when tinkered with - they're not as fun as the mathy emergent models that feel more like lego bricks but I think that's because they take half measures - they're trying to be one thing and failing because they're also trying to do another thing which is have a signature sound/action my module has no doubts about the fact that you are given a challenge, and you use it hopefully that sets it apart as a sort of new kind of module ==> holidays.txt <== every 100 uses is a holiday - lights a certain color/flashes on startup my birthday is a holiday holidays have special pre written rhythms ==> ideas.txt <== Both length of sequence and density mapped to lunar cycle you can progress the random values by reading the clock and startup and using values as a seed? maybe not because this will always produce the same values every monday every tuesday etc? not progressing the literal value but progressing the randomization range of the value maybe normal month dates are better because they're more tied to reality? Little screen with moon on it is also cool because it lets you know when there's actually a full moon - brings that information into your life real odometer flip clock display? (tiny) //Side idea - eurorack module with display that's a first person game/thing walking around - exploratory etc. ==> layout.txt <== CLOCK1 ROTATE1 OUT1 CLOCK2 ROTATE2 OUT2 ==> metaAlgos.txt <== generic variables X and Y global variables max step length random density slop ^maybe globals get assigned to different modulators each lunar cycle for more emergence for shifting algo parameters over time - not just change the random max, but also the min, shifting the whole random window over time "it's takes so long for the seasons to change, by the time the next one comes, you can barely remember what it felt like a year ago" ^^remembering that coming back to things on a multi month basis is actually a very long time away calling the different colors epochs, and there are 8 rotating ones of them, each one taking a full lunar cycle to complete (because there are 8 readable colors on rgb - could even change the hue of the rgb over time but that seems confusing could flash all LEDs a certain color on startup to denote the current epoch (as a reminder) and even flash multipe times if that epoch has been seen by the user yet ///////////// # AlGO-BASIC ///////////// 16 step set length variable step density (percent chance to turn a step on) //////////////// # ALGO-BASIC FUN //////////////// same but variable step length, non variable density ^might be good to have 1 on output, one on the other ///////////// # ALGO-REICH ///////////// X is rest length Y is steps to add (something small, like 1-3) roll for base XO plays 1st Y steps, then rests for X steps, then adds Y number of steps to be played in next time through once whole sequence is added and played through once, resets back to the first step /////////////////////// # ALGO-REICH-NORMALIZED /////////////////////// use an array called mutes, that additvely assigns 1(on) or 0(mute) to each step in the sequence in the same way the reich algo does so the length of the pattern is constant, just the active steps get revelealed and hidden over time ////////////// # ALGO-SUMMATION ///////////// vars uknown Plays whole sequence repeating for X times where X is the length of the sequence in steps remove one step from the end, repeat reset when done could also have rest in between sets, either at random step length or the length of the current set ie for the sequence xoxxo would be / xoxxo xoxxo xoxxo xoxxo xoxxo / xoxx xoxx xoxx xoxx / xox xox xox / xo xo / x ///////////////// # ALGO-PAINTOVER ///////////////// X - number of loops before overwriting a bit generates two patterns of equal length, different patterns though S1 and S1A slowly rewrites s1 to s1a swaps 1bit per x loops, in order from S1[ind] to S1A[ind] once one pattern is totally overwritten, starts writing back over to the other pattern, in an infinite loop ////////////// # ALGO-SKIPPY ////////////// play once through then play every other step in sequence, for 2 loops then every third note for 3 loops, etc. unti only one note played ////////////// # ALGO-CULTURE ////////////// fuzzy idea storing a bunch of culturally significant pre written rhythms then assigning 1 to each output maybe flipping some bits or something so they're slightly different but not so different to totally change the DNA good would prob be 1 bespoke rhythm + 1 generated for a patch rhythms from african bell pattern and variations, common two part stroke rhythms from latin different claves, rumba salsa bases etc. from european hemiola, waltz, etc. some from contemporary composers also using inverted versions of the rhythms (swapping where x and o are) ALGO CULTURE ALT putting those rhythms in a pattern with larger resolution and moving some notes 1/32 or 1/64th off ///////////////// # ALGO-DISTRIBUTE ///////////////// rather than rolling random for every step having a pretermined amount of steps, then randomly distributing throughout the pattern the number of steps could be static while the length of the loop changes or - for another algorithm the number of steps could be a small random range or, for another algorithm the length of loop could be static while the steps to be shuffled changes implementation would be in the for loop the index that you set wouldn't be i, it would be a random location in the array /////////////////// # ALGO-CLUMP /////////////////// placing steps in clumps of 2 or more set amt of clumps and clump length /////////////////// # ALGO-TUPLE ////////////////// start by placing tuplets of different lengths then adding some variation ////////////// # ALGO-SPARSE ////////////// pattern with much more space and maybe 1 or 2 notes in it only then it can be clocked way faster and used like a polyrhythm/be way sloppier ///////////// # ALGO-BlOCKS ///////////// builds rhythms by randomly arranging 1 beat long blocks maybe 16 beats long, maybe random # of blocks etc. based on the rhythm trainer website - which would use 4 blocks, 1 'beat' each (we'll call it 4 steps, meaning 16 total) Those were: quarter rest 0000 quarter note 1000 two eights 1010 dotted eight sixteenth 1001 two eighths plus quarter 1110 quarter plus 2 eighths 1011 four sixteenths 1111 eigth rest, eigth 0010 // alt algo that is like blocks but with non even numbers of steps per block 216 ie you might add a 5 block step to a 3 block step etc. // Euclidean algo? // Algo that swaps between triplet placements and normal placements // ALGO-WONK 32 step arr, loops at 32 places beats by skipping steps ie skip some constrained random number of steps, place a 1, skip again until the index is greater than 31 or maybe theres a value thats percent to add a step every step walk trough the array if you do place a step, the random % chance goes way down then for every step passed that you don't place a step, add a little to the % to step that way you're less likely to get clumped steps, but it's not impossible // // ALGO-WONK alt 32 step pattern then place notes skipping 2 notes at a time (effectively a 16 step pattern, could also skip 4 and make an 8 step pattern) then go through, and move some of the placed steps one index forward or back ==> modulations.txt <== times to modulate by changes over the course of 7 days changes over the course of 4 weeks in a moon cycle changes over the course of moon cycles (big phase) // something pretty noticeable should happen over the course of a week something that modifies that noticeable thing happens over the moon cycle the thing changes over multiple moon cycles could do that rhythm 1 changes params and algos per week rhythm 2 changes per lunar cycle:w days of the week have specific max step lengths (maybe with slight +/- jitter) reich algo could have the same patter for a whole week with higher max reset vals each day - then an even more meta param for the lunar cycle for reich algo - stop thinking of it as actual reich, better to use shorter max lengths (under 8 steps) and think of it as one choerent longer rhythm rather than a whole phrase - the whole phrase turns it from an interesting building block to jump off of, into a pre composed phrase/sectional sized thing that is too prescribed feeling ways to modulate density of steps/step chance max step length placement of patterns ie always places sets of 2 steps with at least one space before the next set (or not) (with half the density presumably) steps placed euclidean perlin noise distribution * density (somehow) using module division rather than set pattern? is this a set pattern? module in greek // special days ie sunday is a day of rest somehow full moons are important - if you use it on a full moon acts differently maybe repeats inputs back more than once like a beat repeat or something communicating this - 'days till full' or 'event' section that only says something if today is a special day 'Jonah's birthday' these are one off algorithms that only happen on certain times maybe super long rhythm patterns ie like 96 beats or something applying more or less slop (delay) to notes module is drunk at certain times module rolls randomly in different ways - and different bias between the two outputs (reread the marbles manual for ideas) -- lunar cycle changes the flavor of modulation - day of the week cycle changes intensity? or other way around - this way you get different match ups because days of the week and lunar phase are out of phase // random variable that decides percentage chance that a random bit (0/1) will be played rather than the bit at current time (checks every step) and another random chance that decides whether that bit will overwrite the current bit - slowly the pattern gets repaved could even swap between two generated sequences and one slowly and at random intervals writes current step to the step of the other generated rhythm, then when that's finished, it starts writing back to the first pattern could also have a trig output for when something gets written // if you use it too much it gets sloppy/gets sloppy at certain times // cv outputs forcurrent position in loop (maybe 2, one for each pattern) // maybe thinking of it as a sort of 3 stage thing there's pre full moon, full moon, and post full moon and those three are meaningfully different, with smaller changes during the in between phases ==> physical.txt <== Magnifying glass over display to make it look bigger/magnifying glass screwed on to the module - like reading stars or something using the electro dimmer pannel somehow 3v VU meter from adafruit - replace backing with moon phases and sweep over 3v using pwm ==> rememberance.txt <== It remembers old rhythms etc. and re uses them yada yada yada like westworld memories lol ==> simulation.txt <== To test long term emergence - stepping through a year of daily generated patterns writing those to a file checking for duplicated, fully filled or fully empty patterns etc (fully filled or empty can be populated with a single random step but probably better if that's not happening super often)