MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

nw2s::dsp time stretching demos
MUFF WIGGLER Forum Index -> nw2s  
Author nw2s::dsp time stretching demos
scottwilson
Lots of demos and explanation about the inner workings of the nw2s::dsp time stretch algorithm...

enjoy:

http://nw2s.net/dsp-stretch/

I'm wondering if I should consider making a pedal out of it with a simplified interface. Any one know where to find out if there's interest for that kind of stuff...

s
myecholalia
scottwilson wrote:
Lots of demos and explanation about the inner workings of the nw2s::dsp time stretch algorithm...

enjoy:

http://nw2s.net/dsp-stretch/

I'm wondering if I should consider making a pedal out of it with a simplified interface. Any one know where to find out if there's interest for that kind of stuff...

s


scott, this is fantastic work and just made the dsp a must buy for me if i can swing the cash once it's out.
i can absolutely see that this thing will be interesting for guitarists as well. in fact, there is a friend of mine here in singapore who does quite a bit of ambient and soundscape work with just a guitar and a pedal board. i'm sure he'd be interested in something like this.
Riggar
Sounds great.

Have been using Paul's stretch software for a while now - inputting various wavs (PC) I've created and keeping a whole directory full of 'drones' as starting points for future sound projects. Good fun.

Be very useful/interesting/powerful to do this in real time with modulation possibilities ...

With this unit - what's the mechanism for changing algorithms?
dadek
So amazing! How much of that is running on the b, and how much would require a b2 or expanded b? applause
scottwilson
Oh I don't think any of this could run on the 'b or the 'b2. The b is an 80Mhz integer only controller. The b2 is better, of course with 180Mhz, floating point, and a few DSP specific instructions, but the 'dsp is totally different...

It's running a 450Mhz SHARC chip with DDR2 RAM which includes hardware accelerated FFT and IIR routines as well as a bunch of other crazy optimizations for things that typically happen in DSP chips like parallel for() loops, two independent memory lanes, circular buffer registers, etc.

The downside is that it doesn't really do much else, so it needs a helper MCU... It will have something like an STM32F407 or smaller to handle the display, CV inputs, USB input, and will actually "boot" the SHARC from binary images on a microSD card.

Which leads me to the previous question... "what's the mechanism for changing algorithms?"

The SHARC's memory structure requires a fair amount of compile-time optimization. When you do something that pushes the limits of it's on-chip memory and computational units, it's almost impossible to do anything else. So let's assume that by "algorithm" we're talking some chunk of that size... The IR Reverb and the Stretch algorithms are examples of those. Each exists within it's own *.dxe file.

On the other hand, if you think about smaller "algorithms" like those that make up your typical multi-effects processor like distortion, chorus, delays, basic reverb, etc, then you can fit a bunch of those into one *.dxe file that can turn the 'dsp into something like a TC Fireworx or similar multi-effects.

I should be able to work out some code samples and include a couple of utilities for a cryptographic processor-ID-specific licensing mechanism that would allow developers to sell what would amount to plugins for the 'dsp. I intend everything I write to be open-source, but it'd be great if I could get some other developers on board too. Since the development tools are pretty expensive, they would need a way to offset those development costs.

Hope that answers some questions... I seem to keep making way too much work for myself!

s
MUFF WIGGLER Forum Index -> nw2s  
Page 1 of 1
Powered by phpBB © phpBB Group