<div dir="ltr">Here are some random thoughts. Unless things have changed or are different with higher end sharc dev boards, I'm not sure you will get audio ins and outs that are acceptable for musicians, especially after you've gone through all the trouble to be able to use long and well made IRs, ie, think of nice reverbs where tails are really important. That means creating your own PCB, effectively increasing the total time to bring it to a useful tool that is plug and play, not only the time spent on learning and implementing the algorithms.<div><br></div><div>That said, my feeling is that whoever implements these smarter approaches to convolution on a sharc platform and shares it will be eternally loved by the community. And once this happens likely others with hardware know how will chime in. That's a short step away from a sharc aleph-like.</div><div><br></div><div>An axoloti/nord-modular like interface and philosophy featuring really good building blocks exploring a powerful DSP platform would be amazing. Great for people wanting to develop their own DSP ideas but also with potential to be poor man's kyma. </div><div><br></div><div>cheers</div><div>b</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 13, 2017 at 8:49 AM cheater00 cheater00 <<a href="mailto:cheater00@gmail.com">cheater00@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr" class="gmail_msg">It should also be said that the naiive algorithms have quadratic runtime complexity whereas the best ones have much better complexity (I believe n log n), so longer reverb tails that can be done with the optimized algorithm are simply not possible with the naiive approach, no matter how much hardware you throw at it - so that might be another reason to spend the time.</p>
<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, 13 Feb 2017 14:40 cheater00 cheater00, <<a href="mailto:cheater00@gmail.com" class="gmail_msg" target="_blank">cheater00@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr" class="gmail_msg">The simplest FFT and convolution algorithms are easy to understand in just hours, the really complex algorithm could take weeks to implement, so if you're just doing this for yourself the break even point is: will you otherwise earn $200 - the difference between a dev board with the cheapest DSPs and most powerful ones - in those several weeks? If not, you might want to look into, uh, flipping burgers or pizza delivery as a career move. If you are doing this for production, or for other people to build themselves, you want something relatively inexpensive, though. The dev time might be warranted if you do not mind spending it as a learning experience.</p>
<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, 13 Feb 2017 10:38 Thomas Strathmann, <<a href="mailto:thomas@pdp7.org" class="gmail_msg" target="_blank">thomas@pdp7.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/02/17 22:39, <a href="mailto:rsdio@audiobanshee.com" class="gmail_msg" target="_blank">rsdio@audiobanshee.com</a> wrote:<br class="gmail_msg">
> So, when combining FIR and FFT processing for convolution, you'll<br class="gmail_msg">
> need MAC, bit-reversed addressing, automatically-wrapped buffer<br class="gmail_msg">
> pointers, and possibly other special instructions for maximum<br class="gmail_msg">
> efficiency at a given instruction clock rate. Hopefully the DSP you<br class="gmail_msg">
> choose will have example code in optimized assembly for a partitioned<br class="gmail_msg">
> convolution, and you won't have to piece all of this together<br class="gmail_msg">
> yourself. Yes, you could do it all in Standard C on a general purpose<br class="gmail_msg">
> ARM or XMOS, but you'll need a higher clock rate and more code to do<br class="gmail_msg">
> the same amount of work.<br class="gmail_msg">
<br class="gmail_msg">
I'm wondering: How precious would development time hav to be to warrant<br class="gmail_msg">
going with a DSP and optimized assembly code instead of taking the more<br class="gmail_msg">
blunt approach with a fast CPU and some plain C code? From following<br class="gmail_msg">
this discussion I get the impression that the answer to that question is<br class="gmail_msg">
"Very" but is that true?<br class="gmail_msg">
<br class="gmail_msg">
        Thomas<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Synth-diy mailing list<br class="gmail_msg">
<a href="mailto:Synth-diy@synth-diy.org" class="gmail_msg" target="_blank">Synth-diy@synth-diy.org</a><br class="gmail_msg">
<a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" class="gmail_msg" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br class="gmail_msg">
</blockquote></div></blockquote></div>
_______________________________________________<br class="gmail_msg">
Synth-diy mailing list<br class="gmail_msg">
<a href="mailto:Synth-diy@synth-diy.org" class="gmail_msg" target="_blank">Synth-diy@synth-diy.org</a><br class="gmail_msg">
<a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" class="gmail_msg" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br class="gmail_msg">
</blockquote></div>