标签: sound

My dreams have come true. I am currently performing my happiest of happy dances (it's not a pretty sight). Let me explain. For the longest time, I've been looking for a sound effects card to use in my hobby projects. In the case of my Inamorata Prognostication Engine, for example, the front panel is festooned with antique push-buttons and toggle switches and knobs and dials. When I flick a switch on this little beauty, I don’t want to be disappointed with a sheepish "click" that sounds embarrassed to be making itself heard. My ears deserve to be caressed by a satisfying "ker-thump," followed by the sounds of clockwork contrivances and mechanical mechanisms and balls rolling down chutes and suchlike.   Sad to relate, I couldn’t find anything to fit the bill. For some applications synthesized sound might be the way to go, such as the effects one can obtain using a GinSing Shield , for example. In the case of my projects, however, I want to use real-world sound samples, so next I looked at traditional audio shields such as the WAVE Shield from Adafruit.     The WAVE Shield is described as being ideal for adding audio effects to one's projects. The problem is that -- like the vast majority of cards of this ilk -- it can only play a single audio file at a time. For my projects, by comparison, I want to be able to add "layers of sound" corresponding to different actions taking place.   Eventually, a group of us started to consider designing and building our own card, as discussed in Sound Effects Shield for Arduino: The Particulars . This project has been shuffling along in the background, but everyone is busy and nothing really substantial has emerged.   And then, just a couple of days ago, my chum Duane Benson sent me an email saying:   I've been busy getting ready for Maker Faire and haven't had time to work on our sound player, but this sound effects board may be what we're looking for.   "This" turned out to be the WAV Trigger board, which is supplied by our friends at SparkFun, but which was actually created by my new hero Jamie Robertson, who is a senior Disney Imagineer by day and a mad scientist designer by night (check out Jamie's Robertsonics.com website).   OMG! As I said at the beginning of this column, the WAV Trigger board is the answer to my dreams. The key feature is that it's Polyphonic , which means "many-voiced" or "capable of producing many sounds simultaneously." In fact, the WAV Trigger can play and blend up to 14 stereo audio streams at the same time, where each stream can be started, paused, resumed, or terminated independently. The board also automatically performs voice stealing , which means that -- if it's told to play a new audio stream while it is currently playing the maximum number of streams -- it will automatically drop the oldest audio stream and add the latest request to the mix.   The way this works is that you use an audio editor like Audacity to prepare your sound snippets on your host computing platform (Windows, Linux, etc.). You can use your own sound bites and/or you can download them from loads of websites. Then you copy these sound files onto a Micro-SD card, which you plug into the WAV Trigger board.   The board I have supports up to 1,000 uncompressed 16-bit, 44.1kHz stereo WAV files (CD-quality), which is way more than I personally need, especially remembering that I only require short sound snippets and an 8GB Micro-SD card can hold over 12 hours of stereo WAV audio. (I was chatting with Jamie on the phone earlier, and he is currently working on a new version of the firmware that will support up to 2048 tracks.)   The simplest way to use the WAV Trigger is by means of its 16 trigger inputs, which can be set to be edge or level sensitive, and which can be controlled by simple switches or by a microcontroller. In this case, activating a trigger input will cause a corresponding audio file to be added into the mix (the trigger-to-sound delay is typically only 8 milliseconds). Alternatively, you can control the WAV Trigger using a simple serial protocol -- an Arduino Library is available to make this easy -- that allows you to access all 1,000 sound files. But instead of my waffling on, check out This Video and tell me what you think.   iframe width="400" height="360" src="https://www.youtube.com/embed/UUkcs_XL5x0?feature=player_embedded" frameborder="0" allowfullscreen/iframe   I can’t help myself. I'm currently chuckling and chortling with delight. My WAV Trigger is sitting here on my desk looking up at me with a "hello handsome, are you ready for some fun" look (metaphorically speaking). What can I say? Yes, I am indeed ready for some fun. Watch this space for future updates as I integrate WAV Triggers into all of my projects.

This is a followup to my previous blog on this topic, the "crux of the biscuit" being that I need a sound effects shield for my Arduino/chipKIT-powered hobby projects.   In the case of my Vetinari Clock , for example, I want to start with a "tick-tock" sound, and I want this sound to be overlaid with other effects, giving the impression of mechanical mechanisms and pneumatic processes working away in the background. Similarly, in the case of my Inamorata Prognostication Engine , when someone flicks a switch, I want to hear the sounds of balls rolling down chutes and cunning clockwork contrivances performing their magic.   One very important point is that I don't wish to synthesize these sounds; I want to use real-world sound snippets, such as the ones you can download for free from websites like Freesound.org . These typically -- and not surprisingly -- sound so much more realistic.   Another important point is that I have no desire to premix all these sounds. I want to be able to set multiple sounds running at the same time, or to have one sound running and then kick more sounds off at later times as required.   As an aside, the concept of mixing multiple audio streams is quite interesting. Suppose we start with two streams, A and B. For simplicity, we assume each stream can have a value between 0 and 1. Our knee-jerk reaction might be simply to add them together and divide the result by two; that is, Z = (A + B)/2. However, a moment's thought reveals that this is valid only in the case where both A and B are at the maximum 1 value. Suppose that A is at 1 while B is at its minimum 0. If we use our original equation, we end up halving the value of A, which is not what we want. A much better approach requiring minimal computational overhead is to use the formula Z = (A + B) - A*B, which allows the contributing signals to be heard clearly without distortion or perceived loss of volume. Viktor Toth explains all of this very nicely in his post " Mixing digital audio ," but I digress.   My chum and EE Times blogger Duane Benson is also interested in having access to these sound effects shields for his own hobby projects. Having searched the Internet, however, we've come to the conclusion that nothing out there really seems to fit the bill, so we've decided to develop our own.   The more we think about this, the more we think this sort of card would be of interest to many of our fellow hobbyists. We have toyed with the idea of launching another Kickstarter project, but -- to be honest -- that's probably more trouble than it's worth. As usual, of course, we will make this project open source and provide all the design and software files so anyone can join in the fun. Also, depending on the amount of interest we receive, it may be that we decide to offer these little beauties for sale, but we're not making any promises here. The main thing, as far as I'm concerned, is that I have these shields for use in my own projects.   The first thing to do in this sort of situation is to tie down the specification. Actually, this would be true in an ideal world, but Duane is already off and running experimenting with SD memory cards, so we really need to hammer out the specification as soon as possible. Otherwise, goodness only knows where we'll end up. For the past few weeks, Duane and I have been bouncing ideas back and forth on the phone. Our mission is to create something really, really useful while keeping the cost and complexity down as much as possible. What I'm going to do here is to summarize our thoughts and ask you to comment on our ideas and to make your own suggestions. File format: We aren't interested in supporting every audio file format known to humankind. We both have great respect for Adafruit. Since it decided that 22KHz uncompressed monophonic WAV files were good enough for its Wave Shield , we've decided to go with the flow and adopt this as our format. This means that, whatever format is used to store the original sound snippets, we will suck them into some sound editing program like Audacity and output them as 22KHz uncompressed mono WAV files. File naming: For the sake of making our lives simple, we will store our sound files with a traditional 8.3 alphanumeric file naming convention using only uppercase alpha characters and numbers. File storage: We considered creating our shield with a USB interface so that it would look like a USB memory stick when connected to a host computer, but we decided this would overcomplicate things. We've decided to go the SD card route. In this case, we will copy the WAV files from the host machine on to an SD card and then plug the SD card into our shield. File lengths: Each sound file can be any length required -- limited only by the available storage. Number of streams: This has yet to be established. The maximum number of audio streams will be determined largely by the SD card interface bandwidth, but processing considerations may play a part. As a working goal, a minimum of six concurrent audio streams should be supported. Mono vs. stereo: : Even though the audio/WAV files are mono, the shield will support two separate audio output channels that we'll refer to as "Left" and "Right" for simplicity. (The way this will work is discussed below.) Amplification: The shield will contain its own amplification (amount to be decided). By default, both the Left and Right channels will be enabled, but it will be possible to disable either or both channel amplifiers via jumpers and to feed the corresponding line outputs to off-board amplification. Interface to Arduino: We've decided that this will be via I2C, and that the two pins used for the I2C interface will be the only Arduino pins affected by our shield. Also, our shield will have some default I2C address (to be decided), but it will be possible to modify this using soldered jumpers on the shield. We might also offer SPI support in addition to I2C, but this has yet to be decided. Things may seem relatively simple thus far, but when we consider the actual usage model, things become a little more mind-boggling.   We plan on providing an Arduino library and example sketches to accompany our sound effects card. Let's assume that we instantiate our sound card as an object called something like "sound_fx." Assuming that some sound files stored on the SD card are called "VCSFX001.WAV," "VCSFX002.WAV," and "VCSFX003.WAV," the simplest command scenario might look something like:   sound_fx.setup("VCSFX0001.WAV"); sound_fx.play("VCSFX0001.WAV");   There will be a number of parameters associated with the ".setup" command. Any parameters that aren't specified will automatically adopt their default values. For example, the sound file(s) associated with each ".setup" call will be sent to both output channels by default, but it will be possible for the user to explicitly specify "LEFT," "RIGHT," or "BOTH"; for example:   sound_fx.setup("VCSFX0001.WAV", channel=LEFT); sound_fx.setup("VCSFX0002.WAV", channel=RIGHT); sound_fx.play("VCSFX0001.WAV, VCSFX0002");   Observe that the ".play" statement can accept a comma-separated list of file names, in which case all the files in the list will start playing at exactly the same time. (In addition to this, should we provide a delayed start capability?)   Now, what should happen if a ".play" command is issued to a file that is already playing? Off the top of our heads, it would appear that there are three possibilities: Terminate the current instantiation and restart this file from the beginning. Add this new instantiation into the queue and start playing it immediately after the current instantiation finishes running. Treat this new call as an independent audio stream and start playing it concurrently with the current instantiation(s). I think we will go with the third option, because it's easy to envision a case where you might want to have multiple instantiations of the same sound file playing offset in time. For example, imagine the whistling sound of a bomb falling -- you might want to start a second instantiation of this sound before the first has finished. Furthermore, we can implement the first two options by means of the ".remaining" and ".stop" commands discussed below.   It should be possible to assign a volume to each file in its ".setup" statement, where the assigned value is an integer between 0 and 100 that will represent a percentage. (The default setting will be 100%.) For example:   sound_fx.setup("VCSFX0001.WAV", volume=100); sound_fx.setup("VCSFX0002.WAV", volume=75); sound_fx.play("VCSFX0001.WAV"); delay(1000); sound_fx.play("VCSFX0002.WAV");   In the above example, observe that, in addition to being set to 75% of its full volume, the "VCSFX0002.WAV" file will start playing 1,000 milliseconds (one second) after the "VCSFX0002.WAV" file.   Additional parameters that can be used in a ".setup" statement will be "fade_in" and "fade_out," each of which can be assigned an integer value in milliseconds. In the case of a "fade-in," that file will ramp up in volume (in a linear manner), starting at zero and increasing over the specified time until it reaches whatever level was assigned to the "volume" parameter. The way in which the "fade_out" parameter is used is left as an exercise for the reader.   It doesn't matter how many audio streams are currently playing (up to the maximum number supported, of course). At any time, it should be possible to add a new sound file/audio stream to the mix.   It should also be possible to determine how long a file has left to run in milliseconds. Assuming that we've already declared a long integer called something like "time2Go," it should be possible to use a statement along the lines of:   time2go = sound_fx.remaining("VCSFX0003.WAV");   If the file has already finished playing, a value of -1 will be returned. Last but not least, it should be possible to terminate the playing of any file using a ".stop" command. For example:   sound_fx.stop("VCSFX0003.WAV");   As for the ".play" command, the ".stop" command should accept a comma-separated list of files. Also, no problems should result from issuing a ".stop" command on a file that has finished playing or was never playing in the first place. I've mentioned this before, but I should probably state it again -- neither Duane or myself are audio experts. We're pretty much making this up as we go along, and we would very much appreciate any input you might care to share with us.   For example, do we need to work with 16-bit audio data, or would 12-bit data be sufficient? If we work with 16-bit data "internally," would it be OK to reduce this to 12-bit data when outputting the audio?   Which microcontroller (MCU) would best suit this application? Would a dual-core device boasting an ARM Cortex-M0 and an Cortex-M3/M4 be the way to go, or do you think we can do it all with a single Cortex M0? Is there a device with suitable digital-to-analog converters (DACs) on-chip, or should we use external DACs?   Do you like the ".setup", ".play", ".remaining", and ".stop" functionality we're pondering? Would you use different terminology? Would you implement this in some other way?   In addition to being able to associate "channel," "volume," "fade_in," and "fade_out" parameters with each file as part of the ".setup" command, are there any other features and functions we should consider implementing?   Actually, thinking of features and functions, in addition to playing a sound file a single time and then stopping, should we offer the ability to keep on playing a sound file over and over again? If so, how should we implement this? One option would be as a "run" parameter in the ".setup" command with two options -- ONCE (the default) and LOOP. For example:   sound_fx.setup("VCSFX0001.WAV", run=LOOP); sound_fx.play("VCSFX0001.WAV");   Another possibility would be to complement the ".play" command with a ".loop" equivalent. For example:   sound_fx.setup("VCSFX0001.WAV"); sound_fx.loop("VCSFX0001.WAV");   However, we previously suggested that the ".play" command should support a comma-separated list of files, each of which may be of a different length. The fact that the files can be of different lengths isn't a problem if each file is played only a single time, but what happens if we are playing them multiple times? Should each file restart as soon as it finishes, or should the shield wait for the longest file to finish before restarting them all from the beginning?   Actually, there are multiple issues with the implementation plan discussed above. For example, suppose we want to be able to start playing one instantiation of "VCSFX0001.WAV" at 100% volume out of the Left channel, and then sometime later -- while the first instantiation is still playing -- we want to start playing another instantiation of "VCSFX0001.WAV" at 75% volume out of the Right channel. We can't do this with our current model -- or can we?   Similarly, what happens if we have two or more instantiations of "VCSFX0001.WAV" playing and we run a ".remaining" or a ".stop" command with this file name as a parameter? To which instantiation should the command apply?   One possibility would be to associate an ID number with each ".setup" command, and for the other commands to use these ID numbers as opposed to file names, but this is confusing to the user, and it opens up additional cans of worms.   Of course, it may be that I'm overengineering everything. (It wouldn't be the first time.) There are ways around these things. For example, consider the following:   sound_fx.setup("VCSFX0001.WAV", channel=LEFT); sound_fx.play("VCSFX0001.WAV"); delay(1000); sound_fx.setup("VCSFX0001.WAV", channel=RIGHT); sound_fx.play("VCSFX0001.WAV");   This would allow us to play the same file out of the different channels at different times (and with different volumes if we specified the "volume" values). Similarly, we could simply say that, for multiple instantiations of a file running at the same time, the ".remaining" and ".stop" commands work with the earliest instantiation.   Hmmm, this is something to mull over, and no mistake. This is a typical engineering problem in that we have lots of tradeoffs that compete against one another. On the one hand, we want to make our sound effects shield as versatile as possible, so that it is applicable to many different usage scenarios. On the other hand, we want to make it as easy to understand and use as possible, because a lot of its potential end users aren't computer experts.   This is the point where we open the floor for suggestions. Do you like the model proposed above? Would you make additions, subtractions, or modifications? Or would you throw it all out and start again?  

I must say I am in a bit of a quandary. Things are racing merrily along with regard to several of my hobby projects, including my Vetinari Clock and my Inamorata Prognostication Engine , but now I've hit a stumbling block.   The thing is that I'm planning on equipping both of the above projects with sound effects, but I'm not sure how to go about achieving the effects I require. In the case of the Vetinari Clock, for example, I'm going to want a "tick-tock" sound. When we reach the turn of the hour, I'm going to want a straining sound ending in a "Ker-thump" as the hour hand moves to its new position. I'm also going to want a variety of mechanical clockwork sounds, along with some hydraulic and pneumatic sounds.   Similarly, in the case of the Inamorata Prognostication Engine, when someone flicks a switch, for example, I want to have sounds like clockwork gears grinding, ball bearings rolling down slopes and dropping through tubes, and all sorts of other effects. All of these projects are being powered by Arduino microcontroller development boards. My first thought was to use a GinSing Shield . I have one of these little beauties and it may well end up being used in one of these projects at some stage, but only for the occasional effect.     However, for my projects, in the majority of cases, real-world sounds simply sound superior (try saying that quickly). In some cases, I might decide to record these sounds myself; alternatively, there are a variety of websites from whence one can download free sound snippets, such as FreeSound.org .   The next point is how to play these sound snippets. Originally I was planning on using a Wave Shield from Adafruit.     On the bright side, this little scamp can play uncompressed 22KHz, 12-bit, mono Wave (.wav) files of any size, and it sounds really good, but... it doesn't really do what I want it to. First of all it uses a lot of the Arduino's pins, which is a pain. Also, it pretty much ties to the Arduino -- you can't do much else while you are playing a sound. My initial plan was to use a dedicated slave Arduino to drive the Wave Shield, and to have a master Arduino to control everything, including telling the slave Arduino what sound file to play.   But this still doesn't address all of my requirements, the largest of which is that I might want to play (and mix) multiple sounds simultaneously. In the case of the Vetinari Clock, for example, I might want to set the "tick-tock" sound playing continuously in the background, and then superimpose one or more other sounds on top depending on the current time and on what's happening in the outside world and so forth.   What I want for Christmas I was brain-stem-storming this topic with my chum Duane Benson earlier today. Duane also has a number of Arduino-based projects on the go that will eventually require some sound effects capabilities.   Following my discussions with Duane, here's what I would like in an ideal world. As a starting point, I want an Arduino Shield with an Arduino Uno form factor. I want this shield to have a lot of memory so as to be able to store a lot of sound effects -- let's say 4GBytes of Flash Memory.   In addition to downloading sound snippets to my PC from places like FreeSound.org, I want to be able to create and edit my own sound files on my PC using some program like Audacity . (Note that I don't mind having an 8.3 file naming convention limitation; also, I don't mind being limited to using uncompressed WAV files.) Now, here's an important point -- I want my shield to have a mini-USB port. I want to be able to use a USB cable to connect the shield to my PC, and for the shield to look like a regular USB memory stick. In particular, I want to be able to drag-and-drop sound files from my PC to the shield.   The shield should provide any necessary processing capabilities. The communication between the Arduino and the shield should be via I2C (in addition to the shield having a default I2C address, this address should be modifiable via solder links on the shield). The two I2C pins are the only ones the shield should use. All of the Aduino's other pins should be left free for other tasks.   A sketch running on the Arduino should be able to issue commands to the shield over the I2C buss. At a minimum, these commands should include something like "Play sound file xxxxxxxx.xxx" (which plays the file once) and "Loop sound file xxxxxxxx.xxx" (which plays the file over and over again). In the case of the Loop command, the default would be to start replaying the file as soon as we reach the end, but it should also be possible to add an optional time parameter like "Every 60 seconds," so a 10-second sound file would play once every 60 seconds, for example.   It would also be nice for the sketch running on the Arduino to be able to query the shield with regard to the state of a particular sound file to see if it's still playing and -- if so -- how long it still has to run. It should also be possible for the Arduino to terminate the playing of a particular sound file, where said termination can be qualified by a specified fade time in seconds (a value of 0 would be the same as the default, which is to simply stop playing that file immediately).   Perhaps the most important aspect of all this is that the Arduino must be able to request that multiple sound files be played simultaneously -- the shield would be responsible for mixing the various audio streams. I'm not sure what limitations this would place on the system. I presume that there will be some limit to the number of channels that can be streamed depending on the memory access time and other factors that I haven’t wrapped my brain around as yet.   For my projects, a mono system would be sufficient. I'm open to suggestions as to whether a stereo capability would be required; if so, when the Arduino requests that a particular sound file be played, it would need to be able to specify to which channel the sound should be directed (the default would be "Both").   Ideally the shield would have its own power supply and will include on-board amplification that can directly drive the speaker(s), but it should also be possible to disable this amplifier and to feed the output to an external amplifier if required.   So, are you aware of anything like this that's already available? If not, do you think other people would be interested in having such a capability for their hobby projects? I must admit that Duane and I were wondering if this would make a suitable Kickstarter project. Last but not least, do you have any thoughts as to the way in which all of this could be implemented? Is there a specific processor (or other device) we should use for the shield? What about a multi-stream sound mixing chip? Any suggestions would be gratefully received.  

Real Sound Lab声功率音场校正系统方案       音响系统中，由于电子电路失真、喇叭制作工艺和腔体材料等所造成的各种音频还原过程的失真，导致声音粗糙干涩。      经世界音频处理权威“声功率音场校正系统“校正后，声音细腻饱满。     公司得到Real Sound Lab授权将   植入CSR8670蓝牙模块（内置DSP），再针对每个音响特性做相应补偿处理和相位矫正，得到最佳的声音还原效果，以确保声音不损失，音质细腻饱满。        特点：电路简洁、喇叭要求不高，效果出人意料        适应：一体化有源音响、高端耳机 技术交流:QQ2680651745

I have this ever-evolving paper on Color Vision , which I am quite proud of.  Have you checked it out? For example, if you do a search for "Color Vision" on Google, this paper currently comes up as the seventh entry, which is rather good going when you consider the abundance of information that's now available on the web. Anyway, one of the topics in this paper is titled "Seeing sounds and tasting colors" . This refers to something called synaesthesia, in which the stimulation of one sets of sensory inputs (say sound) is simultaneously perceived by one or more of the other senses (sight or touch, for example). As you will see (below), I actually found an engineer who sees black-and-white gate-level schematics in colour. Anyway, I was just thinking about how cool context-sensitive editors are – you know, the ones like Verilog editors where the various syntactical elements are displayed in different colours – and I started to wonder if there were any synaesthete design engineers who see black-and-white RTL in colour. Read on and you'll see that I mean... The following is abstracted from my Color Vision paper: Synaesthesia The word synaesthesia (also spelled synæsthesia and synesthesia) is derived from the Greek syn, meaning "together" or "union", and aesthesis or aisthesis, meaning "senzation" or "to perceive". Thus, depending on who you are talking to, synaesthesia can be taken to mean "synthetic experience" or "joined sensation" or "to perceive together". And if you think this is confusing, just wait to see what's to come... In a nutshell, synaesthesia embraces a variety of different conditions in which the stimulation of one sets of sensory inputs (say sound) is simultaneously perceived by one or more of the other senses (sight or touch, for example). There are many different forms of synaesthesia. For our purposes here, we are primarily interested in those that pertain to colour vision. One very common type is when folks associate numbers and letters of the alphabet with different colours. For example, consider the way in which a non-synaesthete would see the alphabet printed as black text on white paper as illustrated below:   Now consider the same alphabet – still presented as black text – as it might be seen by a synaesthete as illustrated below:   Note that the above is simply a representation I created in Visio. Every synaesthete (of this type) perceives his or her own colour alphabet. Having said this, research on a large number of synaesthetes reveals certain trends, such as the fact that 'a' is often red, 'b; is often blue, 'c' is often yellow, and so forth. Another interesting point is that some synaesthetes "see" the letters as being black, but "perceive" the colours as being "associated" with the letters. By comparison, other synaesthetes actually do "see/perceive" the letters as having those colours. And what about words. Well let's start by considering the way in which a non-synaesthete would see a group of words printed as black text on white paper as illustrated below:   For some synaesthetes, each word will appear as (or be perceived as being associated with) a colour that is derived from the individual colours of that word's constituent letters. By comparison, other synaesthetes may "see" or "perceive" the words as having colours that are not related to the letters associated with their particular colour alphabet. An example of this latter case might be as illustrated below:   As a slightly different example, consider the following illustration, which comprises a random assortment of the numbers 2 and 5. Can you quickly count how many number '2' characters there are?   For the non-synaesthetes amongst us, counting the number of '2' characters in the illustration above may require a little concentration ("Did I already get that one?"). Well, now consider the way a synaesthete might perceive this same image as shown below:   Wow! Now (assuming you're not colour blind), it's really easy to see that there are only eight number '2' characters surrounded by a plethora of number '5' characters. How cool! It's important to note that synaesthesia is additive; that is, it "overlays" the primary senses. Also, we should remind ourselves that there are many different types of synaesthesia. For example, when some synaesthetes hear music, they might see patterns of colours hovering about three feet in front of them. A trill of the flute may appear as a collection of purple triangles and small pink dots, for example. (It is said that if a non-synaesthete wants to get a feel for what this might be like to experience, a good start would be to watch appropriate portions of the original Fantasia movie by Walt Disney.) So how many of us are synaesthetes? This is really difficult to pin down, because there are so many different types (listening to music can cause a tickling sensation of touch, or a perception of different smells, or ...), and different folks can be affected to lesser or greater amounts (a "feel" of a colour versus actually "seeing" that colour). Some estimates put synaesthetes as being roughly one in 25,000, while others say one in 2,000, and still others say as many as one in 100 may by synaesthetic. Does this latter value seem high to you? Well, consider that if people are asked to associate different colours with different notes on a piano, the vast majority of us will associate darker colours with lower notes and lighter colours with higher notes. Why should this be (considering that colours and tones have nothing intrinsically to do with each other) unless we are all synaesthetic to at least some small degree? Now, this is where things start to get interesting. I'm an electronic and computer design engineer by trade. Over the course of the years, I have spent a lot of time looking at schematic (circuit) diagrams composed of symbols representing Boolean logic functions such as AND, OR, XOR, and NOT.