[sdiy] Hardware convolution box?
Frédéric (Opensource)
marzacdev at gmail.com
Mon Feb 13 17:34:11 CET 2017
Hi everyone,
I see you discussing this topic (the convolution box) for quite
a while now, but my stupid and naive question is, what do you
need this system for?
I mean, is it only for reverb or rooms simulations?
Or do you want to model some amps or other gear (like the
Kemper Profiling thing does)?
Because I personally see convolution approaches as very
inefficient methods (in terms of computing resources) when it
comes to model a certain system response.
Musically,
Frédéric
PS: Not trolling the list, just curious.
Le 13/02/2017 à 17:18, cheater00 cheater00 a écrit :
>
> Hi Bruno,
> TBH for a single instrument you don't need amazing adc or dac, but
> there are lots of i2s adc and dac boards out there geared for hifi
> enthusiasts. Some are cheap, and work well. Some are great quality,
> and you can spend as much as you want, really.
>
>
> On Mon, 13 Feb 2017 17:03 Bruno Afonso, <bafonso at gmail.com
> <mailto:bafonso at gmail.com>> wrote:
>
> 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.
>
> 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.
>
> 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.
>
> cheers
> b
>
>
> On Mon, Feb 13, 2017 at 8:49 AM cheater00 cheater00
> <cheater00 at gmail.com <mailto:cheater00 at gmail.com>> wrote:
>
> 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.
>
>
> On Mon, 13 Feb 2017 14:40 cheater00 cheater00,
> <cheater00 at gmail.com <mailto:cheater00 at gmail.com>> wrote:
>
> 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.
>
>
> On Mon, 13 Feb 2017 10:38 Thomas Strathmann,
> <thomas at pdp7.org <mailto:thomas at pdp7.org>> wrote:
>
> On 12/02/17 22:39, rsdio at audiobanshee.com
> <mailto:rsdio at audiobanshee.com> wrote:
> > So, when combining FIR and FFT processing for
> convolution, you'll
> > need MAC, bit-reversed addressing,
> automatically-wrapped buffer
> > pointers, and possibly other special instructions
> for maximum
> > efficiency at a given instruction clock rate.
> Hopefully the DSP you
> > choose will have example code in optimized assembly
> for a partitioned
> > convolution, and you won't have to piece all of this
> together
> > yourself. Yes, you could do it all in Standard C on
> a general purpose
> > ARM or XMOS, but you'll need a higher clock rate and
> more code to do
> > the same amount of work.
>
> I'm wondering: How precious would development time hav
> to be to warrant
> going with a DSP and optimized assembly code instead
> of taking the more
> blunt approach with a fast CPU and some plain C code?
> From following
> this discussion I get the impression that the answer
> to that question is
> "Very" but is that true?
>
> Thomas
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org <mailto:Synth-diy at synth-diy.org>
> http://synth-diy.org/mailman/listinfo/synth-diy
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org <mailto:Synth-diy at synth-diy.org>
> http://synth-diy.org/mailman/listinfo/synth-diy
>
>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20170213/02913cdb/attachment.htm>
More information about the Synth-diy
mailing list