18 Nov
2004
18 Nov
'04
11:46 p.m.
Mark Knecht wrote:
On Thu, 18 Nov 2004 18:19:45 -0800, Brad Fuller
<brad(a)sonaural.com> wrote:
Sure - that's a fair comment and a design decision once some project
like this gets started. I just brainstorming. However, even with an
onboard DSP, which is most likely what Pro Tools does, we'd still need
to map from LADSPA C code to DSP code. Is that easy?
I would think it's easier than mapping gates.
I have not ever looked at LADSPA code. I assume most people write in C.
Today's DSPs, even 10 years ago, have a full compliment of C programming
tools. Bingo.
Of course, the goal would be to strike a proper balance with making it
easy and cheap to design and mfr with making it easy and inexpensive for
the end user. From what I've read, that is your profession! I have
always said that engineering is an exercise in compromise ;-)
It would be a cool and fun project!
Have you seen plugzilla or receptor?
http://www.plugzilla.com/overview
http://www.museresearch.com/receptor_overview.php
Kinda what you're talking about?
I think they created a VST wrapper to run in Linux. I would bet the
creators of one or both of these products visit this site.
brad
Mark Knecht wrote:
Instead of
a $400 2 channel PCI card we might end up with a $600
16-in/16-out device with hardware signal processing on board. To me
this is probably a better place to go. If we do all this work ten we
want to start working towards an architecture that will last.
Taking ladspa and mapping it to FPGA: how? and how would you do this
efficiently, if you could do it? A C function to VHDL function
convertor? (it's been a long time since I've worked with FPGAs. I'm sure
there are advances)
It might be more cost effective to use DSPs -- that is: more cost
effective in the long run for everybody -- mostly the end user.
brad