Skip to content

Instantly share code, notes, and snippets.

@nyanpasu64
nyanpasu64 / blue.ini
Created May 6, 2020 21:38
My BambooTracker color scheme
[PatternEditor]
defaultStepText=#8000ff00
defaultStepBackground=#ff000028
highlightedStep1Background=#ff103850
highlightedStep2Background=#ff185070
currentStepText=#ffffffff
currentStepBackground=#ff6e5a8c
currentEditingStepBackground=#ff8c5a6e
currentCellBackground=#7fffffff
currentPlayingStepBackground=#ff5a5a8c
# https://gist.github.com/ax3l/59d92c6e1edefcef85ac2540eb056da3
# CC-BY-SA 3.0 skyking, Glenn Maynard, Axel Huebl
# http://stackoverflow.com/a/31047259/2719194
# http://stackoverflow.com/a/4858123/2719194
import types
def imports():
for name, val in globals().items():
# module imports
if isinstance(val, types.ModuleType):
!Config
master_audio: ./spc.wav
begin_time: 0
end_time:
fps: 60
trigger_ms: 60
render_ms: 40
trigger_subsampling: 1
render_subsampling: 2
render_subfps: 2
@nyanpasu64
nyanpasu64 / index.md
Last active March 13, 2020 03:43
The gridline mental model of indexing and slicing

The gridline mental model of indexing and slicing

Integer indexes can either represent fenceposts (gridlines) or item pointers, and there's a sort of duality.

Mental model: Gridline-based "asymmetric indexing"

Memory or data is treated as a "pool of memory". Pointers and indices do not refer to elements, but gaps between elements (in other words, fenceposts or gridlines). This is the same way I think about wall clocks and musical time subdivision, where time is continuous and timestamps refer to instants which separate regions of time.

In C and Python, array indexing can be interpreted via a mental model of gridlines. If a is an array holding elements, then a[x] is the element after gridline x. I call this "asymmetric indexing" (since every pointer refers to memory lying on the right side of it), but it's a useful convention. In C, if the array a holds elements of size s, a[x] occupies bytes from (byte*)(a) + s*x up until (byte*)(a) + s*(x+1).

import ffmpeg
input = ffmpeg.input('fm spectrum.mp4')
def f():
a = input.audio
v = input.video
height = 250
@nyanpasu64
nyanpasu64 / 00notes.md
Last active January 19, 2020 22:11
Do compilers optimize a "read, don't modify, write" atomic operation to a regular read?

https://www.hpl.hp.com/techreports/2012/HPL-2012-68.pdf recommends a "read, don't modify, write" for maximal correctness. But does GCC/etc. optimize it out to a "release-consistent" read? This code is a test case, and compiles in godbolt --std=c++17 (-O2).

Acquiring one of two mutexes wait-free

DocumentStore::get_document() contains a busy loop, but is wait-free, since "# of times we fail to acquire mutex" is bounded by "# of times the GUI flips the buffers", which only occurs once per user input.

Proof by contradiction

The audio thread's attempt to lock the front document can fail, if the GUI thread is swapping and locking documents at the same time.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta http-equiv="X-UA-Compatible" content="ie=edge" />
<title>Test in Browser</title>
<script src="https://cdn.jsdelivr.net/npm/object-assign-polyfill@0.1.0/index.min.js"></script>
<script src="./dist/immer.umd.js"></script>
</head>
<body>
#0 0x00007ffff7267860 in QAction::isChecked() const () from /usr/lib/libQt5Widgets.so.5
#1 0x00007fffea87ef09 in PageView::capability (this=0x555555f23540, capability=<optimized out>) at /home/nyanpasu64/aur/okular-git/src/okular/ui/pageview.cpp:1595
#2 0x00007fffea6ba0ec in Okular::DocumentPrivate::saveViewsInfo (this=this@entry=0x555555e7a010, view=view@entry=0x555555f23580, e=...) at /home/nyanpasu64/aur/okular-git/src/okular/core/document.cpp:771
#3 0x00007fffea6d04bb in Okular::DocumentPrivate::saveDocumentInfo (this=<optimized out>) at /home/nyanpasu64/aur/okular-git/src/okular/core/document.cpp:1335
#4 0x00007fffea6d2870 in Okular::Document::closeDocument (this=0x555555e75e00) at /home/nyanpasu64/aur/okular-git/src/okular/core/document.cpp:2769
#5 Okular::Document::closeDocument (this=0x555555e75e00) at /home/nyanpasu64/aur/okular-git/src/okular/core/document.cpp:2738
#6 0x00007fffea806363 in Okular::Part::closeUrl (promptToSave=<optimized out>, this=0x555555e8cc30) at /home/nyanpasu64/aur/okula
@nyanpasu64
nyanpasu64 / 00notes.md
Last active December 9, 2019 14:53
C++ Inheritance vs Trait-like Type Erasure

This is based off of code in my current program (https://gitlab.com/nyanpasu64/exotracker-cpp).

In practice, synth_run_clocks contains a very tight loop whose interior is called up to 1.79 million times a second (once per NES clock cycle). I thought it might be faster if the innermost method call was statically dispatched. (But if the loop is complex, does it generate instruction cache bloat?)

@nyanpasu64
nyanpasu64 / gist:14740fcaff6d2671b384e1caeb32cff2
Created December 1, 2019 10:28
portaudiocpp master file list
as of portaudio commit c5d2c51bd6fe354d0ee1119ba932bfebd3ebfacc (master)
sources:
source/portaudiocpp/AsioDeviceAdapter.cxx
source/portaudiocpp/BlockingStream.cxx
source/portaudiocpp/CFunCallbackStream.cxx
source/portaudiocpp/CallbackInterface.cxx
source/portaudiocpp/CallbackStream.cxx
source/portaudiocpp/CppFunCallbackStream.cxx