Message-ID: <51666E94.90607@paradoxuncreated.com>
Date:	Thu, 11 Apr 2013 10:04:36 +0200
From:	Ove Karlsen <ove.karlsen@...adoxuncreated.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: Millennium Basic

Hello. I have bothered this list, with many of my insights, and now I am 
going to bother you with more.

This may be read in blog-format here: 
http://paradoxuncreated.com/Blog/wordpress/?p=13232

I`ve been thinking about this. When I was 8 years old, I did programming 
believe it or not. Basic-programming, yes, but programming. And in 
hindsight I have been so grateful for that. Somethings I remember about 
basic on the commodore 64 still, is that it lacked freedom from 
linenumbering, and carrying variables into other routines. I remember 
thinking, if it only had that, you could do mostly anything with it.

This was Microsoft Basic v2. And one programmed it directly to hardware, 
with peeks and pokes. Later I also learned assembly-programming. 
Regardless of Microsofts product-ventures later, Basic V2, remains a 
brilliant point in history.

I think that, lies at the foundations of my programming. A very 
interactive and interpreted experience, with the computer, without 
obscure APIs, or any uneccesary learning. Something I carried with me, 
into assembly-programming, and something I still use, when developing my 
DSP plugins, making most variables tunable, and these are worldclass. 
(feel free to listen to the comparison to one of the worlds most 
reknowned mastering-houses - 
http://paradoxuncreated.com/Blog/wordpress/?p=13140)
And I spent much time tuning the variables, and not in any way, would 
these come easily as constants, or untunables in any kind of situation. 
I think programmers rarely do this these days. "A fir of FFT lenght 64 
will do", for instance, from a purely theoretic viewpoint. I know very 
well, that that will not get the optimal results.

I also ofcourse did the low-jitter config, that made doom 3, which John 
Carmack states on Quakecon 2012, that "Doom 3 still tax some 
configurations" - run absolutely smooth on 5 year old hardware. From 
tuning from a high-level perspective, knowing what I do about computers.

Most people I see today, who have good programming habits, usually know 
a little bit about assembly-programming, a "vintage" situation, and that 
of programming directly to the hardware, and some knowledge of 
assembly-instructions.

I fear that is disappearing a bit, in highlevel langauge, the need for 
compilation and APIs that may not be accesible to children or beginners.

A lot of the enthusiasm that drives hacker-circles, and often those 
around linux, is such experience. Not neccesarily from a book, but doing 
programming, intuitively, and really just out from understanding a 
syntax. And a lot of enthusiasm exists around interpreted script 
languages, and is often what drives certain technologies forward.

And since I am now doing some of the best DSP in the world, and also 
getting the results that I am, I was thinking about this. And also many 
programmers I meet now, do not have the connection to this, and to my 
annoyance, often hardwire things, I would have finetuned, and use more 
complex high-level constructs than neccesary, which makes their results 
poorer. Slower, less graceful.

What I thought was, one needs to try and protect that "vintage" 
experience somewhat.

Lets say if one writes a basic language, that can also carry variables 
into new routines, that gets kernel-access to the hardware.

So that basically you can do Poke53281,0, and change the color of the 
screen, etc. Or for more correctness use a language like Set53281,0. And 
instead of peek53281,var, Get53281, var. Etc. Print "hello", could 
ofcourse also be Display "Hello", for instance. And try to get a very 
easily read "basic" language, with basic functionality for most things.

Something I also later liked on the Amiga 500, was wellnamed commands, 
and intuitive syntaxes.

You´d have this whole interactive experience, available for enthusiasts, 
hackers and engineers, back again. To not speak of rapid prototyping.

I think that would be really good.

The basic could ofcourse also have a compile button.

And I really do think if one reduces the amount of complexity as much as 
possible, and retain "basic" functionality, that one really can do most 
of the stuff neccesary with, I think many more will be programmers, and 
make the software of the future.

Also probably, a kind of "minimal" subset of a GUI API would be good, or 
simply just functions in the basic-language. But enough for anyone to 
make the software they want ofcourse. Buttons, scrolling, scrollbars, 
gracefully editable information in the GUI, etc.

One thing I really hate, is C++ programmers, (maybe not so true for C 
programmers) that obscure things, and talk about wild highlevel theory, 
and fail to see the point of how simple code performs better, is better, 
and often is closer to how a real model works.

For instance in DSP programming circles, I sometimes meet people, who 
say "they are going to measure the impulse response of the analog synth 
X filter, to get the right frequency response, because analogs are so 
weird and strange". And then they talk about wild filter theorems, and 
end up with a complex filter, with high level structures taking all of 
this into account, than can only be called every 60hz because it is so 
CPU expensive. And this is even sold as a product.

And then you look at the original analog. And see four cascaded analog 
sections. That is the simplest thing there is. That is four onepoles in 
parallel, and can be done with four lines of code. And then you look at 
the other guys code, and see several .cs and .cpps with a lot of obscurity.

I don´t know what is happening. In scholastic pursuits maybe 
understanding the whole theory is good. But as a hacker, one simply 
ignores all that, and goes for the optimal solution. Four lines of code, 
that is it, in that example.

And that sounds good. I am sure most have heard about "the 303". It has 
been discussed so much online, and these arguments are used in that 
discussion. But ignoring all the theory, and just going for a four-line 
filter (+ clipped rez) I got immediately very good results. I later also 
added a few things to that, such as bias, and a simple one-pole "low 
emph" setting, that emphasises low-frequencies. This makes the filter 
sounds very smooth, in the saturating rez.

The soundexample, speaks for itself. 
http://paradoxuncreated.com/Blog/wordpress/?p=1371

How many tried to do this, and failed, and contributed to the discussion 
that "analog" was better than "digital", and so many odd things stated. 
What is stopping people? Are they lost in high-level constructs and wild 
theory?

Instead obviously, only with my programming experience from my c64, I 
got better results.

Something to think about.

Peace Be With You.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists