I've decided after good example to write some diary pages with toughts and events.
Oh, in case anybody fails to understand, I'd like to remind them that these pages are copyrighted, and that everything found here may not be redistributed in any other way then over this direct link without my prior consent. That includes family, christianity, and other cheats. The simple reason is that it may well be that some people have been ill informed because they've spread illegal 'copies' of my materials even with modifications. Apart from my moral judgement, that is illegal, and will be treated as such by me. Make as many references to these pages as you like, make hardcopies, but only of the whole page, including the html-references, and without changing a iota or tittel...
And if not? I won't hesitate to use legal means to correct wrong
that may be done otherwise. And I am serious. I usually am. I'm not sure
I could get 'attempt to grave emotional assault' out of it, but infrigement
on copyright rules is serious enough. And Jesus called upon us to respect
the authorities of state, so christians would of course never do such a
thing. Lying, imagine that.
The tax thing was perfectly legal, I had invested major amounts (for private persons) in the computer, synth and sound equipment I used for the program, so there was nothing at all against writing them off as business investment. That just to put the record on that straight.
Now suppose I'd want to sell software nowadays? Just like then started, the internet would be a good way to advertise and get some reknown, and it may be an interesting option to put a package up for e-commerce and on line transaction sale, though that currently would require the starting fund to have secure server and credit card facilities.
Would that work? Also like at the time, software is vulnerable to illegal copying. At the time I had 3 copy protections schemes built in: the name (and number) of the buyer, protection in the software that would render it unuseable if that name or number would be altered or erased, and a third to be able to see which two owned versions of the program could have been used to remove both former methods by a byte-for byte comparison of two copies, followed by some binary editing, common enough in hacker circuits.
The result was at least not so easy to derive a free-floating copy from, because then the original owner could be traced, and legally held responsible. Depending on what type of software, this product was about $60 with good manual, and quality enough, such a scheme may work. People simply wouldn't feel like it enough to make the copies, and the price wouldn't prevent them from bying a copy when they are interested in more than what the (free, limited fucntionality) demo version would let them have.
For a major package, professional circuits could be ok enough, since they'd pay a good price if the product is right, and probably would like an amount of support with the product, so they would probably want a legal version. For music software, musicians are poor, that may be true for some potential customers, byt not for all, and a lot of professional users may not need to or want to rely on direct sales channels with support and 'official' hotlines, or something. That could mean that illegal copies are a major potential problem, and I'd need to think about it.
I don't know what would happen if I'd put a quite good synthetic sound generator package on the market. It is getting there that that is seriously possible without great amounts of work, and then at least a commercial version with some slick and groovey properties may be interesting. I think normally I'd like the idea of putting a windows and linus version on for free download, but one has got to make a living.
The idea of the synthesizer, and / or additional hardware such as DSP computation workhorses and other PC add-ons, is valid for various objective reasons, and is definately commercially interesting in either of those forms. Then the software could act as good (and possibly free) advertisement.
I'll need to think, the sample processing software on my pages is capable of doing interesting forms of sequencing already, and can be given interfaces and additions in various forms such as available in some major audio processing packages, for which there is probably quite a market, considering the companies making them are not small. I have no major ambitions in the directio in general, but it may be of interest to chose another angle on the sequencing, audio processing software, and of course link that with the sound synthesis software and 19 inch racks, or other enclosures.
The main point of the synthesis angle is that a mixer doesn't make music, and that samples and sampling is recording with some instrument possibilities, but requires sounds that must be obtained somewhere, and fit the occasion. Which is maybe not underestimated, but a very major factor.
Why does a new synth sell? Because it does sounds the older couldn't get right yet, why bother otherwise. Maybe a few other things such as the type of keyboard and controllers, and the display size or so, built in sequencers, that stuff, but mainly one needs a sound. Without a turntable with musical material and rythm machine with fashionable sounds and rythms, nothing much happens, even in a outskirt of making musical utterances.
That bothered me to the point of regularly mentioning it in various circuits, and the general feeling I had about it was that I decided to make a possibility to go to the us with by doing the research I did. And the pay for such a position wasn't bad, neither were the machines and other facilities. Not very positive, and indeed, it wasn't, except I hoped (before I realized what horrible persons I might be dealing with) that I might make some things work, and that contentwise I would make the research and development pay of, be interesting and world top level. The subjects, and what I made work at least did not need to end up in drawers of eternally at rest PhD thesises.
I answered that I did at that time, and would make the sources available, but a bit later I didn't have a possibility to run the program any longer, so it is still that version, except that I have added various functions for generating greek pages on the tcl webserver, based on looking up words on the Perseus greek server.
Oh, and various web page based database functions, and lets say image processing related stuff. The latest experiments I did were in line with making function blocks, in graphical form on the the bwise canvas, respond to page request from a web browser to the connected server, so the server would be extended 'live' by someone connecting the right blocks together, which for instance would generate a web page with function block based content.
So a block for a html header would be connected to a block for database access, and some computations, and some text file, and the result could be viewed in a normal webbrowser by going to the local web server. The graph on the server screen (which can be the same machine, but also anywhere on the internet), would even light up the blocks in order to show a page request is being serviced for visual feedback on how the page is generated.
Loads of fun and usefull for debugging dynamic pages, and professionally completely valid to for instance use with one of the blocks acting as a database, like I put on one of the latest diary pages.
Then a use may have form entering an expression, the expression comes in the graph somewhere (which already worked, cgi-ing with builtin tcl functions is not too hard), and the graph starts running based on that data, doing whatever it does, say a celcius / farenheit conversion for the simplest case, or some database output being formatted into a dynamic image list for a more advanced example, showing what happens, the page is put together, and sent back to the browser.
Piece of cake ? In fact the way I set it up, the whole package should be installable over pretty much the whole range of tcl/tl supported machines, windows, linux, mac, and unix, and so in maybe 10 minutes when things are normal, then doubleclick the server to run it, the bwise window comes up, and the blocks can be put in. At that point, there is not much more to it than make a working graph, and figure out what your local IP address it, for which there is a special function, normally http://localhost/main_function:8000 should be enough (I think I used some port unequal to 80, the normal http number).
That means nothing much hard to use the idea, since installing tcl/tk usually is a breeze, if you know how to install any package, it is well behaved, and quite, quite portable.
What I wasn't satisfied with is the putting the blocks on a row. There are 2 or 3 standard ways of making that work, such as simply entering the order of the blocks to be executed in some list, taking only functional or even simpler on-a-row behaviour, using special blocks as trigger units, or specifying specific flow inducing bahaviour for each type of block.
I can program the options without much difficulty in various alternative fashions, tcl works fine for list processing in that sort of way, and the result is fast enough for web-page stuff, even for hundreds of blocks or so. I wasn't satisfied myself yet with the possibilities of such graphs, in the sense that it wasn't transparent enough, except when more elaborate let's call it 'flow' behaviour would be used in graphs, but then it isn't easy enough to understand what a graph will do in the end.
For practical use, such considerations are not primarily important. The procedure library now even freely available, but copyrighted (I'm not sure it's in the file, but I claim it anyway) of course, I think its on http://briefcase.yahoo.com/theover/bwisepub. The various 'fire' functions for blocks and connected blocks are fine to experiment with, and the linking of functions with a block works fine to, within certain limitations, because I want saving of a canvas to also make possible that all functions for the blocks, and even the dynamic variables of the graph are saved, which I did in various ways.
Not quite out of the research kind of software phase, though a good enough, working (beta version?) shouldn't be a problem, including a 'reserved keyword' list, since I didn't want seperate threads and namespaces for each block, I found that anoying.
That is definately fun, the idea of using more software with it is also prepared, as can be seen on some older diary pages, I made server versions of both the string simulator, and even a web-enabled version of the sample processing package some time ago, which would also be representable by a block on a Bwise canvas, to make audio generating signal paths with a graph interface and webpage parameter and output and control interface.
I've been looking at Hewlett Packard 'openview' and related pages lately, which show pleasant resemblance in some interface programs for controlling and maintaining networks with openview with the interface bwise can generate. It was in Java, mainly I think, or maybe X.
There's nothing against using java as UI wrapper software, where it drives other packages, it is not unnatural use of the language, and it is efficient enough for the purpose, portable, and immedeately can be run on the web, except I don't like the compilation step during development, which is not even that short with two Java compilers I've used (I think they were jdk 1.0 and 1.1), on lets say 100 MHz pentium systems.
For formal, well documented, official software development, it isn't a problem, but every time one forgets a semi colomn: recompile, trr trrt rrrt disc access, maybe swapping, depending on how much is running at any moment, and another so many maybe tens of seconds of lost concentration or time for coffee.
Tcl allows easy trying of functions and expressions with immedeate results, which sometimes can do amazingly complicated scripting taks in very short programming time quite right. The disadvantage is that they may not be the most formally backup-ed scripts, or simply by not completely tested, but my experience is that testing on the fly, too, is a lot faster with such scripting language. I have no problem with working lines of lets say 1/4 K long lines with a lot of braces, and programs made of such units. Experience teaches me that apart from neat and decent high level language coding (as definately I'm capable of, see various C sources on my site), this approach is not bad to get results that work and are not hard to maintain, in general.
I quite remember Xwindow programs, and Objective C and C++ programs with and without it, that are 'neat' in programming sense, and portable and fast, so serve a good purpose, but are quite unoverseeable, mainly because of the massive amount of source code. A fast responding editor with search is needed, unless you're the main programmer, with all the source images in your head. The amount of object and executable code in that time (lets say 12 years ago) started to grow, too, which is not unlogical, there was more disk and core memory available, so why not make bigger programs.
But seriously, megabytes and megabytes of files for relatively simple applications did clutter systems, ethernet, and prevent compilers from working faster, and the current C++ versions I've some things from were maybe not that bad in that department, but I don't think the effect has worn out. A comparison can be made with lets say hobby computers, where things have to be done in a short way, and where generally the only difference in approach and results is that the workstation software can be made into larger programs for larger problems, which in theory can run quite effient, without needing to pay attention to memory use.
Does it make for better programs to have big libraries and wieldy ways of programming? No. The reverse not much either, it is more a matter of thinking straight about the development cycle of software, as is in my thesis for 3d models. The user or programmer has an idea in his head, and he uses the keyboard and mouse to change a program such that in the end it does what he wants. Apart from thinking time, that means the interaction with the program and the generating feedback to act upon should be as efficient as possible, and not have built in 5 minute (depends) intervals when a little change needs to ripple through to see the result of on the screen. That makes the development cycle slower without reason. Plan a coffeebreak yourself, and let the system not generate additional stress.
Html is not that efficient in terms of coding, but for text fiel standards, modern computers shouldn't have problems with that, for images, efficiency is still a major consideration.