Diy sampler

[matoz]

Hi all, go and see here  http://www.narrat1ve.com/

[nebula]

Wow, this guy has put a lot of work into this.  Looks like it could be a lot of fun when it's done.  The web page already is.

[lukas412]

Been following this, I hope to combine it with a simple sequencer and seppoman's ssm filter. Looks like a lot of fun.

Luke

[Max Romantschuk]

I'd love to combine a midibox and something like this to build a lofi drum machine. :)

Should perhaps finish my current project first, though...

[lemonhorse]

great project!

(i'm dreaming for years of an 8bit midibox sampler.  ;) )

[moogah]

Very interesting!  And that guy is (somewhat) local to me as well.  I'll have to look into this!  After building my 9090 I realized how "simple" it would be to create a basic lo-fi sampler using R2R ladders.  I hadn't yet thought up a lightweight way to load and store samples yet tho, so the best designs we could do would be like the early 80's sampler based drum machines where the sounds are permanent, but you can modify the playback parameters and add filtering. 

With the new core module in the works I have to wonder if we've opened up some potential tho.. I think I read that TK wants to include SD memory support, which will provide us with a way to store sample data... but many questions follow:

- what kind of RAM chips are available and affordable?

- would it be best to use dedicated DSP chips like the dsPIC to handle the sample processing and I/O (many of these are inexpensive and have onboard ADC and DACS which make them quite attractive.. but nearly all are SMT only).  There would likely be some expertise needed to write up all the DSP routines we'd need.

In any case this person seems to have come up with a nice simple design which is probably quite capable, I'll be watching this closely!

[moogah]

I dug around a bit and I've made a nice little discovery!  It appears that microchip is selling a "turnkey" dsPIC development board for only 60$  It has onboard programming/debugging, 24bit audio I/O with mic and line level amplification (!) and 4 megs of ram all connected to MPLAB via USB :)  I don't think I can resist this ;)

[TK.]

Sounds nice.

For the case that you would like to do some experiments with STM32 later: here is the i2s_synth example

Best Regards, Thorsten.

[moogah]

Oh!  Very exciting!  I can see that I'll need one of these new cores now too :)  Does the thought of connecting the STM directly to a "memory unit" and doing all the processing on the core itself raise any red flags TK?  I gravitate towards the dsPIC's only because I assume there may be too much overhead in processing sample data from memory to the I/O to handle interface code at the same time... but that is just a guess!

The next hurdle as I see it would be what kind of memory, which I know very little about... I'd like to be able to use standard PC memory sticks because it seems like a simple solution (everybody else does it...) but I've got no idea if doing that even makes sense (is SD fast enough to use as RAM?)... can you offer any tips on what would be involved in connecting a memory controller to the STM?  I'll be googling in the meantime :)

At a high level I would think that synth code is a great starting point, but instead of mathematically generating the audio data to send to the I2S port we would need to have another callback function which will let the application know that new sample data has been loaded from memory.  Ideally this process would allow us true random access of the RAM @44.1Khz (shouldn't be a problem?) for each new sample at the output and the STM will be responsible for knowing what samples are in memory, where they start and end, which samples are currently cued for playback and where their current playback position is...  and if all that works then I could work on adding pitch and amplitude envelopes and LFOs.  If all that worked like it should it would be nice to find that the memory bandwidth allowed us to retrieve more than one sample worth of data per refresh cycle so that layered sounds can be created.. and of course we'd then want to be creating dynamic voices and patches instead of simple static playback configurations... and if that's not enough feature creep for a single post consider that with all these SSM filter chips running around I would bet that more than a few people would like to have dedicated outputs for each "voice"  :D

Have I overshot what the STM core is capable of doing yet?

Edit: I just discovered the programmers lounge, I'm sure many questions are already answered in there somewhere.

[TK.]

I can see that I'll need one of these new cores now too

If you want to join the second prototype order: there are still three boards left: http://www.midibox.org/forum/index.php/topic,12658.msg106948.html#msg106948

Does the thought of connecting the STM directly to a "memory unit" and doing all the processing on the core itself raise any red flags TK? I gravitate towards the dsPIC's only because I assume there may be too much overhead in processing sample data from memory to the I/O to handle interface code at the same time... but that is just a guess!

I cannot really say, which solution is better, as I don't know the capabilities of dsPIC.

STM32 has 64k internal RAM, which can be used for buffering between the DMA based I2S output routine (MIOS32_I2S is running in background and doesn't load the CPU), and the SD card, which stores the samples.

MIOS32_SDCARD is DMA based as well - typical transfer rate is 8 MBit/s

Sufficient?

The CPU is clocked at 72 MHz, and can do a lot of calculations while data is transfered from SD Card into RAM, and from RAM to I2S in background.

However, an ARM Cortex M3 is not a DSP. But it has a floating point unit... and it can be used for so many other purposes :)

At a high level I would think that synth code is a great starting point, but instead of mathematically generating the audio data to send to the I2S port we would need to have another callback function which will let the application know that new sample data has been loaded from memory.  Ideally this process would allow us true random access of the RAM @44.1Khz (shouldn't be a problem?)

The DMA access doesn't support true random access. Data has to be moved into the sample buffer, so that it can be streamed to the I2S chip in background. So, your application still has to prepare the stream before the DMA takes it over.

This method has the advantage, that the CPU doesn't need to service the I2S chip in realtime (at a given sample rate), but that it can do many other tasks in parallel.

Have I overshot what the STM core is capable of doing yet?

I think: yes no (/edit: fixed inversion issue ;))

The reason why the example doesn't cover your feature list is not, that the STM32 isn't capable of doing this.

It's mainly because I wanted to keep it simple to give other people (who are interested in programming a sampler or wavetable synth) a starting point.

Best Regards, Thorsten.

[moogah]

16 bit audio needs about 700kbits/s if I've done my math right, which would mean that 8mbits/s should be more than enough to feed multiple channels of audio actually.  I guess a simple .wav file player will be the first step and a .wav mixer the second  8)

[Max Romantschuk]

Bah humbug! You kids and your 16 bits of audio data... Boy when I was a kid we only had one and a half bits if we were lucky, and it was uphill both ways I tell you! ;)

But really, 8 bits is plenty for lots of things. Halves the bandwidth. But greater challenges are not just simple playback of samples... When implementing a sampler one major concern is playing back samples reliably at different rates. Also how to deal properly with aliasing and keeping below the Nyquist frequency when playing back samples at a higher rate than they were recorded or that the DAC can produce. This is where the DSP hurdles come in.

Then again, if we were to have a large memory to use then you can use multiple samples for a wavetable with individual samples for different frequency ranges, solving the whole aliasing issue. (Some older wavetable synths did this to my knowledge.)

[Futureman]

8 & 12 Bit samplers have lots of character.. Thats what you want in a sampler as far as I'm concerned.. If you want high fidelity, then buy a second hand EMU Ultra6400 or Akai S5000 / S6000.. they are worth f$#k all right now.

I'd personally say that a DIY sampler should all be about the grit & dirt that comes with a 8 (or 12) bit sampler.. It shouldn't worry about filtering to get rid of aliasing & other artifacts.. shit like that rocks and adds character, much like the SID has all sorts of filth in it's sound which makes it rather unique.

Cheers

Mike

[moogah]

Bah humbug! You kids and your 16 bits of audio data... Boy when I was a kid we only had one and a half bits if we were lucky, and it was uphill both ways I tell you! ;)

But really, 8 bits is plenty for lots of things. Halves the bandwidth. But greater challenges are not just simple playback of samples... When implementing a sampler one major concern is playing back samples reliably at different rates. Also how to deal properly with aliasing and keeping below the Nyquist frequency when playing back samples at a higher rate than they were recorded or that the DAC can produce. This is where the DSP hurdles come in.

Then again, if we were to have a large memory to use then you can use multiple samples for a wavetable with individual samples for different frequency ranges, solving the whole aliasing issue. (Some older wavetable synths did this to my knowledge.)

8)  Careful or you'll get recruited!

I *do* like the sound of lofi sampling, but I don't really see the wisdom in starting out creating an under spec'd sampling engine.  Ideally we should be able to code up something that can operate across the full range of fidelity so people can decide for themselves what they want.  Same goes for intentionally leaving in aliasing and artifacts, I think the goal right now should be to create an engine that meets a proper specification for a sampler, once we've done that I think it will be very easy to know where modifications can be made to "degenerate" performance :)

[Max Romantschuk]

8)  Careful or you'll get recruited!

Hehe. :)

Unfortunately my DSP-related knowledge is limited to grasping the problems, but I'm rather useless at designing the solutions. (Tried to learn digital filter design once, the complex math was beyond what I was prepared to cram into my head... ;) )

But I agree that it's easy to make something more lofi, but it'd be a shame to have a sampling engine that produces too much clashing harmonies for it to be useful for melodic stuff. 

[moogah]

Even just knowing what the problems are is quite useful to me at this stage (all I really know is that I don't know much at all!), and working out solutions is something I'm pretty good at.. so don't hesitate to share what you know!

So it sounds like I'm going to need some DSP filters to properly handle aliasing, I can google those up and get some research done.

My big concern at the moment is, if we're going to be working with blocks of sample data then I think we're going to end up having to deal with "windowing functions" in order to provide a smooth output. 

Another possible approach is the adapt some granular synthesis techniques, which (beyond providing us with a very cool form of synthesis to work with) may greatly simplify some common operations.

[seppoman]

I also wouldn't say that an 8 bit sampler is "under-specced". For the hifi stuff I still have my EMU 6400 sampler which does an amazing job at that and can be bought on eBay nowadays for less than any DIY sampler would probably cost.  I'm really fascinated by the thought of a diy sampler, but even if a cheap i2s 16 or 24 bit codec was used, I'd say 8 bit sampling with 32 kHz and maybe 6 voices is absolutely sufficient. Better use the freed processing power for good oversampling/anti-aliasing/more voices/maybe one-shot streaming from SD/destructive functions/advanced synthesis features like granular or wavetable synthesis than for trying to achieve a commercial sampler's quality that's probably out of reach anyway.

S

[stryd_one]

Yeh... I mean, to refer to the original topic, the key word here is "bendable".

If you want a hardware sampler, for real, just go buy one. An akai s2000 can be had for a couple hundred bucks (about the cost of a custom panel on a rack case) and you can go up to some of the very nice e-mu samplers in the region of a couple grand with options galore, which you simply ain't gonna do in DIY land.

However... making a DIY sampler starts to have a point, if you can do something with it that is not possible with anything commercially available. "Bendable" doesn't *have* to mean hardware, doesn't have to mean jumpering random wires all over the place because you have no clue what you're doing... It can be in software and specifically designed to sound a certain way....

just my 2c....

[mrcam]

just curious... OFFICIAL RELEASE ANNOUNCED! APRIL 16-18 at BENT NYC!!!

http://www.narrat1ve.com  :P

[mirmidi]

Hi everybody.

Papareil synths labs made a very inspiring diy CV Quantizer / Wavetable Osc. It can be also used as a 8bit sample player!

http://m.bareille.free.fr/modular1/quantix8/quantix8.htm

[matoz]

Hi all!!

WTPA kits are available : http://www.narrat1ve.com

regards 

[stryd_one]

That's a good deal too!

[Flexinoodle]

Yeah a very good deal

I'm hoping to order one soon as poss

Flexi

[glitched]

I purchased a WTPA kit and the guy tells me I should receive it soon.  However, I might have jumped the gun a little because it's more like a looper than a fully fledged sampler, but it was fairly cheap and I'm really getting into this DIY stuff.  Who knows.

I'll report back when I get the stuff and start soldering!

[glitched]

Well, I got mine, soldered it, and started playing with it within a day.  Very easy kit to put together, even with the SMT chip. 

Take a look at some pics and listen to a couple sound files:  http://drop.io/wtpalog

The official forum is here:  http://www.narrat1ve.com/forum/ .