I search for solutions in this order: Past Code, Unreal Source, Wiki, BUF, groups.yahoo, google, screaming at monitor. – RegularX

Legacy:WheatPuppet/Thoughts On Pipes

From Unreal Wiki, The Unreal Engine Documentation Site
Jump to: navigation, search

This is going to be really, really old news for Linux or Unix users, but there are a stunning number of computer-savvy people I know that know nothing about I/O redirection. But hell, I go to UVM for Computer Science, so it's not like I'm surrounded by great minds in software development.

Pipes 1[edit]

An Introduction

Pipes are great. I don't mean the kind of pipe that carries water in your house, or even the digital pipe that streams data in and out of your computer when you're connected to the internet. I'm talking about pipes in a more abstract sense.

A pipe is a redirection of material or data from one imagined or physical location to another. The easiest example happens to be the pipes that carry water throughout your house, or through cities. A more abstract example is something that was pioneered in the Unix operating system and later adopted by later versions of Windows. From a command line (black box, white text, most users never get much exposure to it), you can "pipe" the output of one program into the input of another. For instance, if program A prints out:

 HELLO WORLD!

And you piped it into another program that puts "You said: " before whatever you would normally type in, the output would be,

 You said: HELLO WORLD!

And now, assume that you piped this output again into the program described above, which would say:

 You said: You said: HELLO WORLD!

The Unix-style pipe allows you to move the output around from one program (or "place") to another, creating an output that's refined to what you want as a user. This is really great for making filtering programs that parse through the output of a given program and returns only what matches the filter. A great example of this is the Unix programs "ls" and "grep". The program ls displays the contents of a folder on a command line, the program grep filters the result of a program and returns only those things that match. For example, if the output of ls was:

  • My Programs
  • My Documents
  • Music
  • Pictures
  • My Videos
  • Download
  • Wallpaper
  • Trash

And you ran it through grep filtering out and returning any line with the word "My" on it, it would return:

  • My Programs
  • My Documents
  • My Videos

Likewise, you could have it filter out any lines that contain the letter "e", if you wished. (This is handy when dealing with different versions of files, since you can filter out all files with a certain number in them) That would look something like this:

  • My Documents
  • Pictures
  • My Videos
  • Wallpaper

Pipes 2[edit]

Some Thoughts

So what's the beauty in a pipe? You can filter output, but you can't do much else, right? Wrong. A pipe also lets you build ad-hoc switches. For instance, let's say you have a bunch of lengths of pipe (real physical pipe, not the software one), and you have a bunch of valves that can direct water one way, or another. So, you hitch up your pipes with a valve between each length, something like this:

 >–V--V–V--V–>

Where the arrows indicate the flow of water, and the V indicates a valve. In this situation, you can use the valve to direct the water in two ways–either to continue along the pipe, or to pour it out onto the floor. You can do the same thing with programs, with each valve in the above example being a program. The program can either produce an output (pour the water onto the floor), or stream its output into another program.

The reason I think this is so interesting is in the interest of modularity. Let's say, for instance, that I were to design a stereo setup with a modular philosophy in mind. Most reasonably high-quality stereos have RCA jack ports in the back (or sometimes in the front) that allow you to input things into it. For instance, you can get the right cable and plug your MP3 player into your stereo, letting you play your MP3 tunes through superior speakers. This is great, but what if you wanted to run your MP3 player through an amplifier or equalizer and then to your stereo? You either have to buy more cables (to connect the amp to your stereo), buy a new stereo (with a built in amp/equalizer), or be content with tinny-sounding music. Why not build the stereo with a port that allows you to connect the amplifier or equalizer directly to it, making the two pieces of equipment one. At the bottom of your amplifier, there would be an identical port, allowing you to connect another component. Thus, you could build a stereo that had exactly what you wanted, instead of having a monolithic stereo that may have some features you want, and some you will never use. So if you just wanted a core stereo, with no bells and whistles, you'd buy the core stereo component with no add-ons. Later, if you wanted an equalizer, you could go and buy the equalizer, and it would be as simple as attaching it to the bottom of your previous system. If you then wanted a visualizer that gave you a small graphic display of the output at different frequencies, or a display showing a Fast Forier Transform image (some electro-geeks will understand what I mean), you can buy components to do each of those things.

This idea mimics the example of pipes above. Each component would have its own audio-out, allowing you to sample the sound from any of your components, the equivalent of turning the valve to dump the water on the floor, or to have a program display its output. Similarly, you can allow the stream of sound to pass through all the components, and all you needed to do was to plug into the core stereo device, which would play the aggregate of all the connected components.

That's it... for now. I'll probably write more.

Comments:[edit]