by Theo Verelst

Bwise is a fairly incomplete package of procedures linked to a graphical block representation on a Tk canvas which is intended to make block-wise programming possible, at least at the experimentors level, and the idea is that what works enough could also be used for practical application.

The ideas behind it are important, not so much necessarily as in that bwise itself is important, but the ideas which led to its setup and the thinking which is partwise represented by it.

It started as a show off that I could make some things work in Tcl/Tk which took some people big, millions consuming projects which never delivered any deliverables worth noting, in the acedemic scene, where I wanted to make a different point, that efforts were being spent which mathematically made no sense, especially about computer hardware design/process algebra.

So I sat down on some cheaply available novell networked windows 95 computers, installed tcl in the morning of some working days, and sort of hobbied together blocks on a canvas which would talk to eachother, and have some relevant characteristics, which was also fun enough.

The ideas behind it start with the networktheoretically tinted observation that the number of ways which can be found through a network, or lets say to order the nodes in a network, also when according to functional decomposition rules or reasonable flow-like rules can be activated soon becomes larger than practical.

The general number of ways to order the execution of a network with 10 nodes is 10 faculty which when memory serves me well about 3.5 million. So ten little hardware parts or ten software processes which must al do only 1 thing can be execution time or ergodically ordered in 10! ways. That makes it impractical to freely play with the execution order parameter in a (possibly schematically captured) design of any serious size, where one easily has 10, 100 or even thousands of parts. Even when only capturing the outline of a machines' or designs' operation. At least for electrical engineers 1000s of parts are nothing of a great deal, for instance in chip and computer design. 1000! is a very big number (I forgot the faculty approximation integral), where we get from 1*2*3*4.. to 990*991*992 every next term adds nearly three zero's, so that number of ordering possibilities has hundreds of zeros easily.

No chance to ever 'try out' all things that could possibly happen in such a network by trying all possibilities, not even on an space age computer for many years to come, and then we'd build bigger things, still.

A server with a thousand internet connections asking it data and getting it is a software version of a comparable problem in certain ways, here to we need some organized, theoretically valid way to generalize on what may happen and what we want to do in various cases.

In electrical engineering, particularly electronics, things are uncomparibly 'worse' in terms of complexity. A radio circuit with 100 parts doesn't just have a hundred processes, it has a 100 processes which act in a continuous way, which interact with eachother, and in case of the semiconducters even non-linearly so. Luckily, we will usually be able to have a schematic diagram which limits the number of inter part interactions to a few per parts, unless we do a em field analysis, and there is the whole building of mathematical basis of the (at least acedemic) electrical engineering science which allows formal solutions to differential equations which can model the parts, and in the case of non-linearities: approximation methods for them with reasonably provable convergence theorems.

In software and computer land, such (serious, interesting, fun, but as most know very mathematically involved, probalby most of all studies) knowledge is little well known. Unfortunately that at times extends too much also to computer designers wannabees or simply unedified persons, as I have had to deal with in the past, but that is not exactly the subject.

Computers are made of electronics, which luckily, and when applied right, make parts which are considered digital building blocks, which are a lot less involved to design with and connect up than most electronics, which of course has led intelligent people in about the 70's to feel challenged to make all the more complicated and generally valid machines and sub-machines with.

For decent or advanced computer programmers, some knowledge of the actual machine our programs run on is indispensible, and I know from experience that even some people with seriously high spun mathematical and computer design ideas can go wrong very much when they must actually make something which even remotely resembles a computer, while maintaining theory which was even process theory-wise wrong. If that would be isolated trouble for me (at the time not even so much) it would probably be only worth mentioning on a cv or maybe my personal whereabouts page, but it seems that much of the software world is into many many so called logical constructions which are often tracible to similar trouble and the errors at its conception.

Against THAT bwise has started, too, hence the acronym.

At that time, I made some pages like:

   http://members.tripod.com/theover/bwiseapp.html
   http://members.tripod.com/~theover/tcl4.html
   http://members.tripod.com/~theover/tcltk.html
   http://members.tripod.com/~theover/pcore.html
   http://members.tripod.com/~theover/sample.html

Where the last two examplify the use of an existing schematic capture/simulation program, which is still around somehow under a different company, based on spice (a well known electronics simulator of old) with additions for (efficient) digital part simulation.

The simulator which could be downloaded for free (in demo version) years ago at least has proven handy:

   http://members.tripod.com/~theover/sim1.html

The master slave flip flop on the bottom of the page is obligatory reading for anyone who wants to claim computer or software or even the-whole-of-life-because-a-computer-works-so-and-so designs or proofs on the basis of important or generally valid considerations. When those considerations fail when the example is taken into account or by the example, the reasoning has been disproven, and is therefore incorrect, mathematically.

Note that the master slave flip flop is a basic computer building block which can be found in hardware books from the 70's onward of any serious for isntance ttl part supplier, and which sits in some form in static memories, probably in some variation also in (cmos) processor register logic, and at that very low level of complexity (for advanced designers) disproofs any computer related proof which based on functional composition wants to proof something general about practical von Neumann machines.

Not wanting to go all the way to make such simulator, too, which is a lot of work, and requires a lot of electronics models, and preferably freely available parts of spice to begin with, I did want to make some electronics and digital part points with bwise, because especially in such design, the same issues arise as with other block wise things in life, such as workflow and also graphs to facititate software design.

I've in various ways been into computer design, this page

   http://members.tripod.com/~theover/Z80_web/z80sys.htm

shows a led display unit and dma based drive print I did in highschool (like 1980) after my own design, which still prooved handy when much more recent I did various microcomputer builds to proof some points, and at least also to a crowd I was forced to work with that I DO have the skills to make computer at least tick to begin with, and that may hardware (as it was some years ago) would with good kitchentable equivalent workmanship even be competitive and valid as fast when needed.

Clearly, in certain ways bwise can be use to design, simulate and instruct in such designs, though emulating a Z80 is not so trivial in tcl for instance.

A 7 segment (I did a 35 segment on some of the bwise pages) simulation and the idea of functional logic, and then maybe some clock signals and memory containing units like memory of stack can be quite rewarding though, and is quite possible with bwise 0.34 (which is later than 0.5 mentioned on some older page), though I didn't at all much make it into a decent namespaced, foolproof UI heavily baloon documented, swift to learn and trivial to deploy word like application. I'm not funded for that you see...

Lastly, a very serious use which at times has been the motivation to continue or promote bwise somewhat is software design linked with audio processing (possibly video / graphics too, but I never did that in that way yet).

Some of the above pages mention the drum application which links with the drum button on bwise. When I made that years ago it would on all windows systems I tried render the drum pattern into a .wav audio file which would play as a sound file, which could either be made of completely synthetic drum sounds, or of a set of Lynn drum samples, and sounded more than cool enough in various circumstances to have proven useful.

I didn't recently package the whole into a recent bwise+C source and executables for for instance windows and linux, so I guess some I will have lost on the subject, but it realy works, effectively the executable simply needed to be in the directory bwise was started in, the drum pattern created, drum render pressed, and: wav file played.

I did volume sliders and various other possible bwise extensions and the whole should be useable to design audio flows and audio program execution flows.

A but more recently I linked tcl/tk with a top audio research application I'm still into but didn't get to work on much lately: a real time sound output, midi driven, 3D graphics prepared simulation vibrating stings and electrical guitar like feedback.

That program does about 6 strings each made of about a hundred individually differential equation simulated string segments, string end point damping, and overall feedback under control of a midi synthesizer modulation wheel, velocity dependent, spectrum adapting string excitation and pitch bend on a reasonable fast machine.

I might continue the tck/tk / bwise interface I made for that program also, which allowed a socket connection to (as it can thus far) inquire as to the state of the string(s) at any point in time, while the realtime simulator core is running, and display the displacements as a graph on a canvas.

Finally, and that too has scientific use background, I'd like to be able to lets say program tcl by going from command line to decomposed block notation, preferably automatically both ways, and preferably in good interactive ways like in a shell with globbing and arrow editing...

And than have powerfull relatively simple but non-trivial blocks to do stuff like I made example pages on: decent flow control, socket connections and their basic use, and direct links with OS provided programs, preferably even beyond that: playing around with stdio and connectivity.

Also, I like the idea of the bwise canvas to hold (parts of) a user interface, which makes sense given you can see the connections between the parts. In the time of the NeXT computer, I remember vividly a lecture on making a user interface for a simple program like on the model view controller page, and make that whole work decently and correctly, not that I couldn't, I did interactive real time midi (network) database and midi signal programming long before, and even sold the product to satisfied customers (for not much, btw), but because it isn't dealt with in many classes and because it wasn't at all easy on workstations to do that right, and especially not in a general and framework-like way.

(anyone get to here...?)

---

Category Discussion - Category Bwise