Messages

Has anybody done anything interesting with OpenGL on the Linux console?

With Wayland compositors starting to appear, people on Linux are getting away from X, and in a way that doesn't force you to use a dumb framebuffer.  I was wondering if any demo coders are playing around in this domain?

Feedback is central to much of DSP (the exception being feed-forward filters).  If you recursively feed the output of a process back into its input, possibly with modification, much complexity is possible.  This is, of course, the mindset behind maths results such as Cantor's diagonalisation and Turing's result on the halting problem (this latter one theoretical stuff from the early twentieth century that laid the foundations for modern computation).  I'm wondering about using clever recursive feedback tricks to generate interesting music for demos without using much code or having too much precomputed data.

(My academic background was the crazy end of maths: things like model theory and especially nonstandard models, so I tend to live outside the box of normality rather than occasionally think there, so I often have a hard time expressing what I think would be interesting.)

I've kind of wandered off this idea for a while, but it keeps coming back to me, so I will most likely revisit it at some point.

The kind of language stack I'm looking at is, from low to high:

1. Assembly, for those bits that C can't get right.
2. C for those really low level building blocks.
3. C# as a way to glue those C blocks together.  Inner loops should be factored into C, not written in C# so that there aren't real performance issues.
4. Something like IronPython or Boo as a more dynamic higher level glue for the C# bits.
5. A custom language for the problem domain for actually scripting the work.
6. A problem factoring language to automagically decide where things fit in the previous 5 languages.
7. Some kind of graphical diagram language so I can programme with a mouse.

You can get monodevelop, mono and boo for the pi.  C can be done in either clang or gcc.  The problem with Qt is the issue of paradigm lockin: once you're problem domain isn't easily expressed in terms of objects, signals and slots, the Qt paradigm becomes redundant and you have a mass of code in your runtime libraries that doesn't need to be there, and coding structures in your source code that don't properly reflect the problems you are trying to solve.

Ultimately I would like to recraft the language stack so as to reduce the code requirements.  That is a long term objective of mine.

Oh, and a 64k demo that requires 64meg of shared runtime library is kinda ugly compared to a 64k demo that runs baremetal on the processor: the former makes your demo like a magic ignition key for a car that someone else has built, and I'm more interested in actually building the car than how the key is made.

I'm playing with the idea of complex feedback loops.  The sound at https://soundcloud.com/john-allsup/beefythedeadcowsaysmoo was produced by wiring the output of my UCA202 through a MonotronDuo back into the input and inserting basic EQ, compression and limiting into the feedback path.  (A PCM recording of an electronic drumbeat was used to seed the feedback path for part of the recording so one can hear the effect of driving the loop and just letting it resonate.) Most of the heavy code could be replaced with trivial DSP and still produce interesting 'dubsteppy' sounds and 'seventies scifi' effects.  I am wondering just how small one could code a high quality music demo if DSP was brought 'back to basics' and just done using a few channels plus basic delays with gain.

Not a demo yet, but the technique I am playing with is using a laptop USB to power the Pi, a crossover ethernet cable to communicate and running all display via X11.  I plan to take IDLE as sample code in python and craft my own IDE for the Pi, then get to grips with the lower levels of the hardware.  If all goes well, I might actually be able to code a small demo.

Having grown up in the days of MSDOS and the 8bitters, I still love what can be done with text mode or a simple display architecture.  I many ways, I find demos that show creativity within tight restrictions more impressive than hollywood graphics when given the full power of modern hardware.

I am playing with operating system designs for fun (reading through Tanenbaum's book and some on LISP and FORTH and other stuff) and when it comes to text mode, I am thinking of doing a composite mode thing (like modern window systems do with graphics).  Eventually, the hope is that it will make a nice toy for people to play once again with the possibilities of old fashioned and retro text modes.

I asked a friend (finishing his PhD in computer graphics) about writing C++ libraries with a pure C API.  I found I had to have an extra chain function outside the extern "C" to call the C++ code and another within the extern "C" code to allow all other languages to call into it.  (This is because C++ uses name mashing to permit function overloading.)  So add one extra call and return that really shouldn't be there.  Then, when compiling, I needed to compile the objects separately and then link them (giving files to the linker in the right order for some reason) and then I took a look inside the binary with a hex editor.  The resulting mess would have made me sick if I hand an ounce of i486 code in my heart.  It is brutally ugly, with a few hundred long scary symbol names and stuff.

The exercise was this: if I want to reuse the C++ STL, and call it, but from a newer and better thought out language that hadn't been invented when C++ was born, how would I do it.  This was a trivial exercise doing the minimal amount of work necessary to use a C++ vector<int> from within C (compiled using a C compiler not in C++ mode).

The moral of this story is that C++ is fine for now, but be aware that when newer languages come along, and they will and are, and need to reuse code, whatever is written in C++ is effectively unreusable.  Use C++ for demos for sure, you can do wonders with only the template system if you want fancy stuff to impress a potential employer how is dazzled by shiny things.  In fact, C++ is the best language around for reusing the <wonder/mess/disaster/beautifulShiningExampleOfAnOperatingSystem:yourchoice> that is Windows.  For the rest of the computational world, C++ is best left behind at the prototyping stage unless you're dealing with one of those obscure corner cases in scientific programming where C++ actually makes sense.  (For reference, the last language that filled that role was FORTRAN, and if you don't know what it's like to program anything other than numerical methods using fortran, you're one of the lucky ones.  At least I got to have a go at it only as an undergrad maths student, and even then could always do things better with the Solaris C compiler with proper optimisation settings and code written with the processor architecture in mind.)

C is the Snow White of languages, and C++ is it's stepmother.  Obviously in this case the stepmother found a time machine that allowed her to arrive later rather than earlier.

Bash script.  Whenever I think of a cool program, I find someone's already written a command line tool to do it, and all I have to do is download and

tar xvzf software.tar.gz ; cd software ; ./configure --prefix="$HOME/myroot" && make && make install

and then run, or even better

sudo apt-get install software

and then run, or

sudo port install software

and then run.  Really, I can do everything through the bash terminal proompt these days.  Who needs C++ anymore?

I wrote something like this on my blog, and wanted to share it with people who might get it.

Multistage Computer Language Evolution
----------------------------------------------------------

1. First we have machines that work;
2. Then we have programmable machines that work;
3. Then we program those machines using a human readable notation;
4. Then we add comments to explain what we're doing;
5. Then we make the comments machine comprehensible;
6. Then we get rid of the 'human readable notation' and write a program to deduce it from the (machine comprehensible) comments;
7. Then we write languages using abstract machines which work like in (2), then (3), etc.
7++. Then a bored programmer decides to take the piss and writes C++;
(7++)<<1. Then he gets some beers in, invites his mates over, they have a laugh and call the mess a standard library to avoid having to clear it up;
(7*+$$:-). Then the programmers at the world's largest software company cotton on and start writing kernel drivers in that language;
(8;-). Then they point at the deadline from marketing and say that there's no time to write things again in a decent language;
(888;-). Then one of them really takes the piss and decides to write a RAD environment using a butchered version of Basic (CEO's favourite language);
(#define NINE 0x50d0ff) Then they really take the piss and go back to (2) and try to shove all this rubbish through to see what happens and whether it has pointy bits;
...
...
...
...
...
(car (cdr (stuff I '(havent written yet)))) No... seriously, I don't know what happens next!

Thanks,  that's all i needed to know.  Someone else has thought of that trick.  There are good real world uses, but I was wondering whether someone had realised it could be used for demo purposes.  The interactivity thing with forth is that forth programs can write and compile their own forth programs with no help from outside their userspace.  They do this in a very small space.  The user can insert words into a running program to totally change how the program runs, and the words can change other things which change behaviours.  You could write a small 64k demo using a forth engine to visualise cryptographic hashes as pretty graphics (which I guess is what they do in Hollywood all the time).

Most demos, by their nature, have a fixed design.  Most fascinating to me are those which fit in a small space.  What I am pondering is an interactive demo which is in some way programmable.  For this, there must be a programming system which by its nature needs to be small and powerful, and this points to Forth.  I am wondering if anybody else has been thinking along these lines?

Hi,

I've been programming various sorts of things for a while, generally trying to solve interesting problems with small snippets of code.  In general I write very little, preferring to search out and find those best ways of doing things.  The demoscene has fascinated me since seeing amiga and PC demos from the beginning of the 90s, and I have finally decided to look into the ways that demos are coded.  I find the 4k or 64k demos the most fascinating: how to get big things out of small.  I did a PhD in mathematics, and have a tendency to look for mathematical beauty in things, and there's a certain amount of that in the demoscene that I want to start finding out about.

Anyway, that is enough about me for now.

Hope to post/chat/interact more in the future.