[sdiy] Programming Language Recommendation

Tony Sidaway tonysidaway at gmail.com
Sat Dec 5 23:29:34 CET 2020

All excellent points. Faust does compile down to C, but that doesn't solve
every problem. The reason I'd try Faust is because I wanted to use a high
level language. But bugs can strike at any point in the software stack and
a high level language can quickly become a liability.

On Sat, 5 Dec 2020, 21:36 Brian Willoughby, <brianw at audiobanshee.com> wrote:

> I've not used Faust for any embedded firmware design, so I won't comment
> on that language, per se, other than to point out that it violates the KISS
> principle.
> Any additional technology is a potential source for unique problems. If
> you don't use Faust, then you can't have any problems that are due to Faust.
> My single most important driving factor in choosing a language for
> firmware development is: *support from the chip vendor.*
> I've designed many products right at the edge of what an embedded
> processor can handle, and when I uncover a hardware issue that the vendor
> hasn't seen before, they invariably want to see source code that runs on
> their standard evaluation hardware so that they can reproduce the bug and
> suggest a solution. Admittedly, it's already difficult when designing a
> custom audio or musical controller hardware platform that's unique, because
> you can't exactly send a prototype to the chip vendor for bug repro. For
> this reason, I stick to standard C and leverage the vendor libraries unless
> performance demands custom code.
> I had one hardware DSP project with full bandwidth USB isochronous
> streaming, and managed to reproduce a bug on the standard evaluation board.
> However, the isochronous USB client only ran on macOS (because Windows at
> the time required a kernel driver to handle isochronous traffic), and the
> vendor could not reproduce the bug *because nobody there had a Mac*!
> I'm telling you that you don't want anything unique about your design if
> you want to push the limits and get support from the vendors. I can't
> imagine an MCU vendor setting up a Faust tool chain to help repro a bug
> report...
> Brian
> On Dec 5, 2020, at 12:01, Tony Sidaway <tonysidaway at gmail.com> wrote:
> > We're straying rather too close to religious matters, I fear. By far the
> most important factor in choosing a language is the purpose you'll use it
> for. In that decision, access to library code features highly. This is one
> of the reasons I suggest that those seeking a combination of high level
> language and powerful signal processing features could do worse than
> examine Faust.
> >
> > It's a highly portable high level language and it'll run just about any
> collection of DSP algorithms you can name right out of the box, in any
> combination and with very concise textual code which can also be
> graphically visualised in a manner comparable to Pure Data. It's a bit of a
> memory hog but modern boards like those based on ESP-32 will run it well.
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20201205/bed1da4a/attachment.htm>

More information about the Synth-diy mailing list