Build Thread - Beatmaker

Status
Not open for further replies.

Pensive

Well-known member
Hi guys

I would appreciate a moment of your advice in the context of how possible this is. OF course, I think its possible but I'm aware I'll be pushing the limits. please see attached layout.

beatmaker-mockup.jpg

In the style of midifighter, I am building a simple Akai MPC clone. Think of it as an x-channel mod player with buttons. x being the number of polyphonic channels I can play at once without the cpu weeping in the corner.

Core kit: Teensy 3.1 + Audio board + 4gb microsd (bought)
Button input : PS/2 mini-pac interface : http://www.ultimarc.com/minipac.html (bought)
LED output: 2 x 16 channel i2c breakouts: https://www.adafruit.com/product/815
Switches: full size arcade with 5v LEDs for the 16 big ones (Bought), 16mm arcade buttons without LEDS for all others
Nav and Menu buttons are rotary encoders (bought). But I think i'll need a "push click" one for the menu button.
Coloured dots are 3v LEDs.
LCD display: 16x4 (http://www.hobbytronics.co.uk/lcd/lcd-displays-5v/lcd-16-4-backlight-blue) with i2c backpack (http://www.hobbytronics.co.uk/i2clcd-backpack-v2) to reduce pinouts.

Interrupts:
push button interface needs interrupt pin
The rest probably don't.

Apart from bursting at the seams for ram (it will fit. I'm sure it will fit.) and overclocking being a necessity,
1) are there any obvious gotchas?
2) i2c stacking issues?
3) LCD noise with the audio board etc?

This is a fairly complicated undertaking, but I'm pretty sound on the code, (i'll need to build on the audio library rather a lot) its really getting all this kit, plugged together, orchestrated by a single Teensy 3.1 @ 96Mhz.
4) In your honest opinion, can it be done as a whole?
5) how much power am i going to need, is battery power a realistic goal?

Thanks

Jon
 
It's probably doable.

The main technical limit for playing many simultaneous sounds is probably going to be SPI bandwidth and SD card random access latency.

Looks like LEDs are going to be your main power consumption. How many and how much current you'll put through each, I have no idea. Maybe you could count them up and do some tests with a power supply and different resistors, to learn how much current they need to "look good".
 
It's probably doable.

The main technical limit for playing many simultaneous sounds is probably going to be SPI bandwidth and SD card random access latency.

Looks like LEDs are going to be your main power consumption. How many and how much current you'll put through each, I have no idea. Maybe you could count them up and do some tests with a power supply and different resistors, to learn how much current they need to "look good".

Thanks Paul, I 'm glad you think the CPU will be up to it, that was my concern.

I plan to load samples from the SDCard into the flash as banks for playing, rather than playing direct from the card, to get around this, so mostly short chopped samples from a single loop, and individual instruments. 256 k isn't a lot but if I'm careful and perhaps incorporate 22khz instead then we might be in business. I might need to use both together of course....

I would then mix them direct in the teensy and pump it out through the audio board as a single spi 44khz stereo (mono doubled) out.

Incidentally my intention is to put most of the new audio mixing code in the audio library , is there a preferred workflow for this sort of thing ? Make an Audioplus library which extends Audio, until the code is fully incorporated? Or just add it to the audio library and push the changes for inclusion?

Re:LEDs, I have no clue , I'll just have a play and see how it goes, the chips support pwm as well do I can dial them down if I want.

Thanks

Jon
 
Thanks Paul, I 'm glad you think the CPU will be up to it, that was my concern.

Playing directly from memory probably isn't a problem.

You could try loading the PlayFromSketch example, wire all 6 pins together, or just write some code that causes all 6 to play at once.

Then add a bit of Serial.print code to look at the usage from AudioProcessorUsageMax(), which tells you the worst case total CPU usage the audio library has consumed so far.
 
You know I think I'll write it to keep layering up until that setting hits 100%, see how she flies. :)

Weekend challenge :)
 
Sequencer Specification

In the interests of the greater community I am attempting to conceive a scalable sequencer design, which can be applied to any audio object in the future.

Forgive my brainstorm, I have to write all this stuff somewhere, I might as well write it here. Feel free to ignore my brainfarts.

In brief summary I have aimed for 64 "channels" if you will although one channel can only have one instrument. So really its just a 64xpolyphony sequencer, with polyphony on each poly-channel to boot).

I have used 96 PPQN (Pulses per Quarter note) which is a rule of thumb for MIDI pulses so it should allow realtime recording of events transparent to the ear (From a timing point of view), with the option of non-destructive quantisation and I also hope to implement a reasonable form of MPC-Style swing within my project, also non destructive.

I attach a draft spec for the system.

Please note for my project I will only need to implement the Core and Quantize functions, I have little use for panning or velocity with my project so this might begin a framework, but I can't promise to finish the framework, although I would like to.

DSP Parameters and Passing other parameters (eg to audio objects like synths with multiple ) needs work , as does determination of re-trigger requirements. If the button hasn't been pressed but a potentiometer has been moved while the sample is playing which affects its cutoff for example, how do I implemente this? (This has just popped in my head but I have to get on with my work now :) )
Again, this is not likely to be something that will affect my project - which is why I havent thought it through to the end yet.

Possible changes:

An extension I am also considering would be to double the ram size of the Loop to 6Kb and a 00 is do nothing, a 10 is trigger, a 01 is held down and a 11 is released. This would afford after touch parameters to be passed and sequenced to wavetable synths for example, and much more complex drumkits / instruments to be designed and sequenced. But at the sacrifice of more RAM.
Similarly passing this through to the event management would allow me to not respond to an 00 to trigger but still pass adjusted params through.

ENOUGH. I must do some paid work.
 

Attachments

  • Audio Library Sequencer - Draft Spec Rev 0.pdf
    48.7 KB · Views: 299
In the interests of the greater community I am attempting to conceive a scalable sequencer design, which can be applied to any audio object in the future.

If you are going to go through all the effort to start audio events with precision timing, you would be revered if you added hooks for sending MIDI events as well. It's not a lot of data: you have to edit or capture note number and velocity and then send a timed note off, too.

I have a Beatstep, Retrofuture Orb, and various other sequencers built into synths, but they are designed to drive ONE device. Having a hackable all-in-one conductor would be great. Something like a (very) feature reduced version of an MPC (which has multiple audio and MIDI outs), Midibox SEQ, or Cirklon (multiple MIDI and CV outs).

Keep us informed. Sequencers are invaluable extra hands with impeccable timing.
 
If you are going to go through all the effort to start audio events with precision timing, you would be revered if you added hooks for sending MIDI events as well. It's not a lot of data: you have to edit or capture note number and velocity and then send a timed note off.

Keep us informed. Sequencers are invaluable extra hands with impeccable timing.

The thought did cross my mind; I considered building the sequencer entirely on MIDI. Ultimately I chose take inspiration from it instead, to craft something more memory and CPU efficient for the teensy.

the solution here might be to add midi support to the Audio library. But I will extend the loop size to include note on, note off information so this is easily achievable.

I'm going to remove the per-event DSP function as on reflection the hardware DSP on the audio board is a global event which is different.

With that in mind I will include midi level note data in the sequencer which will open the project to midi connectivity in the future. I'm pretty sure I'd need another Teensy to get USB midi running along with all this so it isn't something I 'll get working for my project.
 
Last edited:
Incidentally I've looked into midi commands:

http://www.indiana.edu/~emusic/etext/MIDI/chapter3_MIDI4.shtml

Half of me wants to write a midi compatible sequencer, half of me is extremely concerned about limited memory resources.

It uses 3 bytes for a single basic command, channel, note, and velocity, where I am using a lot less with my current design. my velocity resolution is far lower (0-31 against 0-127), I've added support for panning,and i'm not doing notes at the moment.

But I have come up with a solution. At the moment each core event wastes 8 bits on an ExtensionDef even if there are no extensions. This was poor design, but also allows me to justify the changes.

I can make Velocity a core element at midi resolution, following by a single stop/go bit. This bit being 0 will form the end of the event. if it is one, it will continue onto the Extension def. This is where the note definition will come from if the event wishes to define one (otherwise this can default to middle C).

I should be only a couple of bits bigger per core event, but then capable of fully sequencing full resolution MIDI data, without compromises.

I think it strikes a good balance between resource consumption and future-proof functionality. I'm sure Teensy 4 and 5 will arrive at some point......so lets not hobble the engine based on todays limitations =D
 
Wow, I had exactly the same idea to build a beatmaker using the Teensy and Audio Board.
However I wanted to use the Adafruit Trellis button platform for the trigger inputs, because I
think it gives a smoother feel than Arcade Buttons. I also wanted to use the integrated LEDs
to show wether a pad even has a sample loaded.
I would love to read more from you here, please keep updating this thread with your progress.
 
Yeah, I didn't come across the trellis until after I had made all my plans!

I guessed they're all micro switches though? How does it feel to bash a trellis? And how robust are they?
 
Ps my arcade buttons have LEDs in ;)

And the trellis is Tiny! Way too small for me...
 
Last edited:
Hi,

I think this will be doable, maybe not 64 poly. Today i hocked up an trellis on my Board, works quite well. Sure its not an mpc, but its a lot of fun. ��

Im interested with what you will come up.

http://forum.pjrc.com/threads/26861-Project-Teensy-3-1-AudioBoard-Sequencer

Andi

Awesome project, fair play for 7 hours work!!! I think mine may take a little longer.... :)
You've almost recreated an 808 drum machine there........mini project?

64 poly is misleading, I'll do some experiments and probably run either 10 or 13 maximum polyphony, drawn from a maximum of 64 sequenced channels.

Since the audio library is essentially static it makes the most sense to define limits, and allow the 64 channels to be rendered out via those streams as per demand.

I actually think 10 will be plenty for most stuff.



It's taken me a while but today i actually fired up my teensy for the first time, slightly concerned that I had messed everything up with my rusty solder skills.

Everything worked firs ttime - except the LED didnt blink at first, but there's nothing quite as dumb as a human, I'd plugged the audio board on the wrong way round.

:)

photo.jpg
 
Having done some tests, 10 concurrent mixed samples used only 9% of the CPU time.

This is excellent stuff, which suggests that 64 voice polyphony is a possibility if everything is in RAM.
I don't think I need 64 voice polyphony.

10 or 11 should be fine for most simple beats tracks, adding a couple of WAV streams form the SD card (loops, or vocal / microphone / line in tracks) plus some synth channels for bass and lead instruments.

This should leave plenty of CPU headroom for any performance hits from effects / compression / LCD display / LED updates and other ancillary stuff like the performance hit one might suffer when using the SPI 16Mbyte flash chip (not yet implemented).

So below, behold my first draft of the mixer arrangement. Next step is to get 14 samples, Wav1 and Wav2 prepped so i can set up all the mixers and see what happens when i play all of these together at once. Ignore the waveform synth bits, I really don't have a clue how i'll put a synth together yet, this is just my guess.

Initial-layout-design.jpg
 
Excluding all the WaveSynth objects, and mixer 6 (mixer 1 routed direct to the headphones):

All samples 22khz U-law 8bit.
Using the first 2 test wave files:

Here are the CPU loadings reported from my tests

1 Samples = 2% (3 mixers)
2 Samples = 3% (3 mixers)
4 Samples = 5% (3 mixers)
5 Samples = 6% (3 mixers)
10 Samples = 9% (3 mixers)
14 Samples = 14% (5 mixers)
SDTEST1.WAV, SDTEST2.WAV, and 1 sample = 87% (5 mixers)
SDTEST1.WAV and 14 Samples = 51% (5 mixers)
SDTEST1.WAV, SDTEST2.WAV and 14 Samples = 93% (5 mixers)

in each case, there were no effects or filters, DAC output was disabled, and the CPU was running at 96Mhz.

____________________________

I wonder if this is the SPI bus or the SDcard access taking up so many clockticks?
I hope its the SD card access, otherwise the on board 16Mbyte SPI flash chip might not be as useful as I am hoping.
 
Last edited:
I have done a little mockup of the audio library draft layout for just the drums. It may stay as simply drums because i am concerned about clockticks.

Still needs work. Who ever used 8 tap delay on a basskick? Maybe on some bad ass acid dub ting.....but not very common....

draft-drumset-topology.jpg


and i'm currently talking with my wonderful brother (a modelmaker) about the acryclic =D

design as attached

View attachment beatsbyteensy FINAL DRAFT.pdf

getting there very slowly.
 
I hope its the SD card access, otherwise the on board 16Mbyte SPI flash chip might not be as useful as I am hoping.

It is. The card is very slow with our way to access it.
Maybe the next teensy has an SDIO Interface ? SDIO is MUCH faster.
 
I wonder if a more sensible approach would be an embedded platform that runs on Raspberry Pi hardware......

It's been tried before....but not done well. Kick Linux to the kerb and put an embedded loader on the beasty, and find a way to make those ample CPU and RAM resources vailable as if it were a Cortex M4 processor.....

Probably a thousand reasons why this hasn't been done yet....
 
Last edited:
I wonder if a more sensible approach would be an embedded platform that runs on Raspberry Pi hardware......

It's been tried before....but not done well. Kick Linux to the kerb and put an embedded loader on the beasty, and find a way to make those ample CPU and RAM resources vailable as if it were a Cortex M4 processor.....

Probably a thousand reasons why this hasn't been done yet....

i'm not sure what kind of thing you're after (drum machine, it looks like), but an obvious solution would be to use 2 (or more) teensies. nice bonus: more (or even individual) outputs (per voice).
 
Of course I have considered this possibility, and I may be forced to do this. I can make a drum machine no problem, I want to make an MPC which supports synth channels, vocal tracks and loop sampling (that's the golden dream at least).

One teensy will not be able to do it all well via SDCard but with more ram, it might become feasible on a single over clocked teensy.

Taking the SDCard out "of the equation, the theoretical number of voices mixed directly from ram was approaching 100. It is RAM that is my current bottleneck; I hope to make effective use of the 16Mb chip to see what she can do.
 
Status
Not open for further replies.
Back
Top