I don't know if the oldbytes instance is big on introductions, but if so, here goes!
I am a Seattle area nerd interested in the small internet. Back in the day, I spent a lot of time as a forum moderator, and I feel like social media has become much bigger, louder, and less interesting since then. Perhaps Mastodon does better?
I'm probably not going to post a lot, but if I do, it'll be about my adventures with dawless music production and doing strange things with old technology. During lockdown I have collected lots of new #synth gear and am still working out how best to make tracks with it. #chiptune and #trackermusic (mod, xm) are my home turf.
If you like to do musical things, and/or want someone to listen to your tracks, please by all means @ me.
re: forth egg learnings
Oh, and if you're on an older Forth that doesnt have PARSE, the following definition of NEXT? works just as well:
: next? ( -- f ) >in @ >r 0 word c@ r> >in ! ;
forth egg learnings
I like to declare many variables on one line in #forth, but I got tired of saying
variable a variable b variable c ... so it was time to learn how to manipulate the input stream:
: next? ( -- f ) >in @ >r 32 parse nip r> >in ! ; ( # chars in next token )
: vars ( "name1 name2 ..." -- ) begin next? while variable repeat ;
And now I can just say,
vars a b c
This pleases me greatly.
re: forth macros
One approach is to postpone f2 instead of yell.
: f5 ( "name" -- ) : postpone f2 postpone ; ;
good-yeller \ Hi!
Or if you are hell-bent on seeing yell in your colon-definition, I guess you could do this, but it's not exactly elegant. And it only buys you one more level.
: f6 ( "name" -- ) create does> drop postpone yell ;
So... could there be a better way?
In my mind POSTPONE is incrementing a nesting-depth, and immediate words are subtracting 1 from this depth. Execution happens at depth 0, compiling at 1, and postponed compiling at 2. That's as deep as you can conveniently get in vanilla Forth. What if you could go deeper? It makes me wonder if there is some road to replacing classic FIG-FORTH's boolean STATE variable with a depth level instead. I'd have to think about it more.
I'm learning how to do macro-like things in #Forth by extending the compiler. I noticed something odd.
Let's say that I've got an immediate word that does something noisy.
: yell ( -- ) ." Hi!" ; immediate
If I want to make noise on-demand, rather than immediately, I'll need to use POSTPONE.
: f1 ( -- ) yell ; \ Hi!
f1 \ does nothing
: f2 ( -- ) postpone yell ;
f2 \ Hi!
But now let's say I want to create a defining-word that creates new noisy words.
: f3 ( "name" -- ) : postpone yell postpone ; ;
f3 yeller \ Hi!
yeller \ does nothing
Hmm... that's no good. How would I make the new word "yeller" actually yell?
Certainly not with,
: f4 ( "name" -- ) : postpone postpone yell postpone ; ;
because that POSTPONEs the POSTPONE, not the yell.
Meanwwhile, most virtual machines are stack machines. This seems to be a historical accident. Some languages have now switched to use a register VM. As one example, Android Dalvik seems to be a register-based JVM. This exhibits the same size/speed tradeoff shown before. Surprisingly, register VM's are not inherently more efficient on register CPUs; according to one paper it is often difficult to directly map the CPU registers to VM registers. I don't know why that might be.
Here are some links to books and papers I've read:
I spent some time educating myself about stack machines vs. register machines.
In general, stack machines have more compact code and are simpler, but register machines are more performant. So it's a size/speed tradeoff.
Stack CPUs' simplicity means they can often achieve a very high MIPS, but each instruction does less than on a similar register machine. Very reminiscent of the CISC/RISC wars. Unfortunately, we'll probably never know just how much a stack CPU could be accelerated, given that industry focuses on register CPUs.
I'm writing my first sizeable Forth program. I've never spent this much time simplifying algorithms with paper and pencil before translating to code. Writing complicated Forth is so painful that I prefer to wait until I'm sure everything's as simple as I can make it. Is Forth always like that, or is it just my inexperience and lack of fluency showing? I find myself hoping the slow pace is innate because it's making my code quality much better.
The nice thing about writing a subroutine threaded #Forth meta-compiler is that you don't need to have the complete Forth environment up and running to use it. It's essentially a glorified macro assembler preprocessor.
This is quite liberating in ways I hadn't considered before, due in large part to its overall simplicity.
I like simplicity.
Society is becoming a giant grade school:
~walled to give the appearance of safety;
~segregated by class;
~strict social hierarchy;
~narrative/appearance of answers;
~gold stars/participation trophies;
~ruled by seemingly benevolent authority;
~appearance of democracy: student body president, chosen by popularity contest, only has the power to make cosmetic changes to the way the bread and circuses are delivered.
Those who liked high school will find it comforting, I suppose.
More than teaching music theory, my goal was to demystify music theory a bit, and encourage people to pay attention to details in music and recognise things they probably had heard before.
Today I learned about GEORGE, a 1950s stack-based RPN programming language that precedes #forth by a good ten years. Also, fun fact, it is Australian!
sunny downtempo, notes on workflow and creativity
Here is a sunny little track with plenty of angel piano. This has been up on Soundcloud for a week or so, but here's the mp3!
This track exists because I am tired of sequencers. Drag n' dropping notes on a piano roll is where my creativity goes to die. Starting this #jamuary , I gave up MIDI sequencing and fell back to internal sequencers for drums and bass. Everything else must be hand-played.
It's been limiting, because my keyboard playing is poor, and I've discarded the tools that I'd normally use to fix it up. But the limitations are fun. Learning a melody by heart inspires shortcuts that make it more organic. Human imperfection contrasts with the machines' tight, robotic timing. Even needing multiple takes means I spend more time playing and less time producing.
Hopefully the results are listenable, but regardless, it's way too fun just playing with a disorganized pile o' gear and seeing where it takes me.
Synths, retrocomputing, space, books.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!