Since my update last week I've been able to smooth over some rough edges, do a little prototype demonstration in ICM (big learning experience there), and get some more predictability in the experience. My process has been all about building the minimum viable prototype of each piece of the project before expanding on each and joining them together one by one. Since last week I got all the pieces running together in rough draft: the sensor makes the ring, the hook switch stops it and starts the narrative interaction, the keypad is fully constructed, and the handset serves as the content delivery system.
There were some headaches, I'll expand on development below:
Hookswitch and ringer
I had been using a momentary press button in place of the hookswitch commonly found in phone cradles to keep my testing ground small, but finally decided I wanted to implement the hookswitch so I could also start working with the code and experience around a switch that would remain open/high for the majority of the interaction. While prototyping with a pushbutton I could ignore the fact that any Serial would be sending the message ~9600 bits per second, thus triggering the sound event as many times. I confirmed with Seho that I was looking for an edge detection, and referenced Tom's state change detection code to do that. I kept the button count in the code because I know I'm going to need it as I refine the narrative navigation. It works like a dream, sending the print line needed to trigger the menu options each time the receiver is picked up off the cradle. yay!
Figuring out how to do the same with the ring, which is triggered by the ultrasonic distance sensor was another story. In prototype mode I had the sensor sending a serial message based on distance to trigger the ringer, but if someone is using the phone for interaction, they are within that distance therefore triggering the ring again.
The problem with using edge detection is that the sensor works by alternating between acting as an output (send ultrasonic signal out) and an input (receive signal, measure time between the two events to calculate distance). Therefore it is constantly on edge. My first workaround was in p5: I used a boolean to compare the serial trigger ("ring") and whether the sound event was playing to keep the sound from triggering again, or only trigger again once a distance outside of the defined trigger zone was logged. Unfortunately, these sensors are particularly noisy and it takes as little as someone shifting out and back in of its sensing area to create a detectible edge.
My current solution is a boolean on the Arduino side, but I still haven't totally figured this one out. I can get the message to trigger the ring, but I haven't figured out how to "reset" it after the first time it prints, therefore forcing me to refresh the sketch to make a new experience for the next person. I expect this to be further complicated by facts to follow...
Handset
One of the most important components of the interaction is delivering the sound of the messages through the phone's actual handset. I was really wary about going in here, as I had to figure out how to splice the phone cord to an aux cable. I was also hoping to be able to use the phone's mic for input sound, but haven't gotten that far yet. I met with Hayley, who helped me figure out the splice. Luckily I was able to use the original curly cord jack, keeping the phone's authenticity.
Herein lies the ringer problem: now that the speaker is effectively in the handset, I have to figure out a new way to make the phone actually ring. The speaker isn't loud enough to make a convincing ring, so I'm in the process of testing out some new ideas. It turns out the bell driver requires upwards 40v to make the bell ring, which is something I just cant wrap my head around right now. I'm currently trying to figure out how to use a vibration motor to shake a piece of metal in the original phone bell; I haven't gotten there yet so I'll have to fake it for play testing tomorrow. But once I do, I have to figure out how to translate the boolean I'm using for the ring sound effect to writing a digital output. I also have to figure out how to have the trigger reset.
Narrative experience
I received 21 calls and about 9 useful voicemails out of them: a lot of people hung up, and other messages were either empty or unintelligible. My hope of organizing the voicemails by theme was thwarted by the fact that all of the intelligible voicemails were fairly optimistic! So I'm testing some other content choices tomorrow during PComp for feedback. It looks like this:
-Press 1 for messages of optimism (all voicemails)
-Press 2 if you think the end is near (mix of apocalyptic soundscaping and samples from movies that consider the end of humanity)
-Press 3 for an extra-terrestrial opinion (alien sounds and boops)
-Press 4 for an existential crisis (not recorded yet, but I think an array of questions you're supposed to ask before you die)
-Presss 0 to repeat options (jumps menu back to "Press 1")
I'm implementing commands that start, stop, and interrupt recordings, and am pulling from preloaded sounds contained within arrays to deliver random message results based on the number pressed. This has been one of the more satisfying challenges to solve. Turns out making an Interactive Voice Response system from scratch is hard AF and a whole other set of logic to consider over the techno-logic. But having the right messages trigger and interrupt the experience at the right moments is a true pleasure. Learning commands like onended to trigger one sound event after another was a lifesaver, but the documentation quite frankly sucks (I will be contributing to the library after finals). You have to create a function that is held within (); after the onended function, which has been fun to play with since you can string them in a sequence of multiple sound events if you plan well.
Video doc
This is how I've been working with the code, keeping all the physical components down to a base minimum and not drag a desk phone everywhere. The button I press is in place of the hookswitch, and I'm using speakers instead of the handset so you can actually hear the narrative:
Code:
Arduino side...
...and P5 side (with editor here: https://editor.p5js.org/medusamachina/sketches/BkvkmCbCm)
Biggest challenge I face
I still have to figure out how to make the experience invisible though, and that's been my biggest challenge. Right now my keypad serves as a sort of sound sampler, so sound events triggered don't negate sound events currently happening. The reason coding an IVR from scratch is so hard is because there are so many variables to account for... it might be out of the scope of my timeline, but I have some ideas on how I can make it possible elegantly with help. I'm going to edit it to the best of my ability to at least fake the seamlessness, and draw a narrative tree to figure out all the connecting dots that I'm missing... which is a lot.
Honestly the invisibility is the most important part of the experience; people have expectations when they see/use a desk phone, and I want my interruption of that experience to be uncanny, not unfamiliar. Which is why the phone can't start ringing when someone is already using it. Aesthetically unimpressive but experientially unexpected. What did I get myself into?
Biggest lessons learned (so far)
Don't get stuck on a task that won't budge. My mantra through the process has been "it all has to get done, so if I get stuck in one place, do something else." While I may have a certain goal, pushing the entire timeline back to make it happen only makes everything take longer. I've chosen to stop and take care of something else in times where I'm bashing my head against the wall... while I may not need that part at the time, it's been a delight and a relief to have that part done and ready when I finally get to that part of the assembly line.
Outline and research everything before going in. My bookmark tab list is organized by things like "phone stuff" "music controller stuff" "sound programming stuff" "keypad stuff" so as I go along I can look into the resource library I created for myself. I can pull references for my time in office hours, and I can test out multiple possible solutions because I've lined them up already.
Make a "to do" at the beginning of each day and a "done" at the end. Keeps me on track and also helps me recognize progress.