@abargum This...... https://forum.pdpatchrepo.info/topic/11994/adapting-external-loop-help-patch-or-possibly-else-library-objects-for-seamless-varispeed-rev-looping/9 ....... the "maybe.zip" does it, but there is a problem starting at the very beginning or end of the sample depending on whether it is playing backwards or forwards.
Not moving a control fader to the absolute end of its travel "solves" the problem but not to my satisfaction.
David.

@Johnny-Mauser Hmmm... I don't know, and I can't find any definitive info either. But if Pd is compiled for 64-bit and against 64-bit tcl/tk I don't see why floats would be restricted to 32-bit...... except to help Pd run faster...... so maybe they are?. As I understand it the latest OSX will not run anything 32-bit at all.
Maybe that 64-bit is "single precision" but at 64-bit depth has confused any discussion?
If @jancsika has a moment maybe he can explain where things stand.
David.

@Johnny-Mauser Yes, I had wondered about pmpd too. I tried scrubbing (bowing) "\pmpd\examples\51_string~.pd" with no success. It works well for plucks. But it should be possible to model pressure waves as fluid dynamics. Would it be fast enough though?
David.

@s.elliot.perez As far as I know the advantages of 64-bit is for float precision and greater ram access (not faster)..
I don't think 32-bit will be slower.

Quote....
"Unless you need to access more memory than 32b addressing will allow you, the benefits will be small, if any.
When running on 64b CPU, you get the same memory interface no matter if you are running 32b or 64b code (you are using the same cache and same BUS).
While x64 architecture has a few more registers which allows easier optimizations, this is often counteracted by the fact pointers are now larger and using any structures with pointers results in a higher memory traffic. I would estimate the increase in the overall memory usage for a 64b application compared to a 32b one to be around 15-30 %."

But the 64-bit versions will evolve.... with new objects.... and so 32-bit versions will become "unsupported" as has been the case for "extended".
David.

@s.elliot.perez It depends on your project. In windows I just run every variant of Pd uninstalled, in folders on my desktop, starting them with shortcuts to the pd.exe executable, with the startup flags included in the shortcut to control how they are run. Some variants share their path preferences in the registry and some don't (not my decision...... just depends on the version).
I only have extended installed, and it remains my first choice most of the time...... but of course vanilla is necessary now for helping on the forum.
It could be that Miller is following @katjav in his [sigmund~] build? "SNAC" is probably out of patent so hard to tell. [Helmholtz~] certainly has fewer control parameters, but is maybe easier to "tune".
[sigmund~] can be used directly with tables (no signal) as well which can be useful.
David.

@s.elliot.perez I use win7 64-bit...... so maybe not relevant..... but [Helmholtz~] will load in 32-bit vanilla but not Pd 0.49 64-bit.
As far as I am aware windows has not killed off 32-bit processing.... as has osx.
David.

@artelse It is not just Pd.... as you see in my post above the same applies to this forum...
It should read "the backslash becomes backslash backslash ........." and the second is dropped.
More reading to be done on this subject.
David.

@porres And I forgot that [limiter~] from the zexy library was a lightweight, easy to use compressor back in the days of extended. The compressor settings were buried in a sub-patch in the help file. It might not be updated for 64-bit though.
@solipp Thank you for the correction.
David.

@porres Explanation and patch from @katjav is now updated for Vanilla....... http://www.katjaas.nl/compander/compander.html
The main problem in the digital domain is knowing the power of the signal in advance so as to reduce it according to that power. It can be done but introduces a delay to the signal that will be disturbing in a live environment, or it is not done and a fast attack will get through the compressor.
That looks (no delay) to be the case with the cyclone abstraction.
It can be acceptable..... analogue compressors have an "attack" control that controls the delay before compression, but in the digital domain you normally have no choice.
She has solved that problem.
David.

@metaphysician This will I think do what you want just using [phasor~]....assuming that you do really want the pitch to change as playback speed varies?
It's a mod of the patch I posted above....... maybe.zip
Bi directional varispeed looping without clicks.
Start and end points can be set and changed..
The "speed" fader will loop forwards or backards, faster the more it is moved right or left, slower moving it towards the middle, until it stops at the centre..
Click the stop message [0( to stop.
Click the message box labelled "forwards" to go forwards at normal speed.
Click the message bot labelled " backwards" to go backwards at normal speed.

There is a small logic problem to solve where the absolute beginning or end of the sample is set.
If you think it is useful then I will fix that.
David.