Possible Issue with samphold~

[diemildefreude]

So, a new summary of the problem with integrating my Granular Synthesis (GS) module:

Github isn't letting me attach .zip files, but here are links to:

• a 'testable' version which you can open in PD and hear. http://s000.tinyupload.com/?file_id=95918745385600857197
• a heavy-compatible version which you can't hear because the sample must be loaded through Unity. http://s000.tinyupload.com/?file_id=06457352623791187310

These two versions should be identical except for the layout in gs.pd (gs2.pd in the testable version), which deals with the sample-loading.

The problem is that the heavy-compatible version doesn't produce sound. (note: ignore knifenew.wav and use knifenewnew.wav)

Through numerous tests I've been able to isolate the problem.

1) The sample array is loading properly. I know this because phasor-based reading of the entire sample works (i.e. If you move the 'mix' nob to the right in the testable version, or set up the heavy version to do the same). 2) The problem is in gs/pd 3streams/grain-stream $1 3) The problem is not with the phasorline~ (formerly vline~) or with [pd env] 4) The problem is with the output of the samphold~ objects. 5) Whether this is due to the objects themselves or the wrap * buffer length not incoming (for some reason, is still unclear...

http://i65.tinypic.com/5xit0k.png

[diemildefreude]

After posting this, I put an exposed send object under the wrap * buffer length, but I don't know how to access it to observe it while Playing in Unity.

http://i68.tinypic.com/24z9eud.png

I've tried adding the OnFloatMessage code (to the Sampler script) as demonstrated here : https://enzienaudio.com/docs/index.html#06.unity#exposing-and-sending-events

but nothing is printed in the console. What should I do?

[diplojocus]

hey @diemildefreude thanks for the info, regarding the exposed output parameter, instead you can always use a [print] which will display in the Unity console.

I'll take a look at your patch

[diplojocus]

hey @diemildefreude do you have a simple unity project that reproduces this issue, will make it easier to debug.

[diemildefreude]

Here you are, @diplojocus

http://s000.tinyupload.com/?file_id=72001966215525291360

And thanks for the [print] tip, I'll test it out!

[diemildefreude]

I'm not sure what the standard protocol is for sending people projects, but I you just need to click on Scenes and open the only file there.

[diemildefreude]

I added the print objects in [grain-stream] at the [r $1-buf] and the [int] below it. The initial values for the buffer size are correct. The output of [int] stays longer at 0 than in the testable PD version, but it does get going eventually... no sound though.

[diemildefreude]

Hey, any news on this? Let me know if the problem is still not clear.

[diplojocus]

hi @diemildefreude with patch provided, honestly it's hard to even just understand what the issue is, and where it might arise from, let alone even thinking of a solution to fix it.

If you suspect a particular area of your patch to be an issue, then what's helpful on my side is that you can distill it down to just those parts. The simpler the patch to describe the issue the better!

Another helpful thing to do is to describe clearly what you expected to happen and what the actual output was. As an example:

---

Description: The print object outputs all numbers +1 Expected output: print n Actual output: print n+1

Patch:

[loadbang]
|
[f 2]
|
[print ]

---

What's also helpful in this process is that it could turn out to not be a bug in the system but maybe an issue in how we explain how to achieve particular tasks.

Your title explains that it's an issue with samphold~, but from your description it sounds more like a problem when loading samples in Unity. Providing a simple Unity project that demonstrates this would be extremely helpful. Also it doesn't have to be your full project but could be a separate one containing only the pertinent information.

Hope that helps you help us better! 😄

[diemildefreude]

@diplojocus Hey Joe, did you try the unity package I linked to above? Here it is again: http://s000.tinyupload.com/?file_id=72001966215525291360

If you just import that into Unity and open the scene in the scene folder, you'll have the project. As I mentioned above, I don't think it's a problem loading samples, because normal playback of the array works fine. I'll set up a snapshot~ and print after samphold~ to see what values it's supposed output.

[diemildefreude]

Hey @diplojocus You were right that I should have been more exact with regard to [samphold~]. Sorry about that. I just uploaded another version with the snapshots installed after the samphold. To give you an exact description of the expectations, please look at the following image:

In the upper right is the output of the two [samphold~] as they function in a PD-functional patch. Below that is the Heavy version in PD. Note that it is probably normal for samphold2 to return normal because the values before it are multiplied by nothing until the array size is passed in via Unity. In the background, you can see the Unity output itself - all 0s.

I've just had another idea for what the bug is. I remember having trouble with lists in Heavy and e-mailing you about it. Maybe the problem lies in the way the parameters are packed and unpacked:

This works fine in PD, but maybe it poses a problem for Heavy, particularly the part in the upper middle where a trigger is used to pass out both the first float and the whole list.

Finally, I appreciate your patience after all this time and I really am trying to comply with your request for more precision. I hope these screenshots are helpful. It is somewhat difficult to distill some of these more complex things, because I didn't originally make them myself. If you need any other information, please let me know. If we can clear this and some other issues up, I'm really excited about what can be done with Heavy.

[diplojocus]

Can you try putting a [sig~] object just before you connect it to the left inlet of [samphold~]

i.e.

[$1 (
|
[sig~ ]
|
[samphold~]

[diemildefreude]

Very interesting. When trying your fix and pressing play in Unity, the printed values were of the kind expected, but no sound came so I stared at the screen in frustration for a moment, but, after about 25 seconds, sound began to fade in. However, it was very choppy compared to the smooth sounds in PD and looking at the stats revealed DSP clocking in at over 200%, which also explains the slow start.

So your fix worked! But either something else is wrong with the transition to Heavy... ( by the way, is that thing I mentioned about the lists alright as is? ) or Unity/Heavy simply can't handle Granular Synthesis. If so, it's quite surprising, since, when I run the PD-version of the same patch in PD, the CPU in the Load Meter doesn't go past 14.

If you think it's really a software limitation, do you have any general guidelines for the upper limit of what's possible in Unity/Heavy? Or is it a matter of starting simple, building up, and seeing how the software handles it?

[diemildefreude]

Ah, I had the same problem with the other patch - it's because of sending out too many print messages per second. Sorry!

[diplojocus]

Yeah in general printing anything to the console is very costly, especially if it's coming from the audio thread! There should be no problem with doing granular synthesis, it's a common approach we do.

[diemildefreude]

Yes, it works now. Thank you!