enzienaudio
Schrödinger's [snapshot~]
I switched out [phasor~] in some of my Heavy patches in favor of [hv_vline~] but then realized that doing so prevents realtime transposition of a sample in progress.
The reason I wanted to try [hv_vline~] is because I need a way to stop the phasor once it's reached 0. In PD I would normally use [bang~]>[snapshot~]>[>.99]>[0(>[phasor~], but doing this in Heavy using [metro 1] (which also works well enough in PD) instead of [bang~] leads to inconsistent results: sometimes the [phasor~] stops as desired, sometimes it doesn't and repeats the sample instead. What would you suggest for using a [phasor~] to read an array and then stopping it?
When you have finished reading through the array, you can set the frequency of the phasor frequency to zero, and perhaps reset the phase to zero? Is that what you're looking for? Are you basically looking to implement a [tabplay~] object?
Yes, that's right, @mhroth Except, since you can change the speed of the phasor~ while it's reading, you can use it to transpose the sample mid-playback.
I'm not sure why the aforementioned [snapshot~] method doesn't work well in Unity. Presumably the data resolution is slower...?
Here's a picture of the construct. When the [snapshot~] is over a certain value (here I've tried lowering the [>] down to .95), it should send [0( through all of the multipliers and into the phasor and the array should stop playing until a bang sends a [1( into these same values. But it's not working in Unity...
I'll try sending the [0( directly into the [phasor~] instead of through the multipliers, since that should work too, but I doubt that's the problem...
OK, I've spent all day trying to figure this out, experimenting with different fixes and creating simpler builds...
As you can see from the picture in my above post, the sample player is an abstraction. I normally have two of them in _main. They read from the same arrays, but their other values are differentiated with $-arguments. For some reason, removing one of them allows the plugin to work properly, i.e. print out the phasor values and read the array up until the point determined by the [>] before shutting off.
Putting the second one back in leads me to a similar situation as before with the following odd behavior in Unity:
- Putting a [print] at the outlet of the [snapshot~] prints only zeros, although...
- ...the sample still plays for some reason. But...
- ...it doesn't stop where it should, but rather plays til the end and repeats.
Needless to say, this is really weird. I made a simple version of the player earlier, so I'll try making that into an abstraction and doubling it and see if I have the same problem...
The problem is not the existence of two instances of the abstraction.
I've reduced the patch to only one player abstraction which reads two arrays, one of the arrays being read with the aforementioned [>] method. I've also simplified the patch by removing some currently unused things... The only difference between the two versions of the patch is that one (version 87) has a [print] coming out of the [snapshot~] and the other (version 88) doesn't. If I test a single instance of both versions in Unity, the patch with a [print] (87)works correctly - it prints out the array values and the sound stops after it gets close to the end of the array. The version without a [print] (88), however, does not stop and continues to loop the array, as if the [metro 50]>[snapshot~] were not there.
The version with a [print] is not viable, however, because I need several instances in my actual game scene, and even with the slow rate of [metro 50], much slowdown is induced by all of the instances printing together.
Can someone explain this? Or offer an alternative solution? As far as I can tell, it seems to be some kind of limitation of [snapshot~] within Heavy/Unity.
https://enzienaudio.com/h/sep/sustainplayertest/87/
https://enzienaudio.com/h/sep/sustainplayertest/88/
Picture of simplified patch below. Everything of relevance for this problem is inside the orange box :
