PDA

View Full Version : Teensy 3.2 for multichannel delay unit?



mykle
01-20-2016, 05:14 AM
Hello,

I'm trying to figure out if I would be able to build a certain piece of audio hardware I'm imagining using the Teensy. I really enjoyed Paul's demo video of the multi-tap delay. I have a design in mind for a multi-channel delay unit. I've also been looking for an excuse to start playing with the Teensy Audio library.

However, my concept involves being able to switch between & merge multiple channels of delayed audio -- at least four, to be really useful. And I imagine the sample length being something like ten seconds per channel. If I round up my total audio buffer size to sixty seconds, then my audio buffer would need to be 60 * 48khz * 16 bit samples = 5.76 megabytes.

Certainly that would fit on an SD card, and I could stick that in the teensy audio board's SD slot. But I've read there's limits to how fast SD cards can be read, and that getting even two simultaneous channels to play back at once (at audio bandwidth) requires a particular breed of SD card. (Could there be an SD card somewhere that's optimized for random access?)

I read about attaching a RAM chip that gets the memory buffer up to 1.5 seconds, but that's still almost two orders of magnitude too small.

I also read how 128 megabits of additional flash can be added to the teensy, equivalent (i hope) to 16 megabytes. But I'd be constantly re-writing this memory. It seems like flash could be a bad choice there. Although 100,000 write/erase cycles might take me a long time to use up ... I guess it would work for a while, if that spec can be believed. (If that flash chip can be socketed for easy replacement, I'd be less wary.)

On the other hand, I do have a pile of old laptop RAM in my basement, and I've read that the Cortex M4 has an auxilliary memory controller that can read SDRAM. Is there a way to hook up an old DIMM or SIMM to the Teensy 3.2 and use that as a buffer?

Thanks for any advice,

-mykle-

mxxx
01-20-2016, 07:48 AM
Hi,

SD cards won't work as a RAM substitute. SPI flash won't work either, very long write times; it's really just useful for permanent storage.

your best bet would be to use a bunch of SPI SRAM chips, as (i think) is shown in Paul's video (using frank's "memory board" (https://github.com/FrankBoesing/memoryboard)). though even that won't get you nowhere near 5.76MB; it's only 6 x 1Mbit = 0,75MB. so worth about ~ 8.5 seconds of mono 16 bit, if i see it right (the teensy lib is 44.1kHz, not 48kHz). it's possible to pull off very nice delays with those (for instance (http://www.alrightdevices.com/product/chronoblob) -- using 2 x 23LC1024, i believe), but unlikely 4 channels with 10 sec delay line each.

AFAICS, SRAM with more capacity means larger ICs with parallel interfaces. thus many pins. i don't think they'll work with teensy; and the MK20 doesn't have the FSMC, which you've probably read about (the "auxilliary memory controller").

PaulStoffregen
01-20-2016, 12:04 PM
Is there a way to hook up an old DIMM or SIMM to the Teensy 3.2 and use that as a buffer?


I'm probably the last person who could say the word "impossible", since I did something similar 17 years ago with SIMMs interfaced to a 8051 microcontroller!

But trust me when I say I know from experience this would be a long and difficult path.

PaulStoffregen
01-20-2016, 12:09 PM
This does make me curious though. What sort of project would use a 1 minute audio delay? That's an extremely long delay. Even just the 9 seconds (mono) with Frank's Memoryboard gives this sort of "is this thing really working" impression when you say or do something, and then you hear the sound.

Xenoamor
01-20-2016, 01:28 PM
So lets break this down into the two design specifications you have.
60 * 48khz * 16 bit samples = 5.76 megabytes total storage space
48khz * 16 bit samples = 768kHz or 1.302us per bit write/read speed

http://uk.rs-online.com/web/p/sdram-memory-chips/8115096/ seems like a potential.

Just grab an off the shelf RAM chip

mxxx
01-20-2016, 02:50 PM
So lets break this down into the two design specifications you have.
60 * 48khz * 16 bit samples = 5.76 megabytes total storage space
48khz * 16 bit samples = 768kHz or 1.302us per bit write/read speed

http://uk.rs-online.com/web/p/sdram-memory-chips/8115096/ seems like a potential.

Just grab an off the shelf RAM chip

care to elaborate?

i count about 36 i/o pins on this off the shelf RAM chip. teensy 3.x breaks out 34. minus 7 for i2s.

PaulStoffregen
01-20-2016, 03:28 PM
That chip also looks like only 2 MByte, only about 1/3rd of the capacity needed.

Xenoamor
01-20-2016, 03:45 PM
Ooops you're quite right! That's very rookie of me.

Yeah these data rates will probably need a high speed parallel interface

Pensive
01-21-2016, 01:08 AM
This does make me curious though. What sort of project would use a 1 minute audio delay? That's an extremely long delay. Even just the 9 seconds (mono) with Frank's Memoryboard gives this sort of "is this thing really working" impression when you say or do something, and then you hear the sound.

a guitar loop pedal, I can imagine looping entire verses and multiple layers when used properly. OF course it's not a delay, but it's an extension of the principle of a delay line.

https://www.youtube.com/watch?v=temYymFGSEc

The good news is that 4 channel playback from a decent SD card is achievable, but I don't know about recording as well, and writing at the same time... :-/

mykle
01-21-2016, 07:15 AM
a guitar loop pedal, I can imagine looping entire verses and multiple layers when used properly. OF course it's not a delay, but it's an extension of the principle of a delay line.

https://www.youtube.com/watch?v=temYymFGSEc

The good news is that 4 channel playback from a decent SD card is achievable, but I don't know about recording as well, and writing at the same time... :-/

Exactly. It's more of a looper, similar to what you might do with tape loops if you lived in the seventies. (Tape was the internet of the seventies. :) But with random access I could do a lot of handy things, like tweaking in & out points, A/B mixing (or A/B/C/D/E/F/G/H mixing), processing one channel with another channel, et cetera.

Still, my vision for this definitely involves reading and writing at the same time -- or, rather, reads and writes alternating fast enough that the user doesn't know the difference. So I assume SD is not the thing.

However ... I did a search on DigiKey for serial-access memory, and discovered some niche RAM technologies that I'd never even heard of!

Here's 4 Mb of Magnetoresistive MRAM:
http://www.digikey.com/product-detail/en/MR25H40MDF/819-1055-ND/4169130
"They are the ideal memory solution for applications that must store and retrieve data and programs quickly using a small number of I/O pins"

Here's 4 Mb of FerroElectric F-RAM:
http://www.digikey.com/product-detail/en/CY15B104Q-SXI/428-3413-ND/5702263
(Datasheet in Chinese, but their other F-RAM datasheets claim high speed, trillions of writes, hundreds of years, etc.)

If I could make do with 4MB, it seems like one of these might work. Assuming I can adapt it to the pads on the audio board ...

BTW, all the SPI-RAM datasheets i've looked at lately talk about three SPI modes: "normal" SPI, "dual" SPI and "quad" SPI. Can the Teensy speak "quad" SPI for reads and writes?

(The FRAM chips also describing supporting SPI modes 0 and 3. Suddenly SPI is way more complicated than I knew ..)

mykle
01-21-2016, 07:28 AM
Great video btw!

Frank B
01-21-2016, 07:48 AM
No, neither dual nor quad.

mxxx
01-21-2016, 08:01 AM
those are 4Mbit though?, so you'd still need like 8 (ie, for 4 Mbyte)! that might even be possible, but way too $$$ methinks.

and i see. a looper. fwiw, i was always wondering how the EHX 2880 was doing it (stereo only, but it records to SD); from what i've seen, it has a blackfin + some ISSI SRAM chip + (presumably 4-bit) SD.

it records/loops the entire SD (like minutes and hours, if need be), so i'd figure the SRAM is mainly working as some sort of recording buffer in this type of set-up. so you wouldn't need all that much SRAM, after all. something along these lines might be doable, i don't know? probably not 4 channels though.

fwiw, though it's stereo, not quad, you might want to consider a ready-made, hackable platform such as this (http://www.axoloti.com/product/axoloti-core/) ; it comes with both SD and 8MB SDRAM

Xenoamor
01-21-2016, 09:53 AM
Perhaps this (http://www.alliancememory.com/pdf/ddr1/Datasheet%20Alliance%2064Mb%20DDR1_AS4C4M16D1A-5T%28CI%29N-A%20rev1.1_TSOP_July%202015.pdf)?
You'll have to use 16bits for the data or use 2x8bits muxed. The address pins can be controlled by a shift register. This'll give you a FIFO kind of device which makes sense as you're recording sound chronologically

I don't think you'll find F-RAM that'll have the capacity, but they may exist somewhere.

PaulStoffregen
01-21-2016, 10:57 AM
DDR memories have a narrow range of very fast supported clock speeds. If you look at page 14 on that datasheet, you'll see the maximum clock cycle is 12 ns. That's the slowest you can use! And during the data phase, you must transfer data on both edges of that clock, or every 6 ns. Even worse, if you look carefully at the timing diagrams, you'll need you need to transition in the middle of those 6 ns.

Unfortunately, DDR is only practical with dedicated hardware interfaces, or the fastest FPGAs. Even in FPGA, meeting DDR timing with the programmable logic is extremely difficult. Many FPGAs now have dedicated DDR interface circuits for exactly this reason.

Accessing such a memory chip from a microcontroller's GPIO pins just isn't practical. :(

PaulStoffregen
01-21-2016, 11:00 AM
As much as I'd like to see Teensy used, for this large memory requirement, a single board computer like Beaglebone or Raspberry Pi is probably much more appropriate.

Xenoamor
01-21-2016, 01:29 PM
...the maximum clock cycle is 12 ns. That's the slowest you can use!

Thanks for the information Paul! This will be useful to know for an FPGA project I'm currently designing

It is a shame there isn't memory that'll do this though. The Teensy does have the speed required.
From a manufacturers point of view though I guess there isn't a market for slow access, high storage ICs

EDIT-
Well obviously there's Flash memory but there's a limited number of write cycles

Pensive
01-21-2016, 01:51 PM
As much as I'd like to see Teensy used, for this large memory requirement, a single board computer like Beaglebone or Raspberry Pi is probably much more appropriate.

I would agree with you, a RasPi has enough IO to handle an LCD screen, 4 or 5 footswitches and a bunch of LEDs. It also has enough power to do not just looping but all manner of effects without memory limitations and with bolt on 24bit audio boards a-plenty, (or usb sound cards) overall, you'll get a much more capable result.

Assuming you can get linux to play ball reliably in a headless environment. That's a whole other skillset in itself. :)

mykle
01-22-2016, 08:32 AM
As much as I'd like to see Teensy used, for this large memory requirement, a single board computer like Beaglebone or Raspberry Pi is probably much more appropriate.

Hmm ... any chance I can use Arduino and/or the Teensy Audio library on one of those platforms? =)
Or any other option to write bare-metal code in C without an OS?

I admit I got really frustrated trying to do audio on Linux years ago. I pretty much gave up on the idea of linux as an audio platform. It's probably better now, but running an entire unix OS to accomplish this level of thing still strikes me as insanely bureaucratic. And the real-world result of software bureaucracy is latency and bugs ... I've never seen an effects pedal kernel-panic before, and I don't want to start.

Here's some other opinions:

"The on-board chipset of the RPi has quite some limitations unfortunately. It only does playback and because of it's design it is not really suited for real-time, low-latency audio processing." -- http://wiki.linuxaudio.org/wiki/raspberrypi

The beagleboard might be a bit better -- http://lac.linuxaudio.org/2014/papers/32.pdf describes a way to get latency down to 7ms on it, although apparently it has no native audio IO & needs a USB audio interface to be purchased & installed. (7ms is considered "low latency audio" in the Linux world, but some audio engineers consider anything over 5ms to be a potential problem.)

Frank B
01-22-2016, 08:36 AM
Use 4 Teensys + 4 Memoryboards:)

mykle
01-22-2016, 08:39 AM
those are 4Mbit though?, so you'd still need like 8 (ie, for 4 Mbyte)! that might even be possible, but way too $$$ methinks.

Oh yeah, duh. b as in bits, not bytes. Soooo ... I guess 8 of those F-RAM would be $120 worth of chips. Not cheap, but not impossible either.


and i see. a looper. fwiw, i was always wondering how the EHX 2880 was doing it (stereo only, but it records to SD); from what i've seen, it has a blackfin + some ISSI SRAM chip + (presumably 4-bit) SD.

it records/loops the entire SD (like minutes and hours, if need be), so i'd figure the SRAM is mainly working as some sort of recording buffer in this type of set-up. so you wouldn't need all that much SRAM, after all. something along these lines might be doable, i don't know? probably not 4 channels though.

Tell me if I'm wrong because I've never done this, but ... doesn't the slowness of SD writing mean that your buffer fills up faster than you can empty it? Or is it faster to write SD in large blocks somehow?


fwiw, though it's stereo, not quad, you might want to consider a ready-made, hackable platform such as this (http://www.axoloti.com/product/axoloti-core/) ; it comes with both SD and 8MB SDRAM

Wow, that's a pretty interesting universe. Like PD, but then you can unhook it from the computer and stick it in a box. Thanks for the link! I'll look into it more.

PaulStoffregen
01-22-2016, 03:38 PM
Those little 23LC1024 RAM chips work out to be more affordable than FRAM. Eight of them makes 1 Mbyte for $16, versus two FRAMs at $30 or $40.

Connecting 46 of those RAM chips seems kinda crazy, but it probably could be done with appropriate logic chips and buffers.

Frank B
01-22-2016, 04:06 PM
One could use 4 or more Memoryboards with pins2-4 patched to different Teensy-pins. Easy. Just no pinheaders for 2-4 and some short wires instead.

Or, perhaps better, create an new board..

mxxx
01-22-2016, 04:21 PM
Tell me if I'm wrong because I've never done this, but ... doesn't the slowness of SD writing mean that your buffer fills up faster than you can empty it? Or is it faster to write SD in large blocks somehow?

i honestly have no clue. incidentally, this thread (https://forum.pjrc.com/threads/30421-SRAM-augmented-SD-card) just cropped up again, which i suppose (i haven't been following) is similar in spirit; though the concept seems to involve two teensies.

i'd be curious, too, if that would work, or make any difference; ie even for the audio shield equipped with one 23LC1024 -- i haven't tried anything except simple variations of the 'recorder' example, but occasionally was wondering whether it would be feasible to do a simple mono or stereo recorder/looper with simultaneous record/play, overdub etc.

Xenoamor
01-22-2016, 05:01 PM
ZTiK.nl over here (https://forum.pjrc.com/threads/16758-Teensy-3-MicroSD-guide?p=19958&viewfull=1#post19958) says he's getting a write speed of 1311.09 KB/sec with an SD card.

Don't you only need (758,000 * 16)/8 = 768kB/s?

mykle
01-22-2016, 06:12 PM
ZTiK.nl over here (https://forum.pjrc.com/threads/16758-Teensy-3-MicroSD-guide?p=19958&viewfull=1#post19958) says he's getting a write speed of 1311.09 KB/sec with an SD card.

Don't you only need (758,000 * 16)/8 = 768kB/s?

Yes, per channel -- but I need to read from and record to the same memory -- N channels reading while 1 channel writing, where N would (ideally) go as high as 8.

That gets into the issues Paul has mentioned on his site re: SD card random-access performance is much worse than sequencial-access performance. (Although I've never checked that, I only know what I'm told.)

OTOH, if I could access 8 SD cards in parallel, none of them would read & write at the same time & all access could be sequential ...

PaulStoffregen
01-22-2016, 08:34 PM
Hmmm, maybe this chip could work?

http://www.cypress.com/documentation/datasheets/cy62177esl-mobl-32-mbit-2-m-164-m-8-static-ram

It's also not cheap, $43 for TSSOP or $31 for BGA at Digikey, and also not quite enough (4 MByte) for the original goal... but pretty close. There's also a 8 MByte version, without the 8 bit data option, at appox $60.

http://www.cypress.com/documentation/datasheets/cy62187ev30-mobl-64-mbit-4m-x-16-static-ram

Either of these would need mux chips to deal with the large number of address pins. But at least they're async interface that could "easily" be used from microcontroller pins.

PaulStoffregen
01-22-2016, 08:37 PM
Oh, here's one that's "only" $21. ;) Digikey 1450-1026-ND

http://www.digikey.com/product-detail/en/AS6C3216-55TIN/1450-1026-ND/4234585

Frank B
01-22-2016, 08:48 PM
... for the SD-Card idea:

I think you could save some time (some milliseconds) without a filesystem and use blocknumbers instead.
It would be insteresting to know how much channels would work, this way..
Then, for a bit more speedup, you could try to find really old SD-cards in the 512MB -size range. Some time ago i played with some cards and found that they were faster* (perhaps due to simpler internal algorithms or simpler adressing..)
The problem with SD-Cards is adressing blocks - this takes a long time.


Edit:
*for random-access (they were some 100us faster)

edit:
..but i don't believe that more than 2 channels with concurrent read+writes are possible. maybe only one.

Frank B
01-22-2016, 09:03 PM
Oh, here's one that's "only" $21. ;) Digikey 1450-1026-ND

http://www.digikey.com/product-detail/en/AS6C3216-55TIN/1450-1026-ND/4234585

Could be interesting to add a some sort of shift-register and use it as "spi ram".. something for onehorse ?

PaulStoffregen
01-22-2016, 09:25 PM
Probably a job for a 64 to 128 macrocell CPLD....

Maybe like this?

http://www.digikey.com/product-detail/en/LC4064ZE-5TN100C/220-1016-ND/2641817

Frank B
01-22-2016, 09:57 PM
The BE MICROMAX 10 is a FPGA Evaluation Board for 30$ with 8MB RAM:




Adopts Altera's non-volatile MAX 10® FPGA built on 55-nm flash process
Powered by Altera's Enpirion® Power SoCs
Includes 8MB SDRAM, accelerometer, digital-to-analog converter (DAC), temperature sensor, thermal resistor, photo resistor, LEDs, pushbuttons and several different options for expansion connectivity
Embedded USB-Blaster™ for use with the Quartus® II Programmer
Expansion headers include – two 6-pin PMOD, two 40-pin prototyping headers, one 6-pin analog input header and one 80-pin BeMicro card edge connector



https://www.arrow.com/de-de/products/bemicromax10/arrow-development-tools#page-1

mykle
01-24-2016, 08:15 PM
To tell the truth, that Axoloti Core (http://www.axoloti.com/axoloti-core/) board actually looks almost perfect for this. The CPU is apparently a variant of the same ARM chip as the Teensy -- the variant with a memory controller. The board comes with 8mb SDRAM installed, plus the audio IO connectors already built in.

The Axoloti project, actually, seems in many ways to be approaching the same vision as the Teensy Audio Lib: there's a visual UI configuration tool you use to set up the route of audio through the system, then that gets compiled down to C code which is compiled & installed on the board. The Axoloti config is a Java app instead of a web-app, but it actually creates a UI that talks to the compiled firmware & controls it live -- something that I think Paul has talked about doing eventually.

On the other hand, I dug around their github (https://github.com/axoloti/axoloti) ... the Axoloti software architecture looks way more complex than Teensy Audio; it's daunting. And Axoloti's Java UI has poor usability compared to the Teensy Lib's web UI; all the controls are so tiny on my screen, selecting anything is a pain. There seem to be a decent number of Axoloti users, but in github I don't see any major contributors beside the inventor and one other person. I'm a little wary to base a project on a software platform that's well-understood by only two people, and not particularly well-documented either.

Really, I wonder if I could get the Teensy Audio Lib to run on the Axoloti hardware! Is that possible? I imagine there was a lot of complexity in getting the Arduino environment to target the Teensy's ARM chip instead of an Atmel in the first place ... and I don't really know what the Teensy Loader does at all ... but I'm more comfortable writing bare C code with avr-gcc and avrdude anyway. It seems like there's open-source code in the Axoloti project that I can use for working with the SDRAM & audio IO, and there's a Makefile that illustrates how to get it all compiling with gcc. I just don't know what hardware assumptions Teensy Audio is making, and how much would have to change for it to work on this other board.

Also, I'm not sure how Paul would feel about his Teensy-supporting code being ported to other hardware. =/

PaulStoffregen
01-24-2016, 08:37 PM
To tell the truth, that [URL="http://www.axoloti.com/axoloti-core/"]
Really, I wonder if I could get the Teensy Audio Lib to run on the Axoloti hardware! Is that possible?


Possible, maybe, but a tremendous amount of work.... probably *much* more work than fixing these shortcomings of Axoloti's software.



Also, I'm not sure how Paul would feel about his Teensy-supporting code being ported to other hardware. =/

I wouldn't be happy.

Frank B
01-24-2016, 08:42 PM
But the other way.. i just forked the code.
Interesting things there, that could be ported to Teensy.

Easiest are the 808-samples.. but there might other interesting effects too, which don't need so much ram.

mykle
01-24-2016, 09:39 PM
... for the SD-Card idea:

I think you could save some time (some milliseconds) without a filesystem and use blocknumbers instead.
It would be insteresting to know how much channels would work, this way..
Then, for a bit more speedup, you could try to find really old SD-cards in the 512MB -size range. Some time ago i played with some cards and found that they were faster* (perhaps due to simpler internal algorithms or simpler adressing..)
The problem with SD-Cards is adressing blocks - this takes a long time.


Edit:
*for random-access (they were some 100us faster)

edit:
..but i don't believe that more than 2 channels with concurrent read+writes are possible. maybe only one.

I can sort of picture making *something* work using just 2 channels: one channel of writes, multiplexing all 8 channels of audio in parallel in each block, writing sequentially to the buffer, and one read channel that reads the same 8 channels in parallel, but from a different position in the buffer. Metaphorically it'd be like an 8-channel tape loop with the read & write heads at different positions.

Is that possible with SD? Has anyone benchmarked the speed of this direct-block writing/reading to SD, circumventing the filesystem?

On the other hand ... one job of the filesystem layer on a hard drive is to map out bad blocks. Do SD cards get bad blocks? Are they hardware mapped, or would they need to be mapped in firmware? Is read/write speed affected when that happens? Seems like that could be a source of glitches.

PaulStoffregen
01-24-2016, 09:54 PM
I want to stay focused on developing awesome features, but the difference in open source licenses is important.

Axoloti is GPLv3 with copyright assignment to Johannes Taelman.

Teensy Audio is MIT or MIT-like. Many people do embed Teensy inside products they sell, or they make their own PCB, sometimes with the chip we sell, sometimes without. My intention has always been to allow people to use the library for their commercial & proprietary purpose, even if they're making their own hardware without buying anything from PJRC. That's not the best or most profitable business decision, but if I only cared about profit I almost certainly wouldn't be making making dev boards and free software platforms. I'm willing to be flexible on license terms for contributed code, but I do want to stay in the permissive spirit of MIT for code people will embed inside microcontrollers. On the PC tool side, GPL is fine.

Please don't submit GPLv3 code for the Teensy Audio Library. Let's respect Axoloti's GPLv3 license.

Edit: but I'm happy to hear about any features Axoloti has that we should consider, and even the algorithms involved. Let's just make sure we're not copying Axoloti's code in violation of its license terms.

PaulStoffregen
01-24-2016, 10:12 PM
Has anyone benchmarked the speed of this direct-block writing/reading to SD, circumventing the filesystem?


Well, File > Examples > Audio > Recorder has a couple lines you can uncomment to see the write time. With just a small amount more code, you could print the file offset. If you know the FAT32 cluster size of the filesystem (something I'm sure you could find out with various PC-based utilities reading the card), you should be able to tell which writes are direct to the media and which ones are involving location or allocation of a new cluster.

You could also try File > Examples > SerialFlash > RawHardwareTest on a flash memory chip. It prints some benchmarks about the 256 byte page write time.

In fact, here's a test run on a Macronix MX25L25635FMI-10G (32 Mbyte) chip. 256 bytes writes in 469 us, and that's with the overhead of suspending the write once to read 8 bytes.



Raw SerialFlash Hardware Test

Read Chip Identification:
JEDEC ID: C2 20 19
Part Nummber: (unknown chip)
Memory Size: 33554432 bytes
Block Size: 65536 bytes

Reading Chip...

Writing 32 signatures

Double Checking All Signatures:
all 16384 signatures read ok

Checking Signature Pairs
all 8191 signature pairs read ok

Checking Read-While-Write (Program Suspend)
write 256 bytes at 512
write time was 469 microseconds.
read-while-writing: 00 00 00 00 15 F5 95 4B
test passed, good read while writing

Checking Read-While-Erase (Erase Suspend)
erase time was 268634 microseconds.
erase correctly erased 65536 bytes
read-while-erasing: 00 00 00 00 15 F5 95 4B
test passed, good read while erasing

All Tests Passed :-)

Test data was written to your chip. You must run
EraseEverything before using this chip for files.

Frank B
01-24-2016, 10:43 PM
Please don't submit GPLv3 code for the Teensy Audio Library. Let's respect Axoloti's GPLv3 license.

Edit: but I'm happy to hear about any features Axoloti has that we should consider, and even the algorithms involved. Let's just make sure we're not copying Axoloti's code in violation of its license terms.

Sure.
I bet we need some more or less heavy modifications anyway.

mykle
01-25-2016, 06:51 PM
The Axoloti licensing is definitely an issue for me as well. Right now I'm just trying to make something for myself, but if I do come up with something really handy, I'd like to be able to dream of someday selling it. =)

It sure would be awesome to be able to buy a Teensy shield with audio IO, midi IO, a memory controller and some RAM on it. But for now I think I'm going to play around a little with the Audio Shield & see what kind of raw block performance I can get out of SD cards. Sometimes limitations bring focus.