I see from a search that the third stretch-goal on the original Kickstarter campaign included a time-stretch module. Now I see from a search here comments which appear to indicate that there is no time-stretch feature (i.e., slowing sample-playback while holding pitch constant) in the current Percussa SSP. Is this correct?
I was not around for the kickstarter,
but i believe for the 3rd stretch goal, there was a list of ‘proposed’ modules which backers voted on…
then these were selected…
the results were:
so this was
- Looper (not yet available)
so only the looper is outstanding…
Im not sure what else was on the list of possibles, Im assuming from your post a time stretching module - if so, then this was not selected by backers.
Kent, summarized this really well in this thread
I think what technobear posted is acceptible, I am sure that Bert and Celine have their hands full. I am not a developer, but I have mucho respect for people like technobear and what they have brought to the module, and look forward to future contributions when possible. I also hope that other developers will jump on board and develop even more VSTs for the module. I’d love to see more MI VSTs introduced, but I also know that has to be time consuming and labor intensive. I think most of the basic building blocks are there (especially with SWAT and the OG modules) there are very few core modular functions that are not supported currently. The USB I/O alone made me sell my ES9 to help fund the SSP purchase and all in all, I am thankful for what we have, and consider anything else icing on the cake
P.S. I wish I knew what I was doing, because I have some ideas and things I would love to implement in the SSP, but I am totally clueless when it comes to programing.
Just checking in for 2023. As of August 2023, has a time-stretch module since been reconsidered? Has such a module been reassessed for the SSP’s roadmap? I see from the June 2022 livestream that the code was rewritten to take advantage of a standalone GPU, presumably allowing the CPU to handle more sophisticated tasks (e.g., time-stretching). Or is a time-stretch module definitively not in the cards for 2023 (or for that matter, 2024)?
as far as I know, no commitment or roadmap has been published.
I think the primary purpose for freeing cpu, was to make more cpu available for user patches, so users could create more complex patches (ie. using more modules) - though of course, it also means you could use a few more ‘expensive dsp’ modules in a patch.
moving to the GPU would only free up processing on the (single) core use for the UI… so might allow for more complex ui’s rather than more audio processing. the only way more ‘dsp’ resources would be free, is if the ‘ui core’ was underutilised to the point we could start safely doing dsp on it.
BUT that was just the GPU side… of things, the update also optimised a lot of other processing that was going on - and these optimisation would likely benefit all cores.
as for time stretching , I assume you mean time independent pitch shifting. if so, have you tried using GRA for this?
many (most?) of this kind of pitch shifters are implemented using granular.
(really they are a granular with a simplified ui/controls)
basically use small grains and use a playback rate related to the pitch shift.
depending on the material you are working with you can fine tune the parameters.
(if you look at Ableton’s complex time warp, you’ll see which granular params are used)
Thank you for your reply, Bear! By “time-stretching,” I mean slowing/speeding-up playback while holding pitch constant. Does GRA do this? Also, is the looper capable of reverse-playback and/or ping-pong playback (i.e., playing the sample forwards, then backwards, continually).
I don’t own an SSP so haven’t tried GRA, but I use the time-stretch features of my ER-301, QU-Bit Nebulae, and Make Noise Phonogene, all of which produce a fair amount of artifacting at slower playback-speeds. If such a module were available for the SSP, I could benefit from a bit less artifacting (especially when slowing down to 0.1x-speed) due to its increased DSP-horsepower. Also, since the SSP provides a much more luxurious UI, I would be elated to learn if the SSP’s GRA-module can perform this function.
I’m not making “beats,” nor do I need any “slicing” capabilities. My specific area of interest is that I like to slow back playback of both human and synthetic-speech for weird drone-making and sound-effects purposes.
if so, we’d like to see your patch (notes)
looper, so my LOOP module can do reverse playback,
this rate is under cv control you could I guess ping pong , just use a square wave -1 / 1.
but the issue is, you’d have to have the lfo running a speed relative to the length of the loop, as I dont have any ‘sync’ there.
gra , see below (for my quick experiment notes).
yeah, artefacts are going to happen when you slow things down a lot, thats partly the nature of the beast -basically your using a very small snippet of ‘sound’, so the idea is when played at a certain rate and windowing it (smear) it sounds ok… (see Curtis Roads / Microsound)
there are other approaches too, like PVOC, but if you have nebulae you have no doubt tried that too
things like paulstretch which do long stretching well, I suspect (as Ive not checked) do analysis to get around this, but its not real time.
note: I do not claim to be an expert in this area, nor do I use it very much.
rather, I just enjoy granular engines and seeing what I can get out of them…
(k, perhaps a bit more, as Ive done some dsp coding in this area, and researched bits of it, from Roads/Microsound)
@wavejockey … in my modular rack, I have Nebulae so tend to fall to that,
though I have messed about with this in modular environments using technique discussed…
so not use GRA for this, and in the past, I tended to find GRA was a bit noisy when using many grains.
that said, I did give it a go… to see if the theory works, and what it comes out like
and indeed it works… (kind of…) pretty much the patch is as you would expect.
so the general principle we will use is using 2 LFO,
one oscillator to drive the grains (and so pitch) (kind of optional)
the other oscillator to playback the sample at the rate we would like.
note: I used 2x OMOD, but you could use LFOs
GRA → OUT
LFO1 Sq-> GRA:TRIG
LFO2 Ramp → GRA:START
GRA: GrCourse = 0 (essentially disable grain generation)
GRA: GrDur = 1
GRA: NGrains = 50 (probably 200 default is fine too)
GRA: Start = 0.5
GRA: Length = 0
GRA:Tune/Crse = 0 (adjust to taste0
GRA:Txt : adjust to taste
LFO1 : Rate
this sets the pitch of the tone you will hear
LFO2 : Rate
this sets how fast the playback of the ‘sample’ is.
note: its relative to length of sample… so a 1 sec sample, at ‘normal rate’, you set this to 1hz, if it was a 10 second sample… it be 10hz.
thats it, its pretty straightforward… I loaded up a few samples including piano and drum loops and listened to what it sounds like (more on that later)
LFO1 is ‘optional’, you could use GrCoarse, but I found I got better results using an external oscillator… not sure why, and I didn’t dig into it.
as. said this is all basic stuff really…
Ive used variations on this for many types of granular playback, as I tend to like to drive the grain generation (lfo1) and position (start) manually (via LFO2) for all sorts of granular effects… (its fun as a live effect, for things like delays etc)
so how does it sound?
well as I mentioned previously, you get lots of artefacts …
so as an fx its a alot of fun, not only are you time independent pitch shifting, but you can get many different timbral changes by changing the windowing (texture in GRA), also using Tune/Course has a kind of filtering/comb/ring mod effect.
as I mentioned at the top of this post, this is kind of what I expect from using a granular in this way, and indeed its highly dependent on the source material… so its a fun thing to experiment with… but its not ‘fine tuned’ to give a perfect pitch shift.
I will say, as again already mentioned, I find GRA specifically a bit noiser than Id like for this usage… and Id need to dig deeper to work out why…
e.g. perhaps the duration of 1 is too long (Im not sure whats its ‘measured in’), perhaps using as scaled cv to give lower values might work better? or is it some assumptions in the code? or something to do with the windowing?
as I mentioned in the first post, if you were creating a pitch shift module, you would fine tune many of the granular parameters to make it more suited to the application.
we are using a bit of a sledgehammer to crack a nut here, with the precision that brings