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.
9 |
8 |
7 |
6 | *
5 | *
4 | *
3 | * *
2 | * * *
1 | * * *
0 |--|---|---|---|---|---|---|---|---------------
1 2 3 4 5 6 7
^
| harmonic --->
|
amplitude
Suppose that we now make a signal based on these spectral
components, which is mathematically represented
by a sum os sinewaves of the right frequency, and the
right eighing factor, a1 x sin(f1) + a2 x sin(f2) + a3 x sin(f3) ...,
it would look something like this:
| |\ | | \ | | \ : | | \ : | | \ | | | \ | | - \ - | | \ | -----------------------------------------In asci chars its a bit hard to represent, but its a saw-tooth wave with rounded edges, basically. According to Fourier theory, if we continue the row of sines, all the time making an=1/i where i goes beond 3, well at infinity get a perfect sawtooth waveform, mathematically. If we stop earlier, we know that the spectrum is limited, because it has only the sine components until a_max, and when a_man is 16 for instance, it is already quite a decent sawtooth, and sounds like one.
Suppose we cut out all the even harmonics, that is f3, f5, f7, etc. Then again Fourier theory tells us that we end up with a square wave, as follows:
9 |
8 |
7 |
6 | *
5 | *
4 | *
3 | *
2 | * *
1 | * * *
0 |--|---|---|---|---|---|---|---|---------------
1 2 3 4 5 6 7
^
| harmonic --->
|
amplitude
with fourier synthesis gives:
| /\ /\ | | \/\/ | | | | | | | : | | | : | | | | | | | | | | | /\/\ | -------------------\/----\/------------------It can be proven in the same theory that any repeating wave pattern can be represented by a spectrum, and that that spectrum than always can be converted back to even exactly the same wave, as long as the whole spectrum is taken into account.
Another example is the triange wave, which is composed of even harmonics, and pulse waves, which are made by All this is well known, mathematically non-trivial theory, lets say 2d year electrical engineering stuff, but the applications can be quite direct.
I have, like quite some others in fact, made a program that does this form of synthesis, allowing a dos user to enter a spectrum with the mouse, and then compute a wave sample automatically, where the screen displays the resulting sample on at least a vga card more accurately than the above scetches.
Now what about these spectrae? The ear understands them, and more or less operates in frequency listening mode, that is the ear mainly percieves a spectrum, not a waveform. This is not completely true, especially for the lower frequencies, andit must also be mentioned that the spectrum must be accompanied by the corresponding phase data for all harmonics, but still, in sound recognition sense as well as musical sense, as spectrum is a good representation of what the ear perceives. In normal life, the spectrum of a natural sound changes all the time. An organ note is an exception, when an organ note (or a flute) is played, the spectrum is mainly constant, but otherwise it changes all the time.
The program I made therefore takes two spectrums, the first and the last, and generates a longer wave, where the effective spectrum at each moment in time is a mix of the first and the last, starting with only the first and gradually over 50/50 changing to the last spectrum. The resulting wave can be seen and scrolled through on the screen, and is automatically send to the microcomputer for playing.
The C program I've uploaded as a txt file, and I've put up the .com program file and a sample needed for the program, for a try start up with 'zda sl22.spl' from a dos prompt. I'm not sure on which machines it works, mine was a dos 6 or so 286 1meg one, altough its basic stuff I'm not sure about screen and especially memory management code, and the compiler I don't know about either (Its called sphinx), but for my machine this all works fine. Let me know.
Of course you don't want a printer on and connected, because it would start printing the sample, which looks ugly and probably spits paper, but the spectrum editor, interpolator, filter, ADS unit and waveform display are all crammed into the small 5k executable, no kidding, try it yourself.
The screen starts with only the menus on top, of which the 'first' and 'second' take you from the first set of sliders from the bottom of the screen upward to the second. The left most 16 (the number where the mouse cursor is above is shown in the upper right corner, together with a number indicating the slider position from one to a hundred), are for the harmonics, number 17 and 18 are for filter cutoff and resonance (usefull range roughly 0-93, 0-51, respectively), while 19-21 are attack, decay rate, and sustain level for the amplitude. Both the harmonics and the filter cutoff and resonance are interpolated between the first and second slider sets, and the 'send' menu has to be pressed to generate a complete wave in memory, which can than be examined by the 'next' and 'previous' menus.
I don't have the 'sine' sample set on the web, I've normally a set of sine waves for the harmonics, ranging from 1 to 4 sines per 256 samples, but I've included a nice enough complex sample, which doesn't examplify the harmonics idea in simple form, but is was generated with the idea, and sounds good. The sample format is completely special purpose, it is 7 bytes preamble, than 256 data bytes, unsigned, and then a stop byte, as I remember by hart. That is because they were compatible with my basic programs (see the synth progress page), where they are basically dumped memory locations in the bsave/bload format (made from that basic code by 'bsave "sl22.spl",&h7800,4096-512').
I also have seperate loader programs for these samples, and for IHX hex files with object code to load the microcomputer with data and programs, the sample loader is included in the zda software as 'fillz80_noprint(int lenght)'
LET it be clear, grrr, that this program and the sample formats work for real, even in doable time, and that they do all things I made clear good enough for quite strong sounds, BUT, that I would prefer all this in regular C, and with some more up to day run-time code, and preferably with standard sample format. The latter I'd probably do with all this, the others are simply not doable at the moment, unfortunately.
Note: after checking I found out that the tripod server still doesn't assume binary data connecions for file formats it doesn't recognize, meaning that using a browser to download the .com program and the sample probably doesn't work right. I'll see if I can zip things together, then it should.
interesting url, I just tried one of my physical modeling samples: http://www.woodsongstudios.com/, unfortunately there are proxy or firewall problems, you may want to try yourself for instance
https://members.tripod.com/~theover/s1.wavIts a nice java applet that does fft and inverse fft java, also based on wav files.
Often such a network will be the well known ethernet, but it may be any connection, it could even by Isdn, or on the other end of the speed spectrum: a ATM connection. The idea is that computer systems are normally not that well utilized, anyone glaring at a 'cpu load' indicator forinstance on Linux, or on Windows, knows that not often such a meter shows 100% utilization, and when one is wordprocessing or browsing, maybe a percent of the pentiums' power on average is enough. Most will know that is still is worth it having enouh processor horse power handy anyhow, because when we load a big page, or compute a complicated print job, for a short burst a lot of computations per second do make the systems' responsiveness a lot better.
Quite long ago these effects were also realized by the makers of for instance multi-user systems: users have terminals, and a big enough central computer handles the tasks of all users in a semi parallel, task switching way (100 or 1000 switches per second), and the computer power is distributed to users on a fair distribution basis, which was often better than having workstations of together the price of a minicomputer, because the peal power of the mini would be a lot higher, and so if for instance a high load compilation is started by only one or a few users at the same time, the peak performance will make those tasks a lot faster.
When workstations entered (about 15 years ago) that situation changed, because many would have their own, and they were regarded fast enough for many tasks (windows, multiprocessing, database on their own disc, graphics). Its sort of saying that the total budget for a number of users is now divided amoung them, and they satisfied with their own machine, a workstation, and later the same applied to a PC. This being not problematic, it does raise the question of computer horsepower distribution. Suppose we want to do a little grapics animation for a small movie, then we need to do a lot of computations to compute the frames, which on a workstation may take a day for instance. Then if we'd have the sample total computing horsepower, a central one would maybe do it in a few hours. Or, and that is the idea behind distributed computing, we take all workstations available, almost idle, and make them part of the computation.
Sounds fair enough, and for certain types of computations this is far from easy to achieve, especially when all parts of a compuation are connected, that is when the 'nodes', the computer systems taking part in the computations require eachothers data regularly. Then a lot of network activity results, and special types of programming are required to make things work.
With this idea in mind, I made a graphics rendering program suite that actually worked in a distributed way (for research purposes alone, though, because the network bottleneck and the type of program wasn't faster usually by using the distributed method, except under certain conditions), and I also thought and worked on the methods of making this type of programming work.
The internet and most network based programs communicating rely quite a bit on a communication protocol suite (software in layers) called tcp/ip, short for transfer control protocol and internet protocol. At the programming level a programmer can 'officially' exchage data with another program, making use of these protocols, the method to do the actual communication makes us of the the concept of a 'socket'. In short, one programs connects over a socket pair with another program on the other end of the pair, and somehow tcp/ip makes sure they can send eachother data over these sockets.
When you type a url in a browser, what happens first is that such a socket connection is built up with the destination server, and when it is established, the serer pushes data over it, and the browser may feed for instance form data to the server.
A socket for the programs is just a number from 0 to in principle 65535, relating to datastructures in the computers memory which allow data packets to be transfered, usually as a kind of 'stream' where data flows through. Some sockets numbers have an agreed meaning, such as number 80 for http (web pages), 21/22 for ftp, and some of the lower ones for telnet, ping (check and time connection), etc. Higher numbers are free, and are used on request, for instance when a browser requests a file download, a socket is created in the browsers program, and a corresponding one on the server side, where the file is put in, as it were, byte for byte starting with the first.
The same can happen when the server and for instance the browser are on the same machine, in principle that is no problem. Windows (9x, donno about 2000) doesn't do its multitasking all too smooth, both it does work for instance to browse on the same machine where a webserver runs, as I did regularly for an image database I worked on.
Now suppose that we have two programs that should be connected to communicate certain data. An ordinary solution to that problem is that we make one the server, give it a nown address and port number, and then make the client connect after the server has been started. Then there are standard mechanisms I'll outline, after which communication may proceed.
My problem at the time of the graphics programs was that I wanted various programs (lets say 8 or so) to communicate, and it would be inconvenient to give them fixed addresses, and the order of starting them up wasn't known, and it was even desirable to be able to restart a few, and let the rest run. In a client server solution, when the server goes down, the client is in trouble, normally, so the client server model was not my main target.
Without going into the details and more refined issues, basically a connection is set up by 3 phases: bind, connect, accept, which usually indicate the binding to an IP address and port number, a request for a connection, and the indication of acceptance of a connection with a certain connect-request generating party, that is another program.
To make this general, I made what I called a connection server, which had as purpose to create connections, and make them available to all programs wanting them on a readable name-basis, without the need to do connection setup, or the need to wait for the connection to be acknowledged on the other end. Its sort of like connecting wires with plugs on both ends, which are connected to a program asking for one end of a wire with a specific name.
With only one end connected, the wires would accumulate some information being put in them, then stop, but not produce errors, and when the other end has also been requested, the data can straight away flow both directions. When one of the to parties on either side of the wire disconnects or is killed (process term), the wire and the data still carried by it is kept alive, and can be connected again by a new other end program. Unless both parties disconnect, the wire, with a specific, man-readable name, exists. I made a few graphical interfaces listing all existing wires by name, with their connected parties, and the programs taking place in the communication with wires would use understandable wire names, which were visible in a continuously updatable connection graph, using standard unix facilities, that is no special operating system facilities would be needed, and in fact the whole software suite would work on various types of machines.
And the approach was succesfull, efficient and fulfilled its purpose, the distributed software worked fine. The connection server was very robust and reliable, it would run for a week without the need for restarts, and the connections were just as efficient as the bare OS provided sockets, because there was no extra processing the stream.
The idea relied on the passing of file descriptors between the connection server and it's clients, which needed only a small library, with an easy to use function in it
socket = cserver("connect mywire1");
chars[] = cserver("list");'
cserver("close myotherwire");
was the idea. The server
kept the file descriptors after passing it to a client,
and therefore even a client crash would not disrupt
the connection pair and the other parties. And dataflow-wise,
all things work smooth enough when flowcontrol is applied
according to decent rules:
if (selectshort(SELECTBIT(mywire) | SELECTBIT(myotherwire) )) {
fprintf(mywiresocket,"whatever \n");};
And then distiquishing read/write of course would effectuate
that the data meant for a non-existing process is buffered
in the socket buffer space until the other party reads it,
and a starting process simply starts reading. When a party
crashes, it may be it in and output data streams need
resetting, but this can be arranged over normal select()
and parsing conventions, including process-, not OS,
controlled timeout.
It can easily be so that a network exhibits known dataflow patterns, allowing a use to make good use of the knowledge about the data streams to for instance plug in and out processes when he or she known certain streams carry no data. On unix, flushing and intrinsic flow control works quite well, depending on buffer distribution (which in the case of multiple processes on the same machine would be length 0 send, 1+ receive buffer, then a decent OS prevents the use of a threefold copy (into send buffer process A, via intermedeate buffer, into receive buffer process B), while maintaining grain-efficiency by acknowledging standard frame delimiting methods (either flow high-watermark or end of line delimiters for ascii connections).
Both on sun sparcs and various HP minis/workstations, this method worked well and efficient, delivering (one machine) up to 25/50 megabyte per second effective, measured interprocess transfer speeds for various data formats, on a 50MHz hp720. This was major speed graphics machine infrastructure preparation, you see. Knowing that a device can also be written to as a file, it would make it easy to transparently use parallel processes or an additional graphics accelerator for a graphics application.
The connection server idea wouldn't work under older verions of cygwin, just like the accompanying shared memory communication I used, which is good for lots of dma effectivity, I'm not sure windows allows passing a file descriptor officially, shared memory of course is available, though I'm not sure what PCI and eisa controllers allow exactly. Linux may well do the filedescriptor passing according to I think is was system V standard, then the same approach could work, with the bwise canvas block editor approach this could prove powerfull.
At the time I implemented a (strictly non-preemtive, but quite fast) multithreading mechanism, where I used the same connectio convention, and even added complete transparent stream support, which would allow transparent and run time decisions on how to distribute computations over threads, processes, and machines, by simply changing a connection table or graph. At about that time, I started to get kicked out quite a bit. Of course this research an prototype stuff was doing a significant portion of what various groups in the section were aiming for. And it did work, and efficiently. So?