This just popped up:
https://www.kickstarter.com/projects/electro-smith/daisy-an-embedded-platform-for-music/description
An alternative to Teensy perhaps. A bit pricier, but has the codec on-board, as well as a hefty 64MB of RAM which is very interesting for looping/long delay/reverb/granular type stuff!
They plan on supporting pd and maxmsp, as well as providing libs and examples for arduino and (as I understand it) standard C++ libs. I like that's they're seperating the peripheral libs from the DSP libs (at least that's what it looks like), in case I want to do my own DSP!
I've bought various eurorack kits and modules from them before, so can confirm that they are a real company. ;D
Looks great, and a very good alternative to Teensy. Not that much pricier, and codec+memory included.... looks like a good deal.
If you add the external accessories gets expensive though.
pd and maxmsp support is a blast!
I built a pedal using PD based on a Rpi, but I abandoned it due to my reluctance to use a device with a headless linux in it, and the complexity of editing stuff in it. This could be a good alternative to reuse my PD patches.... :)
Quote from: cloudscapes on February 25, 2020, 09:01:43 AMa hefty 64MB of RAM which is very interesting for looping/long delay/reverb/granular type stuff!
Before getting excited about that large external memory I'd want to know what kind of throughput you can get. While it may be suitable for looping (one sample per sample) you may find it's too slow for brute force reverb simulation (reading 10's of delayed samples from the delay memory for every output sample).
Quote from: audioartillery on February 26, 2020, 05:31:28 PM
Before getting excited about that large external memory I'd want to know what kind of throughput you can get. While it may be suitable for looping (one sample per sample) you may find it's too slow for brute force reverb simulation (reading 10's of delayed samples from the delay memory for every output sample).
Yeah I'm looking forward to knowing more about those kinds of specs. It's parallel SDRAM, so should be very fast.
when they talk about supporting Pd and Max/MSP they mean that they are "[...] supporting Max/MSP through the Gen~ object, and Pure Data through Heavy export" which is quite a different thing and many other platforms do (like the Rebel Technology OWL Pedal, which is now 5 years old!).
I feel that , unless they have developed their own streamlined framework, they are not bringing anything really new to the table. The extra power and the nice quality AKM codec are a plus and their range of dev boards is nice.
That said, it looks nice, and at $29 for a dev board it looks worth supporting :).
Quote from: potul on February 25, 2020, 11:29:59 AM
I built a pedal using PD based on a Rpi, but I abandoned it due to my reluctance to use a device with a headless linux in it, and the complexity of editing stuff in it. This could be a good alternative to reuse my PD patches.... :)
You should try Bela (shameless plug) :icon_mrgreen:
Quote from: micromegas on February 27, 2020, 05:36:32 PM
You should try Bela (shameless plug) :icon_mrgreen:
I did mess with a Bela for awhile with Faust. Getting that all set up with a separate cross compiling Linux machine was quite a bit of effort but I did do it. I think it's probably OK for FX not involving gain as it's only got 16 bit DACs and seemed a bit noisy to me.
Can't guarantee anything but it sounds like the Faust team is looking at the Daisy with an eye to supporting it.
^bump
How did I miss this one? :o There seem to be a lot of code examples in their Github.
https://www.electro-smith.com/daisy
regards, Jack
I love how they call their pedal "Petal."
Cute and clever. :icon_lol:
I can't decide whether to get the Daisy Seed or the Teensy 4.1?
https://www.pjrc.com/store/teensy41.html (https://www.pjrc.com/store/teensy41.html)
https://www.electro-smith.com/daisy/daisy (https://www.electro-smith.com/daisy/daisy)
Daisy Seed:
ARM Cortex-M7
64MB of SDRAM, and
8MB of flash memory
16-bit Analog to Digital Converters
Teensy 4.1
ARM Cortex-M7
1MB of RAM
8MB of flash memory
16 bit Analog to Digital Converters, but need to buy the additional Audio shield board?****
Looking at the specs, the Daisy Seed looks a better option.
What do you think?
The Daisy Seed has 24bit converters.
While the Teensy Audio library is a fun thing to play with, the limitations of 16 bit operations make it a no-go for me :icon_sad:
I can't see 24bit ADC mentioned in the Daisy Seed spec here:
https://www.electro-smith.com/daisy/daisy (https://www.electro-smith.com/daisy/daisy)
Maybe, I missed it, I can only see this.
"Pinouts include:
. 31 total GPIO pins which can be configured as standard GPIO or one of several alternate functions including 16-bit Analog to Digital Converters(x12)
. 12-bit Digital to Analog Converters(x2)"
But, yes, on paper, the Daisy Seed looks better for audio projects.
I pikced up a Daisy and a PedalPCB Terrarium a month or so ago to play with, both are still sitting untouched on my bench. I'm sure everyone knows how that goes ::)
Quote from: GuyB on November 17, 2020, 12:21:51 PM
Maybe, I missed it, I can only see this.
"Pinouts include:
in the same page, scroll up:
"Hardware: ARM Cortex-M7 MCU, High fidelity AKM stereo audio codec with up to 24-bit 192kHz, 64MB of SDRAM, and 8MB of flash memory"
Quote from: potul on November 18, 2020, 02:22:12 AM
Quote from: GuyB on November 17, 2020, 12:21:51 PM
Maybe, I missed it, I can only see this.
"Pinouts include:
in the same page, scroll up:
"Hardware: ARM Cortex-M7 MCU, High fidelity AKM stereo audio codec with up to 24-bit 192kHz, 64MB of SDRAM, and 8MB of flash memory"
Thanks, yes, I think the Daisy will play 24bit/192kHz audio, but I think it's stating that it uses 16bit analog/digital converters.
It states "including 16-bit Analog to Digital Converters" here:including 16-bit Analog to Digital Converters (http://including%2016-bit%20analog%20to%20digital%20converters)
I think I need definite info on this, as the spec isn't clear, I'll search the Daisy forum.
QuoteAKM stereo audio codec
I consider a CODEC to be capable of Encode and Decode. So it's either capable of DAC and ADC or a misnomer. I'm sure a lot of people say codec 'cause it's easier to say and write.
Quote from: GuyB on November 18, 2020, 06:45:10 AM
Quote from: potul on November 18, 2020, 02:22:12 AM
Quote from: GuyB on November 17, 2020, 12:21:51 PM
Maybe, I missed it, I can only see this.
"Pinouts include:
in the same page, scroll up:
"Hardware: ARM Cortex-M7 MCU, High fidelity AKM stereo audio codec with up to 24-bit 192kHz, 64MB of SDRAM, and 8MB of flash memory"
Thanks, yes, I think the Daisy will play 24bit/192kHz audio, but I think it's stating that it uses 16bit analog/digital converters.
It states "including 16-bit Analog to Digital Converters" here:including 16-bit Analog to Digital Converters (http://including%2016-bit%20analog%20to%20digital%20converters)
I think I need definite info on this, as the spec isn't clear, I'll search the Daisy forum.
Hm, confusing indeed. I have no idea what this remark of "16 bit ADCs" is about.
The AK4665 is a 24 bit codec, so ADC+DAC:
http://atlantikelektronik.de/fileadmin/_templates/ATE/Datenblaetter/AK4556VT_Datasheet_AKM.pdf
Schematic of the Daisyseed here:
https://github.com/electro-smith/Hardware/blob/master/reference/daisy_seed/ES_Daisy_Seed_Rev4.pdf
Quote from: pruttelherrie on November 18, 2020, 12:29:19 PM
Hm, confusing indeed. I have no idea what this remark of "16 bit ADCs" is about.
There is the audio stereo ADC-DAC, and there are also 12x 16bits ADC inputs (for pots, expression pedals, etc....). And 2x 12bits DAC outputs to interface with whatever you like.
This is at least my understanding.
Hey so if reading this right, it has analogue to digital and digital to analogue converter built in so i would not need any op amp to convert signal compared to an arduino ..?
i want to run my guitar in - Program the daisy as an on/off momentary switch for the effects circuit and then send the signal back
You are getting confused.... An opamp is not an ADC.
Guitar signals will need to be aconditioned before feeding the ADC, so I would say you still need some kind of buffering/amplification. Line level signals might be ok to be fed directly.
Quote from: potul on November 18, 2020, 12:58:08 PM
Quote from: pruttelherrie on November 18, 2020, 12:29:19 PM
Hm, confusing indeed. I have no idea what this remark of "16 bit ADCs" is about.
There is the audio stereo ADC-DAC, and there are also 12x 16bits ADC inputs (for pots, expression pedals, etc....). And 2x 12bits DAC outputs to interface with whatever you like.
This is at least my understanding.
Ah yes!
I think you're right.
After a bit more research, I've learned that the Daisy Seed has the AK4556 chip on it's board for an AD/DA converter:
https://www.akm.com/content/dam/documents/products/audio/audio-codec/ak4556vt/ak4556vt-en-datasheet.pdf (https://www.akm.com/content/dam/documents/products/audio/audio-codec/ak4556vt/ak4556vt-en-datasheet.pdf)
"The AK4556 is a low voltage 24bit 192kHz CODEC for high performance battery powered digital audio subsystems. The dynamic performance to power supply voltage ratio is very high, attaining 103dB and 106dB SNR for ADC and DAC, respectively. Sampling rates up to 216kHz are supported. The AK4556 reduces jitter sensitivity by using an integrated switched-capacitor filter. The analoginputs and outputs are single-ended to minimize pin count and external filtering requirements. Packaged in a very small 20-pin TSSOP, the AK4556 is ideal for space-sensitive applications."
Potentially, the Daisy Seed is looking very good.
ElectroSmith posted this statement here:
https://www.muffwiggler.com/forum/viewtopic.php?t=228165 (https://www.muffwiggler.com/forum/viewtopic.php?t=228165)
"Here are some specs!
CPU: STM32H750IBK6
SDRAM is run at 100MHz with 32-bit accesses per clock (the 1MB of internal SRAM is clocked at 480MHz). The external SDRAM is connected via a 32-bit parallel data interface.
Audio codec: AK4556 (Stereo 192kHz / 24-bit)"
Getting started with Daisy Seed:
https://forum.electro-smith.com/t/welcome-to-daisy-get-started-here/15 (https://forum.electro-smith.com/t/welcome-to-daisy-get-started-here/15)
Some example Daisy Seed coding examples are here:
https://github.com/electro-smith/DaisySP/tree/master/examples (https://github.com/electro-smith/DaisySP/tree/master/examples)
Quote from: pruttelherrie on November 17, 2020, 11:32:26 AM
The Daisy Seed has 24bit converters.
While the Teensy Audio library is a fun thing to play with, the limitations of 16 bit operations make it a no-go for me :icon_sad:
The Teensy is not limited to 16-bit at all. You can you whatever you want for your intermediate processing. Float, double, etc. I use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough. What you are limited to as 16-bit audio TRANSPORT. This means passing audio BETWEEN effects is 16-bit. But within an effect processing bock, you can have as much precision as you need.
ChipAudette even expanded the Teensy audio library to support floating point values as the native transport mechanism, but again, if you think you need more than 16-bit transport between stand alone audio effect blocks you might be making your processing less efficient than it could be for the same result.
You really do not need more than 16-bits for transport.
Quote from: Blackaddr on November 20, 2020, 11:48:12 AM
Quote from: pruttelherrie on November 17, 2020, 11:32:26 AM
The Daisy Seed has 24bit converters.
While the Teensy Audio library is a fun thing to play with, the limitations of 16 bit operations make it a no-go for me :icon_sad:
The Teensy is not limited to 16-bit at all. You can you whatever you want for your intermediate processing. Float, double, etc. I use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough. What you are limited to as 16-bit audio TRANSPORT. This means passing audio BETWEEN effects is 16-bit. But within an effect processing bock, you can have as much precision as you need.
ChipAudette even expanded the Teensy audio library to support floating point values as the native transport mechanism, but again, if you think you need more than 16-bit transport between stand alone audio effect blocks you might be making your processing less efficient than it could be for the same result.
You really do not need more than 16-bits for transport.
I didn't say that the Teensy itself was limited to 16 bit.
The audio library works with 16 bit integer DSP (as you state). I followed discussions on the forum where Paul noted that he was not interested in going to 24 bit (unless it could be made downwards compatible, etc), but somehow I missed the ChipAudette library (the same Chip Audette who did a lot of work on STM32duino? [edit]not sure where I got that from?[/edit]). I'd like to tinker with the blocks themselves, but I'm totally lost in integer DSP, so I continued work on a port of the library to the floating-point DSP of ESP32: https://github.com/pruttelherrie/ESP32-A1S-Teensy-Audio
But "too many projects, not enough time" moved that backwards as well.
Quote from: pruttelherrie on November 20, 2020, 01:04:18 PM
Quote from: Blackaddr on November 20, 2020, 11:48:12 AM
Quote from: pruttelherrie on November 17, 2020, 11:32:26 AM
The Daisy Seed has 24bit converters.
While the Teensy Audio library is a fun thing to play with, the limitations of 16 bit operations make it a no-go for me :icon_sad:
The Teensy is not limited to 16-bit at all. You can you whatever you want for your intermediate processing. Float, double, etc. I use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough. What you are limited to as 16-bit audio TRANSPORT. This means passing audio BETWEEN effects is 16-bit. But within an effect processing bock, you can have as much precision as you need.
ChipAudette even expanded the Teensy audio library to support floating point values as the native transport mechanism, but again, if you think you need more than 16-bit transport between stand alone audio effect blocks you might be making your processing less efficient than it could be for the same result.
You really do not need more than 16-bits for transport.
I didn't say that the Teensy itself was limited to 16 bit.
The audio library works with 16 bit integer DSP (as you state). I followed discussions on the forum where Paul noted that he was not interested in going to 24 bit (unless it could be made downwards compatible, etc), but somehow I missed the ChipAudette library (the same Chip Audette who did a lot of work on STM32duino? [edit]not sure where I got that from?[/edit]). I'd like to tinker with the blocks themselves, but I'm totally lost in integer DSP, so I continued work on a port of the library to the floating-point DSP of ESP32: https://github.com/pruttelherrie/ESP32-A1S-Teensy-Audio
But "too many projects, not enough time" moved that backwards as well.
Sorry, I should have been clearer too as I was referring to the Teensy Audio Library itself.. Teensy Audio library is not limited to 16-bits in general. It is only limited to 16-bits for transport BETWEEN effects (AudioPrcoessors), which you shouldn't need anyway if you're doing things efficiently anyway.
People keep asking Paul to add 24-bit support to the library which is pointless here. No codec as SNR ratios that actually use those bits, they are all noise. It just would slow down the all the audio buffer memcpy's.
This discussion is actually a hot topic well outside the Teensy Audio vs. other dicussion. There is lot of eye-rolling going on in the studio DAW audio industry as uninformed consumers demand 24-bit for transport applications. Lots of articles about kind of nonsense:
https://www.mojo-audio.com/blog/the-24bit-delusion/ (https://www.mojo-audio.com/blog/the-24bit-delusion/)
Having > 16-bits is essential for intermediate calculations but you can always dither back to 16bit for transport (either between effects/plugins or for storage)
Right!
Thanks for the elaboration.
The nice thing about 24 bit converters paired with decent preamps is that there's no need to get your gain "exactly right", just be in the ballpark and get going. I still remember late 90's recording with 16 bit ProTools converters and getting the gain right was a b*tch.
[edit] of course, 24 bits is overkill for getting the gain right, just a few more bits would be perfectly fine but in converters they usually jump from 16 to 24...
Also, I just remembered that my QuadraverbGT has 14 bit converters, and sounds just fine with those! [/edit]
QuoteI use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough.
Direct Form topologies really suffer from quantization (amongst other flaws). You could probably use filter designs like trapezoidal-integrated ones, that behave much better in 32-bit floating point at a very low extra-cost. See also the "SVF-vs-DF1.pdf - Noise performance plots" on the Cytomic technical paper page (https://cytomic.com/index.php?q=technical-papers).
Though I sometimes use 64-bit floating-point for non-linear circuit simulation, because the extra accuracy makes the Newton-Raphson iterations converge much faster, even for elementary circuits like R-C-diode clippers. This is particularly true when the signal is strongly clipped.
Quoteof course, 24 bits is overkill for getting the gain right, just a few more bits would be perfectly fine but in converters they usually jump from 16 to 24
Usually digital and software people prefer a number of bits multiple of 8, so we generally go straight to 24 bits when 16 bits are not enough. Anyway codec manufacturers generally describe their chips with usual data like dynamic range, noise floor, SNR, THD, weighted or not, and that's basically all we need.
BTW I would not dither to 16 bits for intermediate calculations (between plug-ins or FX modules) unless constrained by the architecture, because dithering noise can build up and suffer from non-linear processing. It's much safer and probably cheaper to keep the full resolution on the whole path.
About the Daisy Seed, I build a few effects with it and it works great, I'm very happy with it. However the MCU has strong power use spikes contaminating the analog path so it requires a well-filtered power and serious capacitors. This said, if you don't use high-gain effects, it's perfectly acceptable.
When dealing with embedded microcontrollers, you shouldn't be implementing filter topologies manually in your own code(assuming you will be heavily loading your CPU and don't have tons of cycles to spare). You should be using the hardware acceleration libraries for the processor which means you're limited to what they offer you.
In the case of ARM Cortex M's, the M4F and M7 have hardware DSP acceleration for filtering using the CMSIS library. For IIR filters the most processing efficient that they support is Direct Form I and II cascade biquads. If you implement your own filter topology with general software the performance will be terrible by comparison.
https://www.keil.com/pack/doc/CMSIS/DSP/html/group__groupFilters.html (https://www.keil.com/pack/doc/CMSIS/DSP/html/group__groupFilters.html)
Regarding the 16-bits for transport, we're just going to have to agree to disagree. Dithering converts the what would have been truncation error (potentially audible, but still improbably anyway) into random noise. in other words, it raises the noise floor slightly. The noise floor also can only be heard (if at all) during quiet or empty passages. As soon as there is actual sound content, you can't hear the noise anymore in an overall well designed system. E.g. if the total SNR for the whole system, end to end, is better than 60dB you probably think a very high quality, silent system.
Yes, the SNR adds up from any component in the system but the vast majority comes from outside the digital audio path. In other words, accumulating some dithered noise from a dozen effects is going to to be far less than that in the analog part of the system which is subjectable to all kinda of EMI noise and interference. Your accumulated SNR in your 16-bit TRANSPORT paths are going to be probably putting the SNR between 70dB and 80dB. Your actual analog audio path as a whole is probably going to be struggling to meet 60dB SNR. Your standard passive guitar pickups are brutal for SNR from EMI, everything else almost doesn't matter at all.
Again, as above, using higher precision in certain local math calcuations is essential. Using the 32-bit floats for IIR coefficients is going to be way more accurate than 64-bit fixed-point integers but the computation will be way slower. The 64-bit integer CMSIS accelerated biquads are way faster than the 32-bit float accelerated biquads. Using as many bits as you need hear in the fastest computation possible is what good DSP designers do. Slowing down the CPU and memory transfers putting bits where they do give you must return (like as transport between effects) is not a good idea.
By using 24-bit transport when you don't need to on a compute-bound processor means you are using more more RAM, more CPU cycles moving data around, everything gets slower. This is going to potentially reduce how complex your algorithm can be as with embedded audio processing we always seem to need more compute speed. Would you rather have more accurate reverbs and distortion effects due to more compute intensive algorithms, or would you rather trade that for simpler, less advanced algorithms in order to save a few dB of SNR buried so low you can't hear them anyway?
I haven't benchmarked the CMSIS functions vs my own generic code, but you're certainly right. There is nothing fancy in the CMSIS source code (standard instructions and intrinsics, loop unrolling, etc.), so nothing prevents you to implement your own filter topology with the same level of efficiency. In my previous post I just wanted to point that a topology change can be an relevant alternative to higher bitdepth if accuracy is an issue.
I agree that 16 bit may be enough for intermediate steps when you have a firm control on all the levels used in the effect graph. But requiring this control is actually an issue (what pruttelherrie told about setting the gain). And more importantly, if one of the effect is a distortion with a pretty high gain (like 60 dB), the dithering noise is amplified too, becomes annoyingly audible and may cancel all the good work done by a noise gate. Note that even without dithering, sounds at the edge of the quantization (like sounds of fingers holding the strings, or just occasional static noise) become ugly bursts of noise at the end of the chain after a massive amplification.
At present, there is 10% off Daisy using code: ELECTRO10
See offer here:
https://www.electro-smith.com/daisy/daisy (https://www.electro-smith.com/daisy/daisy)
Quote from: Firesledge on November 26, 2020, 12:34:16 PM
I haven't benchmarked the CMSIS functions vs my own generic code, but you're certainly right. There is nothing fancy in the CMSIS source code (standard instructions and intrinsics, loop unrolling, etc.), so nothing prevents you to implement your own filter topology with the same level of efficiency. In my previous post I just wanted to point that a topology change can be an relevant alternative to higher bitdepth if accuracy is an issue.
I agree that 16 bit may be enough for intermediate steps when you have a firm control on all the levels used in the effect graph. But requiring this control is actually an issue (what pruttelherrie told about setting the gain). And more importantly, if one of the effect is a distortion with a pretty high gain (like 60 dB), the dithering noise is amplified too, becomes annoyingly audible and may cancel all the good work done by a noise gate. Note that even without dithering, sounds at the edge of the quantization (like sounds of fingers holding the strings, or just occasional static noise) become ugly bursts of noise at the end of the chain after a massive amplification.
In my tinkering with the line 6 modeler pedals, in particular comparing the amp modeler and distortion modeler to the others, they did a cool, interesting analog front end. They were mono pedals, but used a stereo ADC, one channel was normal, but the signal feeding the other channel had a high gain preamp with some garden variety TS style diode clipping. With the different models the programmer had the choice of the clean input or the amped input, that had much better detail with the quiet parts of the signal.
If you didn't want to sacrifice stereo input, it could be a modest modification to use a general purpose digital output to use an analog switch, like the 4066, to switch in gobs of gain in the preamp for special distortion/high gain digital effects.
Quote from: Processaurus on December 10, 2020, 05:14:44 AM
In my tinkering with the line 6 modeler pedals, in particular comparing the amp modeler and distortion modeler to the others, they did a cool, interesting analog front end. They were mono pedals, but used a stereo ADC, one channel was normal, but the signal feeding the other channel had a high gain preamp with some garden variety TS style diode clipping.
That's really interesting. Given the compute power available back then, I would consider this "hybrid" modelling approach is acceptable if it gives guitars a better quality sound in the end. Kinda cheating though? Maybe?
I can see some reviewer saying it "DSP has really come far. This new digital pedal totally nails the simple diode clipping based distortion pedals."