Comparison of white and pink noise. White noise has fairly constant spread, but energy increases exponentially with octave. Pink noise has farily constant energy per octave, but its spread increases towards lower octaves.
Process: for each overlapped windowed segment of audio input, compute energy/octave via Haar wavelet transform. Accumulate count, sum, sum of squared values. At the end of the input, ouput statistics: mean and standard deviation for each octave (normalized to mean 1). Compare output for different input. Think about how to make a classifier based on the output. Think hard about how to make this process differentiable and propagate discrimination results back to changes in the input.
There's a march planned in London this coming Saturday 19th October 2019:
Maybe a neural network is the wrong thing - for deep dreaming I just need a differentiable program, so I can propagate back to the input why it gave the output that it did.
yesterday I failed at making some drone music, just didn't turn out any good.
today I failed at training a neural network (trying to eventually do deep dream stuff for audio with a music vs speech discriminator - currently testing with sine wave vs white noise), just wouldn't work. possibly I had some matrix or other transposed or my architecture was fatally flawed or something else. the vanishing gradient problem bit me as part of this, output was effectively random as the earlier layers wouldn't get going.
wondering what I can fail at next week...
Got a button that switches the graphics display portion of my program, but I can't figure out how to set the Gtk Theme Variant at runtime within my code. My system is using a dark theme, and launching with GTK_THEME=:light seems to adjust it. Found some code from https://github.com/electron/electron/commit/058d0bbe19a61b0709ac75cb258ee65147d9ac57 but it doesn't seem to work (even after I adapted it to gdkx).
Got the asynchronous task list working. Now I can initiate many annotation tasks and continue zooming while they calculate in the background in as many threads as are available.
The overall GUI layout is bad at the moment (space around image, task list goes off screen without scroll bars, stretching the window, progress bars have tiny height) and the only algorithm I've ported to the new thread pool is Ray Out.
But it's a start.
Seems to work for doubly-embedded Julia sets, though it gets prohibitively slow without multi-core acceleration (~45mins to wait for the annotations on the attached, when it could take 3mins if all my cores were used in parallel). Image radius is about 1e-14, so not very deep, but tracing all those rays takes long.
Working on an asynchronous task queue with a worker pool now. I want each task to show up in the GUI when it is enqueued, with its own progress bar and cancel button; to be removed from GUI when it is done (when completed, it adds the annotation to the image, unless cancelled).
Ideally I will be able to continue interacting while tasks are running, enqueuing new tasks or even navigating to different locations. It remains to be seen whether I will need a priority system to make rendering more responsive.
✅ embedded Julia set filaments
It's a bit slow using only one core to trace all the rays in sequence. I should investigate a multithreaded task queue or something.
Automatic annotation progress update:
✅ child bulbs of a mu-unit
✅ filaments of a mu-unit (done, this post)
❎ child islands of a mu-unit
❎ embedded Julia set filaments (next on the list)
❎ embedded Julia set islands
❎ embedded Julia set hubs
Mu-unit is Robert Munafo's terminology: https://www.mrob.com/pub/muency/muunit.html
Add a button to annotate the descendent child bulbs of a component.
Make this button annotate the tuned islands too.
Add rays, namely the periodic pair landing on the root, and pre-periodic pairs pruning the filaments.
✅ first medium part done
❎ hard part needs a completely different approach
❎ second medium part is fairly straightforward, next on the list
Currently you can select an item in the annotation list on the right hand side of the user interface window, and it is highlighted in the fractal explorer window. But when you have a lot of annotations, trying to find a specific annotation gets tedious. So I want to make it so I can click in the explorer window and have it select the annotation in the list.
I think I can do this by drawing the annotations (using the #CairoGraphics library) into an off-screen buffer with anti-aliasing turned off and annotation ID values as colours. I'll probably draw the rays thicker than 1 pixel in this buffer, otherwise selecting will be a nightmare. I already have one off-screen buffer used for text collision/overlap avoidance (aka dynamic level of detail), I might be able to reuse it. Ray sort order should be by (preperiod+period) (lowest drawn last / on top) to be intuitive, text b-boxes on top.
Add a button to annotate an embedded Julia set automatically, because marking all those points and rays is a bit boring.
Add a number box for hiding rays whose (preperiod+period) is higher than this threshold, as a stop-gap until I figure out how to choose this threshold (or another way to prune rays) automatically.
[ZIMMER162] Bebhionn - System III
some nice minimal techno, maybe too minimal for dedicated listening but it's nicely accompanying my coding today
I fixed the crash (race condition caused by freeing something in the wrong (non-GTK) thread), and improved the sort ordering too.
Also added an automatic dynamic level of detail feature for the annotations, so when you zoom out you don't get a mess of unreadable overlapping text. Not perfect yet (the rays still bunch up heavily) but better than before.
#HowTo #install #Mandelbrot #Perturbator #GTK on #Debian #Buster (derivative distributions may also work, other distros may need tweaks). Installs into ~/opt by default, you can change that with make options (e.g. `make -C c/lib install prefix=~/fantastic-software/`).
sudo apt install git build-essential libpari-dev libmpc-dev libgtk-3-dev libsndfile-dev libglfw3-dev libglew-dev
mkdir -p ~/opt/src
git clone https://code.mathr.co.uk/mandelbrot-symbolics.git
git clone https://code.mathr.co.uk/mandelbrot-numerics.git
git clone https://code.mathr.co.uk/mandelbrot-perturbator.git
make -C c/lib/ install
make -C c/bin/ install
make -C c/lib/ install
make -C c/bin/ install
make -C c/lib/ install
make -C c/bin/ install
I tested the build process in a chroot (which grew to 1.2GB), but I haven't figured out how to run graphical applications from a chroot yet.
Uploaded a 10min silent #screencast #video of me operating my `m-perturbator-gtk` GUI for exploring and annotating the #Mandelbrot set. There are still some annoying bugs (annotation sorting/ordering is mildly inconvenient, sometimes it crashes when zooming which is a big big pain as there is no autosave yet).
1080p video link (43MB):
This version of the program has some local changes to the code from my public repositories, will push soon.
Ordering rays to see how to construct the tip rays (one letter inside ()) from their neighbouring hub rays (five letters inside ()).
. O(o) -- one lo
. O(o o o o i)
.(O) -- central lo
.(I) -- central hi
. I o o o o(i) -- five lo
. I o o o i(o) -- five hi
. I(o o o i o)
. I o o o(i) -- four lo
. I o o i(o) -- four hi
. I(o o i o o)
. I o o(i) -- three lo
. I o i(o) -- three hi
. I(o i o o o)
. I o(i) -- two lo
. I i(o) -- two hi
. I(i o o o o)
. I(i) -- one hi
The pattern seems to be "match longest prefix of neighbouring hub rays, then append o(i) and i(o). Except for spoke five. Needs to be verified for other locations, just in case it is a fluke.
navigating by spokes: https://mathr.co.uk/blog/2013-02-01_navigating_by_spokes_in_the_mandelbrot_set.html
> The tip of each spoke is the longest matching prefix of neighbouring angles, with 1 appended.
islands in the hairs:
> Actually, a finite binary expansion is really an infinite binary expansion, ending in an infinite string of 0s. But there's another infinite binary expansion for each number ending in infinite 0s, that ends in an infinite string of 1s: .xyz1000... = .xyz0111...
By the tuning algorithm 1(0) and 0(1) become i(o) and o(i), I suppose.
Trying to analyse the patterns in the external angles of hubs heading towards the other tips of the spokes:
-- influencing island p4
o = .(0011)
i = .(0100)
-- central island p29
O = .(00110011001100110100001100111)
I = .(00110011001100110100001101000)
-- bulb 1/5
b = .(00001)
B = .(00010)
-- main inner hub
-- spoke one (towards inner tip)
-- spoke two
-- spoke three
-- spoke four
-- spoke five (towards central island)
Spoke one is discussed in the previous post in this thread.
Spokes two, three, four seem to be something like: if the last part of the periodic part of the hub is i (resp. o) take the preperiodic part of the tip with periodic part (i) (resp. (o)) and append o (resp. i) combining with the periodic part of the hub.
Continuing along a spoke in the same direction means going along spoke one of each next hub.
Spoke five needs more thought.
making art with maths and algorithms
Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.