Receiving sent values from instanced versions of the same Pd patch.

Hi! I’m loving this project as it’s exactly what my project requires to get the audio-end working flexibly!

I’m running into an issue where I need to receive a float value from the patch. After following the LibPd-2-Unity tutorial, I have the following code receiving a float value “volume” from the patch and influencing the scale of the object.

public void FloatReceive(string sender, float value)
	{
		if(sender == "volume")
		{
			scaleObject.localScale = new Vector3(0.1f+(value/1f), 0.1f+(value/1f), 0.1f+(value/1f));
		}
	}

However, I have two game objects, each with their own LibPdInstance running this single patch, and both are receiving the volume value from the first instance of the patch.

Is this an issue with the way my variables are setup? See this video for a short demo of the issue: https://www.youtube.com/watch?v=c_jD0dD6zRg

[sambilbow]

Redescription of desired effect

• 1. One Pd patch, and one script in charge of all the sound generation and parameterisation/visualisation respectively of a GameObject
• 2. Package this into an instanceable prefab.
• 3. Instance many of these prefabs
• 4. Send data to each prefab’s Pd patch separately based on hand gestures and other scene variables
• 5. Receive unique data from each prefab’s Pd patch (despite them all using the same patch)

I can achieve 2 and 3 with a bit of learning so this issue is mainly about 5.

---

Solution

I just stumbled across this solution, came back to this issue and found that its essentially what you pointed me in the direction of! It involves sending the name of the GameObject (which will eventually iterate as they spawn (e.g. object-0, object-1, object-2) over to PureData to act as a kind of psudeo $0 that Unity can access (because it put it there).

This looks quite similar to the quick fix I did above, but whereas that fix still required a unique script per GameObject, this fix uses the same script and Pure Data patch per GameObject.

In Pure Data Set up a receive mechanism that stores the GameObject’s name and accordingly sets the name of a send object inthe patch

In Unity/C#

1. Name the GameObject with indexes (i.e. sphere-id-0, sphere-id-1 etc…)
2. In the script for the GameObject that deals with the Pd patch, do the following (where pdPatch is a variable containing your LibPdInstance) i. Send the name of the GameObject over to the receive object you made above. pdPatch.SendSymbol("label",gameObject.name); ii. Bind to the name of the GameObject pdPatch.Bind(gameObject.name); iii. Set up a conditional BangRecieve() function so that the you can make stuff happen only if the bang comes from the patch who’s index is equal to your object’s name (if you dont do this, you will receive multiple bangs, although unique they will be copied for every public void BangReceive()):

  public void BangReceive(string name)
  {
      // If the name received by the LibPdInstance event equals the object name
      if (name == gameObject.name)
      {
          // Print that you received a bang
          Debug.Log("Received bang from: "+name);
          // One day soon, do some awesome audiovisualisation of the Pd patch in 3D!
      }
  }

---

Next steps

I will want to bind to more than just one outgoing message from PureData. I will try doing this by binding to indexed parameters that still use the GameObject’s name: pdPatch.Bind(gameObject.name+"volume") and set up multiple send objects as the above screenshot shows by using [list append] then [list trim] so that PureData sends out via an object named [sphere-id-1volume] for example.

Eventually I’ll tackle building the GameObject naming into a prefab instancer, but the way I see it, this is probably the best fix I can go with for the time being

---

Caveat

A downside is having to set up the new send system with a testing mechanism (since without Unity telling it what the send object is sending to, it doesnt go anywhere). You can see I did this by sending [sphere-id-0( to make sure that the mechanism works.

[sambilbow]

Thank you so much for your reply. I will have an investigate over the next couple weeks and report back here if thats okay? Could be useful for future repo users.