Welcome to GreenPoint | To DSP program or not to DSP program. That is the question.
348573
post-template-default,single,single-post,postid-348573,single-format-standard,eltd-cpt-1.0,ajax_fade,page_not_loaded,,moose child-child-ver-1.0.0,moose-ver-1.1.1, vertical_menu_with_scroll,woocommerce_installed,blog_installed,wpb-js-composer js-comp-ver-4.7.4,vc_responsive
blog-header

Dilemma!

For GreenPoint TDI, as a control systems software company, we run into this question all the time and we have struggled to effectively solve this dilemma over the years.
Let’s take a look at the parts and pieces necessary to complete a DSP project.

In almost all instances, you will have a DSP program as well as a control system to, in essence, replicate the logic for consumption of various types of graphical devices. The level of which DSP blocks are “unveiled” to the client obviously depends on the scope at hand and the scope that is created with the end users staff. The dilemma of “who will program the DSP” comes into play when you look at the skill sets of the different companies involved. IN 100% of our projects, the control systems programmer does not sell the gear for control, or Audio for that matter. We are not generally “best of breed” audio specialists however we are experts at building code for scale and understanding various manufacturer’s protocols. The audio guys, on the other hand, are experts in sound (or should be if they are selling audio equipment) but, conversely, they are not experts on building software for scale and understanding manufacturer’s protocols. The idea of DSP programming i.e. using logic blocks, like they all do is so an audio guy can follow a signal path and inject processing symbols into the signal flow. This makes complete sense to somebody that is trying to get an audio system up and running who understands that kind of signal flow, but does not make a ton of sense to a control programmer who wants to build efficient code that is scalable and reusable.

So what happens, almost every time?

pointing

Solution!

What can be done about this? The answer for us appears to be quite simple in nature. Split the responsibilities amongst best of breed!

There are really only two parts to writing great DSP software:

1.) Great sound that exceeds the needs of the end users

2.) Efficient, scalable and easy to navigate control software to manage the audio signal flow.

If the control systems software team can shell out and layout the structure of all the necessary blocks and how the signal will be routed and then the Audio guys add processing of their own into the chain, as well as commission the system for ideal sound quality, not only will all parties be profitable, but the end user will get the best DSP experience they can get.

AUTHOR: admin