PaulStretch3 preview(12) release

[Xenakios]

I can't wait to have this in AU format for use it in Logic

Considering just the standalone version seems to already have all these problems for various people, I can't imagine a plugin version going much better...(A plugin version might suck anyway because the processing needs to have latency, at least the size of the FFT. It's still an interesting thing to think about... )

[ghettosynth]

I can't wait to have this in AU format for use it in Logic

Considering just the standalone version seems to already have all these problems for various people, I can't imagine a plugin version going much better...(A plugin version might suck anyway because the processing needs to have latency, at least the size of the FFT. It's still an interesting thing to think about... )

I can't speak for anyone else, but, for me, the latency wouldn't be an issue because it's the workflow for the use cases for this thing that would be great.

I use plugins that have high latency for composition because nothing else does what they do, e.g., GRM Evolution. I've come to expect that it's not the kind of tool that you want to use in "real time" from a performance point of view, but it's still very convenient to be able to use it in between other spectral processing plugins while working.

At any rate, I am grateful for the standalone version, but like many, I would love an awkward high latency plugin. That said, I think that some (many?) people would still complain about the latency even after being told up front that it is a necessary evil for the plugin.

[Xenakios]

I can't speak for anyone else, but, for me, the latency wouldn't be an issue because it's the workflow for the use cases for this thing that would be great.

I use plugins that have high latency for composition because nothing else does what they do, e.g., GRM Evolution

I know/own the GRM plugins and they work fine for my purposes too. I would actually prefer a plugin version of this PaulStretch thing too, but looks like it was a good decision to do this standalone version first to find out some of potential issues...A plugin version right away would have been a complete crash fest, no doubt.

[ghettosynth]

I can't speak for anyone else, but, for me, the latency wouldn't be an issue because it's the workflow for the use cases for this thing that would be great.

I use plugins that have high latency for composition because nothing else does what they do, e.g., GRM Evolution

I know/own the GRM plugins and they work fine for my purposes too. I would actually prefer a plugin version of this PaulStretch thing too, but looks like it was a good decision to do this standalone version first to find out some of potential issues...A plugin version right away would have been a complete crash fest, no doubt.

Without a doubt the standalone version was the way to go first. In fact I would argue that spending the time to get it stable and as feature rich as possible before turning it into a plugin would be prudent. I'm just lending support for the idea of a plugin, but, it sounds as if you use some of the same tools and consequently are aware of the use cases. Moreover, I'm encouraging you to be sure to have on your asbestos suit before releasing a plugin because even if you tell some people that it really can't work any other way, they will still whine and complain.

Looking forward to trying out beta 6.

[dangayle]

I also vote yes on a plugin version. Not so much to play live, but to stay in the flow when doing sound design.

Example:
- Create a cool synth patch -> freeze & flatten track
- Reverse track, add reverb -> freeze & flatten track
- Apply Paulstretch -> freeze & flatten track

It makes this workflow much easier this way.

[Xenakios]

Bump for beta 6. Download links in the original post.

The Menu button now shows under Advanced options the prebuffering thread priority. Changing that may or may not fix issues when starting playback.

Before anyone mentions it, I know it'd be nice to be able to drag and drop the spectral processing stages instead of using the buttons...But the default JUCE listbox implementation sucks for drag and dropping the items inside it. I will need to implement some custom solution for that later.

[shroom81]

Still crashes immediately here Hope you'll find that bug since this is looking real good.

[CinningBao]

This is turning into quite a neat little package

Love the new order feature. I assume it goes from top down? It's the obvious assumption.
Filename in the main window, nice!

I would beg of you one small thing; can we not have the larger FFT sizes? We've still got a maximum of 2.972 seconds, a 60 second window would be a dream, plus it would sound like a literal dream with windows that big!

Stunning work dude.

[Xenakios]

Still crashes immediately here Hope you'll find that bug since this is looking real good.

Sorry, I think I have to call it quits on trying to solve this issue... (Since I don't have Windows 10, I can't easily debug issues specific to that.)

[Xenakios]

a 60 second window would be a dream

I highly doubt that will work correctly (it would use an insane amount of CPU probably) but I can test it on my system...

[CinningBao]

a 60 second window would be a dream

I highly doubt that will work correctly (it would use an insane amount of CPU probably) but I can test it on my system...

Cool, thanks

I didn't experience CPU under extreme load in the beta4 which had this configuration when running with 30-60 second windows, but I'm not sure if the changes you've made since beta4 would affect this.

[ThomasHelzle]

Instant crash for me as well with beta 6, both when I load a wav file and hit play without changing anything else as well as when I just open the software and close it again - in the latter case I get a crash after hitting the windows [X] close button.

Beta 3 and 4 worked fine.

Windows 8.1 x64, Asio/Windows Audio Focusrite Scarlett 18i20, 64 GB RAM, 2 GeForce Cards...

Cheers,

Tom

[Xenakios]

I didn't experience CPU under extreme load in the beta4 which had this configuration when running with 30-60 second windows, but I'm not sure if the changes you've made since beta4 would affect this.

I wonder if that version was just showing the FFT size wrong... I probably have to go back in the revision history and see. (Just tried changing the FFT size maximum limit with the recent version. It does manage to play back but not smoothly. Probably have to make it increase the used buffer size for these larger FFT sizes.)

[Xenakios]

I have one more thing to try about the crashes : reverting back to using KissFFT, it might be I have built the FFTW library wrong so that it doesn't always work on other systems. I will post beta 7 builds with KissFFT later today. The downside of KissFFT is that it will perform more slowly, especially with larger FFT sizes...

edit : Here's the version with KissFFT for Windows 64 bit

https://goo.gl/E6Q71h

[Xenakios]

Still crashes immediately here Hope you'll find that bug since this is looking real good.

Can you try this build? https://goo.gl/E6Q71h