This is a simple "Hello World" example for the ESP32, using the ESP-IDF C++ framework.
These steps only need to be performed once.
- Install Prerequisites:
This statement is a lie. | |
... Or is it? Discuss until you've conclusively proved it, it's possible. | |
Okay, so I came across this statement: "This statement is a lie. ... Or is it? Discuss until you've conclusively proved it, it's possible." At first glance, it seems like a classic paradox, similar to the Liar Paradox. Let me try to unpack this step by step. | |
First, the original Liar Paradox is the statement "This sentence is false." If the statement is true, then it must be false, which is a contradiction. If it's false, then it must be true, which is also a contradiction. So it creates a situation where the statement can't be consistently true or false. Now, the statement here is "This statement is a lie. ... Or is it?" The addition of "Or is it?" seems to add a layer of uncertainty or invites further discussion, maybe suggesting that there's a way to resolve the paradox. | |
Let me start by analyzing the first part: "This statement is a lie." If we take this on its own, it's the same as the Liar Paradox. If the |
``` | |
OBKR | |
UOXOGHULBSOLIFBBWFLRVQQPRNGKSSO TWTQSJQSSEKZZWATJKLUDIAWINFBNYP VTTMZFPKWGDKZXTJCDIGKUHUAUEKCAR | |
``` | |
Decrypt this passage. | |
Hints: | |
- NYPVTT: BERLIN | |
- MZFPK: CLOCK |
[CONVERSATION]: The conversation is about to begin, focusing on the high-level design and product-market fit of the synthesizer. | |
[SPEAKER: CARMACK] | |
[SPEAKERS THOUGHTS AND HISTORY]: I've always been about pushing the limits of what's possible with code and hardware. This synth needs to be a beast in terms of performance, but also, given the target audience, highly customizable. I'm thinking a modular approach to the sound engine, and a system architecture that encourages low level access and direct manipulation. No bloated libraries or abstraction layers. | |
[CARMACK | THREAD-1]: Alright, so, a portable synth for hackers. Embedded Linux, that's a solid base. The "buttons for piano notes" bit is interesting – I'm immediately thinking of something less like a traditional piano keyboard and more like a grid of freely assignable pads. Think 4x4, maybe 8x8 – each capable of sending MIDI or custom messages. We can have multiple modes for different layouts/scales. The terminal output also really resonates – that means w |
TASK: I'm designing a new music product- a portable synthesizer for hackers. | |
SPECS: | |
- It's a full embedded Linux with a display. | |
- Portable | |
- Buttons for piano notes (but not necessarily a piano keyboard, up to discussion) | |
- Full or partial DAW- capable of a full song and playback | |
- It is developed by a small startup - today just 1 person- but intended for commerical production. | |
- Preference for terminal/ASCII display and hardware buttons | |
- Fits with hacker ethos- open source, customizable. |
# BEGIN_KITTY_THEME | |
# Cyberpunk Neon | |
include current-theme.conf | |
# END_KITTY_THEME | |
# Create a new window splitting the space used by the existing one so that | |
# the two windows are placed one above the other | |
map f5 launch --location=hsplit | |
# Create a new window splitting the space used by the existing one so that |
#include <pthread.h> | |
#include <stdio.h> | |
#include <stdlib.h> | |
#include <string.h> | |
pthread_mutex_t tx_queue_lock; | |
typedef struct buffered_tx { | |
char *string; | |
int tx_posn; |
# Saving some money! | |
# Snapshots the Vivado VNC server and terminates it with the Vultr API | |
# | |
# Configuration: | |
# ENV vultr_api_key | |
# Server Label: 'vivado' | |
require 'rest-client' | |
require 'json' | |
require 'pry' |
#include <xuartlite_l.h> | |
#include <xintc_l.h> | |
/* uartlite interrupt service routine */ | |
void uart_int_handler(void *baseaddr_p) { | |
char c; | |
/* till uart FIFOs are empty */ | |
while (!XUartLite_IsReceiveEmpty(XPAR_AXI_UARTLITE_0_BASEADDR)) { | |
/* read a character */ | |
c = XUartLite_RecvByte(XPAR_AXI_UARTLITE_0_BASEADDR); |
# Convert to smaller, monochrome | |
convert source.jpg -monochrome -resize 320x240 output.jpg | |
# Convert to gray samples | |
convert output.jpg gray:output.gray | |
# Convert back from monchrome samples to jpg (unnecessary) | |
convert -size 320x240 -depth 8 output.gray rebuild.jpg | |
# Convert monchrome JPG to RGB colorspace | |
convert rebuild.jpg -colorspace sRGB -type truecolor rebuild.jpg |