Hi there,
If you are reading this chances are you are coming from the set of three posts I made about my experiences in building a Max 6 patch which would allow me to playback surround sound files in accordance to ITU BS.1116, record and process the results.
One thing that struck me when reading them is how much the patch has changed and changed overnight in many cases. I have just setup the blog via email feature of WordPress, so I thought there would be no harm in a final post to outline how the Max patch works. Hopefully, it will be a good source of information to any students out there who want to have a go building their own patch! Note that this is a long post but I did not want to split it up into sections for the sake of clarity.
This is the beast. Actually, it is not too bad. What you see here is the randomising section at the top followed by the test section of the listening session. The test section is identical in make up to that of any other section, so there is little point in showing you an even worse resolution photo of that!
Lets take a look at it piece by piece.
This is one of the 12 segments of the Randomisatron as I like to call it. Each segment routes two of the sound files into one of the twelve sections. The destination will be determined by the test supervisor inputting a randomising code which is basically the list of 1 to 12 inclusive jumbled up. This means that each set can be sent to any position in the playback order. This allows me to meet the randomisation section of ITU BS1116.
The patch cords coming out of the “open” objects are fed into the final two inputs of the p 14 subpatch. The name has remained the same since I started so the 14 has no significance! The 1 to 12 buttons are routed to the first twelve inputs of the p 14 patch and then the next twelve.
This layout results in that the each number destination button will be routed to both of these gate objects. There is one gate object per “open” object mentioned earlier. You can see these pop in on inputs 25 and 26. They are routed to the right hand input of the gate object. The gate works in the following way: The signal at the right input will be routed to the output corresponding to the signal coming into the left input. What this means that is if the left input is receiving an 8, then the signal at the right input will be sent to output number 8. This process is doubled up so that the contents of each set (pictured below) remain together and get sent to the same section.
The outputs of the p 14 object go straight into the p send object. This is another subpatch called “send”.
Here you can see the 24 inputs from the previous section. 1 to 12 correspond to the first gate object which controls one of the “open” signals and 13 to 24 control the other two. See how 1 to 12 go to the send “a” and 13 – 14 goes to the send “b”? Those “send” objects are a way to send signals around your patch without needing patch cords. This is very handy when you have a physically large patch. Send 1a and send 1b belong to the two soundfile players of the firsts section. Send 2a and 2b for the second section and so on.
Without jumping too far ahead, you can see the receive 1a and 1b boes, these correspond to the send objects of the same name. All this means that each set of recordings can be sent anywhere in the patch and remain together.
When answers are submitted, I can then use the Excel spreadsheet talked about in the third blog post to unscramble the results so I can process them in an easier way.
With the randomisation done, lets move onto the playback of the files.
The test section does not have a set of receive objects as the “open” signals are routed directly to it since the test section does not have to be routed anywhere except to itself. Lets take a minute to talk about these “open” signals
These are the open message boxes. When they are told to (via a master button) they will send out a message stating “open 2sf1.aif” etc. This signal is then routed to which ever section as described earlier.
The left input of the sfplay~ object, which is a sound file player, is listening for messages such as “open nameof.soundfile”. Once the Randonisatron is initialised and triggered, it sends 24 of these open messages to the appropriate 24 sfplay~ objects. Each of them recognise the open message and open that file from the hard disk.
Playback
With the sfplay~ having opend the soundfile, it is time to start playing. The Play button is routed through a 1 message box which is then routed into the sfplay# left input. Sfplay~ is also listening for the numbers 1 and 0 as that means play and stop. On this note, remember earlier I showed how I had to add plus 1 to the gate? This was done as the gate sending out 1 messages meant that the sfplay object got confused. The +1 meant that the confusion would not occur.
The sfplay~ object has the number 6 after it. This means that the sfplay object is setup to play audio channels with 6 outputs which is what is required for 5.1. The 1 message I mentioned earlier is routed into a loop message. This is yet another message that sfplay~ is designed to listen for. Once received, it will play on a loop until stopped. The stop button has its own 0 message to stop playback too. The final output (right hand side) of the sfplay object is specifically to send a message when the playback stops. The patch cord coming out of this is redundant come to think of it, but it does not cause any glitches so let that be an oversight not to worry about.
As a side point, note that the Play button is routed to the dac~ via a toggle switch, this switches on the output when you press play.
With your sfplay ojects playing the correct soundfiles, how about switching between them? The selector object is similar to a gate but it works in reverse. Where the gate routes one input to one of a number of outputs, the selector routes one of many inputs into one output. With six selectors all being fed by the outputs of the sfplay objects we now have a means of switching between the output of one of the sfplays. Both channel 1s are being routed into one selector, both channel 2s into another and so on.
The recording 1 and 2 buttons on the top right send 1 and 2 messages into each of the selector inputs which means that when there is a 1, they will switch to all of the first sfplay outputs and when there is a 2, the second set. Pressing either of the Recording 1 or 2 buttons sends a signal into a special message box (the grey boxes are message boxes). 0, 1 80 is a special message which only the line object below will recognise. When the line object gets this message it will go to 0 and up to 1 in 80 miliseconds. In Max, when you multiply a signal by 0 the signal disappears. Just like a number in maths class. When you multiply it by one, you get the original number. By multiplying the output of the line object by the audio signals coming out of the selectors, the audio will mute for 80 milliseconds while the switchover takes place. To do this you need the *~ object. The * is multiply and the ~ stands for a MSP object, which is an audio signal. Any object with a ~ means it is designed to deal with audio signals. (audio for my purposes, not strictly as general as I said I must say) To make absolutely sure there are no clicks or pops when switching over, you could delay the selector switching by 10 miliseconds so the switch happens when everything is muted but I have not had any problems here with this setup.
Then the output of the multiply object gets put into the audio card and to the speakers (finally I hear you scream).
This final part of the playback section shows the participants what they listen to. First off, by clicking play you send a signal the Recording 1 button so all playback will default to Recording 1. The output of each button gets send to if statements. It reads like this. If the input number 1 ($i1) is equal to 0 then set the output as 0 or if the input equals anything else, throw a 6 out. There is a severe quirk going on here which you need to know about. The recording 1 and 2 buttons are just that, buttons. They send out a quick stab of 1 followed by a 0. A toggle switch would stay on or off until you said otherwise but that would not work for this patch. What the if statement is saying is that once it receives the 0 from the recording 1 button, then it will send a 0. If it gets anything else from it (like the initial 1 you get from pressing it) it will send out a 6.
Similarly, for the Recording 2 if statement, once it receives its initial 1 (when clicked by a mouse) then send a 1 but for everything else send out a 6. Why a 6? Well the if statements lead into ANOTHER BUTTON! Madness! This button will only understand a 1 or a 0. If it gets a 1 it says you are listening to recording 2, if it gets a 0 it says you are listening to recording 1. Okay, that is a bit confusing I know. Note the suddent change in writing style as I begin to bore myself! The button will never respond to a 6 and when it is hooked up in this way, where the left input is the trigger, rather than your mouse button, it will only change until it is told otherwise.
Getting the Listeners Reactions.
This is the final bit in the puzzle!
This is the part of the patch which logs what peoples answers are. Instead of normal buttons from before, we have a lot of toggle buttons. Like a light switch, they will do something until told otherwise rather than like a normal button that sends a quick sharp message for as long as the mouse has been pressed on it.
There are five questions, and their patching is identical. The output of each toggle button (or switch) is 1 or 0. 1 when on and 0 when off. Here, both buttons are off so there are two 0s.
Click one of them on, and you get a 1. What is happening here is that the output of the two buttons is being added and sent through an if statement which says: If input number 1 ($i1) is equal to the number 2 then set the output to 10 or if input 1 is not equal to number 2, set the output as whatever is coming into the second input $i2.
So, here the 1st input is not equal to 2 so it is using what is coming into input two, which just so happens to be the same thing. Having the word “set” on front of a message makes anything after it become the message in a grey message box. Wordy I know, but look at the difference between the above and the below.
Some mad person has selected both the available options. Now, the input number 1 DOES equal 2, so that sends the message “set 10” out of the output. The grey message box recognises this and turns itself to 10.
Here are all five of these setups working together. All the answers are good and all the outputs are routed to this “expr” function, which is a mathematics object. What that saids is add input 1, 2, 3, 4 and 5 together. Have you noticed the Max way of describing inputs? Dollar sign + I + number.
With all answers good this means each question is sending a 1 which all together makes for 5 and now the participant is given the green light at the bottom. Remember the way that if there was a wrong set of answers given, there would be a 10 sent out? Well look at the final set of if statements at the top. They are looking for a 5, and that is it. One wants to send a message when 5 is not there and the other wants to send a message when 5 is there.
By giving one wrong answer, 10 is being added to the “expr” object so that means that the if statement looking to send a message when there is no 5 wins and the participant gets the red light! Btw. The whole calculation is set in motion by the confirm button which sends a signal too all the mathematical parts to do their thing.
Thank you again!
This was a huge post, I appreciate that but I wanted to make sure that there was a clear write up of all the elements in one go for anyone who was interested. It has been tremendous fun making the patch and quite rewarding too. I hope someone can take something away from this for their own project. There are many elements that could be done better I am sure, but part of the fun is realising that and devising an more efficient way of doing things!
See ya!
