The End of Hearing: feedback #3

I have processed all the collected feedback (64 forms in total) and this is what it looks like after quantifying, summing up and distributing all the data:



Initial feedback conclusions:

1] we believe that future can be shaped and that design can help us do this;

2] we value hearing and think that we can adapt to future soundscapes;

3] we are undecided about the role that noise plays in our lives.

More specific conclusions should be published soon.

The End of Hearing: scenario diagrams

To assist explaining the scenarios I prepared for the final show, I created three posters, which guide through the complicated processes of sound conditioning and blasting, radio signal reception through the AIR implant and artificial silence vaccinating using the Otomixer.

The posters are not intended to be self-explanatory. The processes are just too complicated to place them on one poster and not make it look too busy. And anyway, I wish to have those conversations with people coming to the show, asking questions, making strange suggestions, not understanding half of what I would be saying...

These are the posters:

Noisecode keyboard

The main part of Noisecode media platform I've recently developed is a hacked and customised keyboard which I have got from my friend, Jessika.

It consists of four parts.
part 1—standard QWERTY keyboard, which all are familiar with. It is in its usual place on my keyboard and looks just like all of them. Nothing new and surprising—you'll know what it does and how to use it.

part 2—noise key set, on far right of my customised keyboard. It has 7 keys, each coding a single shape/colour of a noise. Hitting two noise keys produces a pair of noises coding a single letter according to language currently used.

part 3—languages: three keys positioned in the top part of my keyboard should be used to change the language of Noisecode transliteration. As for now there is English, Polish and Italian coding available.

part 4—transformations column: the heart of my customised keybard. Facilitates all possible transformations supported by Noisecode application: speech to text (provided the computer has a speech recognition software installed), text to speech, text to noise, text to shapes, shapes to noise, shapes to text. This part link part 1. and part 2. together. The output always depends on the selection made in part 3. of the keyboard.

noisecode: IT

After considerably long time (and with help of Davide Iemmola, my friend from CSM–MACD) I managed to code Italian alphabet. This posed rather different difficulties than in case of Polish alphabet, as instead of compressing the alphabet to fit my set of 28 variables (suited perfectly for English!) I had to extend the content. I managed to do this in a truly surgical fashion by throwing 5 noises away. My decision was to cut on the double-noise pairs, so the only doubles to remain would be 'space' and 'start' which remain constant in each language coding.



As said before, Italian alphabet consists of 21 letters (ABCDEFGHILMNOPQRSTUVZ), 10 digraphs (ch, ci, gh, gi, gl, gn, ha, qu, sc, zz) and 3 trigraphs (gli, sch, sci). These rules helped with assigning right letters to right noises.

noisecode: interlingual faultiness

Having a fixed set of variables (nucleobases in nucleic acids of DNA / zeroes and ones in informatics / letters in alphabet / noises in noisecode) we can encode with its use any piece of information we want. Information can be also transcribed from one code to another, providing the codes conform with one aother.
Since transcribing Polish into noisecode I have been able to experiment with two languages. Interestingly enough, what proved to be most fascinating now is the faultiness of transcribing from English into Polish and the other way round via noisecode. These are three examples of what happens:

• >HELLO_WORLD> is transcribed into a set of noises according to noisecode.en;
• transcribing this set noises back into letters but using noisecode.pl rules gives an output of: >ZUFFA_OASF[łż]>;
• transcribing >HELLO_WORLD> into a set of noises according to noisecode.pl ans then filtering it back through noisecode.en produces: >CUGGW_QWZGS>.

• >NOISECODE> processed through noisecode.en;
• noisecode.en set put through noisecode.pl: >JAILUHA[łż]U>.
• >NOISECODE> processed through noisecode.pl;
• noisecode.pl set put through noisecode.en: >PWIRUVWSU>.

• >PAŹDZIERNIK> (October in Polish) processed through noisecode.pl;
• noisecode.pl set put through noisecode.en: >NOHFSHIUZPIK>.
Note: there is an extra letter in the noisecode.pl-en output. This is due to double-coding of Polish special characters which are indicated by a set of two pairs of noises. In this particular case it is: Ź = [Z]+[ćńóśź].
• >PAŹDZIERNIK> processed through noisecode.en;
• noisecode.en set put through noisecode.pl: >N[ąę]R[łż]RIUSPIK>.
Note: the reverse situation occurs in this case. In order to transcribe letter Ź into noisecode.en it has to be simplified—therefore, Ź becomes Z in the noisecode.en output.

noisecode: PL

Noisecode covers now a second language—Polish.
Polish contemporary alphabet contains 32 letters. There are 9 unique characters with diacritic symbols (Ą, Ć, Ę, Ł, Ń, Ó, Ś, Ź, Ż), and there is no Q, V and X—this makes a total surplus of 6 characters in comparison to English alphabet. Due to this number noisecode had to be either extended by a new noise, or special characters had to be combine-coded by a sequence of a base letter and a diacritic symbol. I chose the latter option, mainly because having kept a constant set of noises enables me to contrast and compare noisecode.pl with noisecode.en. Therefore, 9 characters in noisecode.pl are expressed with a set of two pairs of noises instead of a single pair as in case of standard letters.



Yellow lines indicate combine-coded special characters:
base letter linked with a diacritic symbol.
Grey lines indicate dighraph rules.
Dotted lines indicate a trigraph rule.

Apart from the set of noises used to code letters in noisecode.pl, there are some other important similarities shared with noisecode.en:
• all vowels are composed with the 'mains hum 60Hz' noise (with the 'Hum+Hum' pair coding the diacritic symbol used for A and E only and transforming them into nasal vowels);
• coding of start/stop and space stays the same;
• the digraph and a trigraph rule is used to code letter clusters.

Note two significant differences between noisecode.PL and niosecode.en which may have great impact on the final audio form of each language:
• Polish alphabet contains more characters and, therefore—according to the alphabet principle—...
• ...there is much less digraph/trighraph rules in Polish alphabet (PL=8/1 while EN=35/5).

noisecode: the ellipse of noises

Finally I managed to assign noise pairs to letters. This wasn't an easy task. Starting with vowels, it took me quite a while after I finally knew what goes where. Well, there's the final diagram presenting the whole alphabet with it's typographical and noise-graphic representation.

noisecode: vowels and digraphs

After abandoning the typographic method for assigning 28 noises to 26 alphabet + 2 punctuation signs, I felt lost and rather helpless about moving forward with my noisecode project. I considered phonetics as a key to the problem, but that would need me to develop at least twice as many noises (and likely to produce 3-element variables instead of current 2-element ones), as well as abandon my idea of creating a written alphabetical code.

As written realm provided to little rules for me to base noisecode on and phonetics offered to many of them, I decided to search for a solution in between. Ultimately, it is vowels and digraphs that should be credited for solving the problem.

Vowels
There are 5 vowels in English alphabet (A, E, I, O, U), as well as 2 semi-vowels (W, Y) depending on the word they appear in. In total there is 7 letters which act as vowels, which is defining a syllable. As noisecode is based on a set of 7 noises composed into unique pairs, I decided to assign one particular noise to become typical for vowels only. I chose mains hum, because even when accompanied by other noise it is still well head and distinguishable. Thereby, I hope to strengthen the specific language rhythm that will be heard in texts translated to noisecode.

Digraphs
"A digraph is a pair of characters used to write one phoneme (distinct sound) or a sequence of phonemes that does not correspond to the normal values of the two characters combined". (source: Wikipedia)

There is 41 English language digraphs which I used as rules in noisecode:
ae / ai / au / aw / ay / cc / ch / ci / ck / dg / ea / ei / eo / eu / ew / ey / gm / gn /
ie / kn / mb / ng / oa / oe / oi / ou / ow / oy / ph / ps / qu / rh / sc / sh / si / th /
ti / ue / ui / wh / wr.
Apart from that I used 5 English trigraph rules: igh / ous / sch / ssi / tch.
The rule is a formal requirement for both noise pairs coding a digraph to have at least one common elemental noise, e.g. TH digraph consists of T and H which both are coded by two noise pairs consisting of one common element (grey noise) and two other noises being the second element in each pair (brown noise in T, white noise—H).
The only exception to this rule is OUS trigraph, where there is no common noise for all three letters, however each pair of subsequent letters has the rule applied: mains hum is the common element in OU-, pink noise provides the rule for -US.

Whether vowels and digraphs rules would prove to be viable solutions to my problem with the method of assigning noises to letters, this is what next translations into noisecode will show. I should create some samples shortly.