Professional Exams for Digital Signal Processing!?

"Brian Byrne" <brian.byrne23@mail.dcu.ie> wrote in message
news:rTjBi.611$9V2.397@amstwist00...
> Thanks for that information.
>
> Ideally , I want to program computers using DSP techniques for Audio and
> video games.

Ha Ha. One of the most crappy jobs that one can imagine.

1. Digging through the piles of bad dasheets: "program the chipset register
C3H12K8-2 with the value from the register B5_main_INDEX. Note that bit7
represents the inversion of the direction, whereas bit6 corresponds to the
direction of the inversion." So on, so forth.

2. Resolving all sorts of software and hardware compatibility problems. "If
the MS security patch KB423893490 was applied, the game can cause the
invalid page fault in the driver foobar_acm.vdx. If you are experiencing the
problems, please reinstall Windows Vista".

3. Working in the disgustful environment of a big company ruled by sales and
marketing.

4. Never doing anything new. Dumb coding of trivial algorithms.


Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com

Richard Owlett wrote:

> In my VERY personal opinion the IEEE got too fascinated with academic 
> credentials. The result is a registered PE is qualified to build bridges 
> but need never have used an IC.

What would you expect? These organisations are controlled by academics, 
and exist for the purpose of promoting their ends. In the late 70s and 
early 80s in the UK there was a lot of fuss along the lines of "how come 
the UK has so many Nobel laureates, yet can't turn any bright ideas into 
successful industries". There was a strong feeling scientists and 
engineers were becoming too blue sky in their ways, and not sufficiently 
pragmatic about making useful stuff. The IEE deliberated on this point, 
to adjust its requirements for Chartered Engineer status. The result was 
to raise the academic bar, and nothing else.

Steve

On 29 Aug, 21:34, "Brian Byrne" <brian.byrn...@mail.dcu.ie> wrote:
> Thanks for that information.
>
> Ideally , I want to program computers using DSP techniques for Audio and
> video games.
>
> Based on you information, I think its worth while to consider the whole DSP
> area as two components:
> 1.) Theory of signals & System , DSP Processing techniques, programming DSP
> concepts

I might agree...

> via Matlab.

No way. I have no reason to suggest there was any malice
involved when the mathworks designed their signal processing
toolbox in ancient pre-history, but they did a poor job.
Whenever I encountered students who knew DSP from
matlab, I had a hard time de-teaching that stuff out of them
so I could teach practical DSP.

> 2.) Actual programming of DSP devices , FPGA, & ASIC's based on fundamentals
> in point 1.

If you try this based on a basis gained vi amatlab, you are
a lot worse off than starting straight on without any prior training.

Rune

On Aug 30, 3:19 am, "Vladimir Vassilevsky"
<antispam_bo...@hotmail.com> wrote:
> "Brian Byrne" <brian.byrn...@mail.dcu.ie> wrote in message
>
> news:rTjBi.611$9V2.397@amstwist00...
>
> > Thanks for that information.
>
> > Ideally , I want to program computers using DSP techniques for Audio and
> > video games.

Is that Audio within computer games? Or audio in some field, and video
games?

I take it you meant the former; audio within games. Then welcome to my
world :) But there's not a whole bunch of dsp that goes on, especially
as many of the consoles used in games aren't up to the job. Perhaps
the PS3? However, the company I work for are reserving judgement on
that platform for the time being, at least until sales of the thing
pick up from current levels. Perhaps things will improve for that
platform if some decent games started appearing for the thing.

> Ha Ha. One of the most crappy jobs that one can imagine.

Really? Is that from first hand experience? If so, then I'm sorry it
didn't work out for you!

I consider myself rather lucky to work within an audio department of a
games company. I've had some crappy jobs within the computing
industry, but this aint one of 'em! Yesterday we spent most of the
morning creating a bank of guitar sounds via Native Instrument's
Guitar Rig. I then spent the afternoon creating a vst that would fire
off those sounds via midi events from Cubase. Great fun. Today I've
got to start looking at moving midi event handling code into a
seperate thread so that we can improve the timing resolution.
Basically, my work is varied and fun.

My advice would be to become a decent Software Engineer. As Jerry
says, pay attention to detail and stick to good principles as this
will set you apart. Do the maths, since that will make you a better
engineer; I consider computer programming to be a subset of the
general problem solving methods applied via maths, but if you want to
do DSP specifically then you're going to need trigonometry, calculus,
complex number theory and probably a whole bunch of other stuff. Get
yourself a general appreciation of audio; perhaps learn to play
guitar, and learn how to drive a mixing desk. Just immerse yourself in
all things audio so that you can communicate with audiophiles. Then
bring your technical skills to the field.....

If you want to do a course, then I think there are quite a few Masters
courses in DSP (Queen Mary, Southampton) and Music Technology (City,
York) that you might find worthwhile.

I hope that helps.

Rune Allnor <allnor@tele.ntnu.no> wrote in news:1188451007.296145.109460
@r29g2000hsg.googlegroups.com:

> Whenever I encountered students who knew DSP from
> matlab, I had a hard time de-teaching that stuff out of them
> so I could teach practical DSP.
> 

You don't KNOW DSP from Matlab, you learn DSP, and you implement it in 
Matlab. I learned DSP, implemented much of it with my own code in ASYST, 
and some years later started doing work in Matlab-- and it was tons easier.

So, can you give any good examples of how the Matlab signals toolbox (or 
base system) conceptually screws up DSP?  I know that there's a small issue 
with how Matlab scales ffts that's off the "regular" definition by a factor 
of N or something like that, but its small.  I trust you're not going to 
start a tirade about zero-indexing.

If you mean that owning matlab and the signal processing toolbox does not 
imply that you have all the conceptual tools necessary to use and 
understand DSP techniques, I fully agree.

-- 
Scott
Reverse name to reply

Richard Owlett <rowlett@atlascomm.net> wrote in 
news:13dbpjsb8gd5vea@news.supernews.com:

> In my VERY personal opinion the IEEE got too fascinated with academic 
> credentials. The result is a registered PE is qualified to build bridges 
> but need never have used an IC.


Boy, I'm just not seeing the link between building bridges and academics.  
An academic with no practical experience isn't qualified to build a bridge.

I get your point, but your example is off the mark.


-- 
Scott
Reverse name to reply

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:1188451007.296145.109460@r29g2000hsg.googlegroups.com...
> On 29 Aug, 21:34, "Brian Byrne" <brian.byrn...@mail.dcu.ie> wrote:
> > Thanks for that information.
> >
> No way. I have no reason to suggest there was any malice
> involved when the mathworks designed their signal processing
> toolbox in ancient pre-history, but they did a poor job.
> Whenever I encountered students who knew DSP from
> matlab, I had a hard time de-teaching that stuff out of them
> so I could teach practical DSP.
>
> > 2.) Actual programming of DSP devices , FPGA, & ASIC's based on
fundamentals
> > in point 1.
>
> If you try this based on a basis gained vi amatlab, you are
> a lot worse off than starting straight on without any prior training.

Agreed.
Matlab is for the trivial scholar problems. Archimedes, Newton and Einstein
perfectly dealt without Matlab.

VLV

On 30 Aug, 14:20, Scott Seidman <namdiestt...@mindspring.com> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in news:1188451007.296145.109460
> @r29g2000hsg.googlegroups.com:
>
> > Whenever I encountered students who knew DSP from
> > matlab, I had a hard time de-teaching that stuff out of them
> > so I could teach practical DSP.
>
> You don't KNOW DSP from Matlab, you learn DSP, and you implement it in
> Matlab.

These days students "learn" "maths" in terms of what matlab can and
can not do.

> I learned DSP, implemented much of it with my own code in ASYST,
> and some years later started doing work in Matlab-- and it was tons easier.

That's similar to what I did too; I used pascal and C, not ASYST. Not
many
people do things in that order these days.

> So, can you give any good examples of how the Matlab signals toolbox (or
> base system) conceptually screws up DSP?  

Anything where order is derived from the design or estimated
during processing. When I first was aquainted with the SP toolbox
(mid -90s) the order was a parameter to the filter design functions.
That may have changed recently; I don't know.

Music requires the number of sinusoidals present as a parameter,
the Yule-Wlaker solvers, Levinson recursion etc requires the
oredr as a parameter; all these algorithms are far better used
if you use a *maximum* order, and an order estimator as a
termination criterion inside the various recursions.

Rune

Scott Seidman wrote:
> Rune Allnor <allnor@tele.ntnu.no> wrote in news:1188451007.296145.109460
> @r29g2000hsg.googlegroups.com:
> 
>> Whenever I encountered students who knew DSP from
>> matlab, I had a hard time de-teaching that stuff out of them
>> so I could teach practical DSP.
>>
> 
> You don't KNOW DSP from Matlab, you learn DSP, and you implement it in 
> Matlab. I learned DSP, implemented much of it with my own code in ASYST, 
> and some years later started doing work in Matlab-- and it was tons easier.

Youngsters. Huh. In my day we built DSP systems from the gate level up. 
And, no namby pamby modeling tools to try it out first. :-)
> 
> So, can you give any good examples of how the Matlab signals toolbox (or 
> base system) conceptually screws up DSP?  I know that there's a small issue 
> with how Matlab scales ffts that's off the "regular" definition by a factor 
> of N or something like that, but its small.  I trust you're not going to 
> start a tirade about zero-indexing.
> 
> If you mean that owning matlab and the signal processing toolbox does not 
> imply that you have all the conceptual tools necessary to use and 
> understand DSP techniques, I fully agree.

Steve

On 30 Aug, 16:09, Steve Underwood <ste...@dis.org> wrote:

> Youngsters. Huh.

Well, opinions are divided on that particular matter.
Not long ago I was told I am half-antique; I was born
before Armstrong walked on the moon...

Rune