Where, exactly, do I start?

[Connoisseur of Distortion]

I know almost nothing about DSP. I have a bit of programming experience using the Python language, but i have no idea about the actual design/implementation of DSP. I am a capable builder / problem solver, but this is something waaaay beyond me.

I want to be able to create an algorithm, test it to see if it will work, and ultimately place it in a useable pedal form.

Now, i know from experience that there are bad places to start in computers (i started on liberty BASIC... bad choice!) and i want to learn this right. You guys know this stuff much better than I, and you also know where pitfalls will come from. Can anyone point me towards sites that will give me a strong editor (i can usually get through gotchas, so don't worry about it being too advanced), tell me how to get started, and can help me place these created algorithms into boxes for real time use?

Thanks everyone, I think this new sub-forum is a step in the right direction!

[idiot savant]

I think I'm pretty much in the same boat as you. I'm looking into the Wavefront route. Maybe one of the development boards. They're a little pricey though. there are several code samples on the site, and it doesn't look THAT difficult.(speaks too soon)

Haven't been this excited in awhile, This is a whole new realm to me. The potential for DSP is great.

I'm going to put together the Femtoverb right away.

[David]

Easy, guys.  We've got to do this thing in steps.  We need to crawl before we can walk.

Peter / Andrew / Aron:

Let's get this effort to coalesce so we can get it moving.  I understand that Peter and Andrew have preferences for the Atmel chips.  However, R.G. has already created designs around PICs.  There are also other PIC projects out there.  I'm gonna stick my neck out again and shoot my big mouth off and suggest the following:

For our "square one" project, let's light up the LED using a PIC16F628.  We don't HAVE to have development boards to use PICs.  Just a breadboard and a regulated 5V power supply.  16F628s are cheap.  Real cheap.  We can get project information from:

http://www.sparkfun.com/commerce/present.php?p=BreadboardTut  (setting up a breadboard to handle a PIC)
http://www.sparkfun.com/commerce/present.php?p=Microcontroller%20Implantation (connecting the PIC)
http://www.sparkfun.com/commerce/present.php?p=Magic (coding)

For doing something "real", let's do that top-octave generator R.G. referred to.  It's discussed in a thread on Moog Taurus pedals.

As for the "PIC"ked Switch,  I'm out of my league.  Andrew, I guess this will be where we have to switch over to AVRs.

[The Tone God]

Easy, guys.  We've got to do this thing in steps.  We need to crawl before we can walk.

Agreed but Dude, chill. Your spazing a bit.

If we are going to do this together then we all need to be on the same page. Jumping around platforms and languages is not a good idea. There are few advantages to it and MANY disadvantages.

This is the way its going to go down.

Platform: Atmel AVR 8-bit RISC
Processor: Tiny13
Kit: Atmel STK500
Lanuage: Embedded C
Software: AVRStudio for editing, emulation, and programming. WinAVR for the C compiler.

This is a VERY good setup for a beginner IMHO. Others with experience can comment if they wish. This setup should cost at the most $100 for the hardware. The software is free. If someone wants to deviate from this and learn something else then they are on their own.

Andrew

[David]

I bow to your superior expertise, your T.G.-ness.  Consider me appropriately humbled and chastised...  NOT!
We'll do it your way ... for now.

[The Tone God]

I bow to your superior expertise, your T.G.-ness.  Consider me appropriately humbled and chastised...

Its T.T.G. not T.G. Now you have appropriately chastised.

Andrew

[David]

Easy, guys.  We've got to do this thing in steps.  We need to crawl before we can walk.

Agreed but Dude, chill. Your spazing a bit.

If we are going to do this together then we all need to be on the same page. Jumping around platforms and languages is not a good idea. There are few advantages to it and MANY disadvantages.

This is the way its going to go down.

Platform: Atmel AVR 8-bit RISC
Processor: Tiny13
Kit: Atmel STK500
Lanuage: Embedded C
Software: AVRStudio for editing, emulation, and programming. WinAVR for the C compiler.

This is a VERY good setup for a beginner IMHO. Others with experience can comment if they wish. This setup should cost at the most $100 for the hardware. The software is free. If someone wants to deviate from this and learn something else then they are on their own.

Andrew

Oh, great tT.G. ness!  This is the "spaz" speaking again...
Is this the same platform and software that Sensei Snowberg has been referring to?  I mean, if we're gonna standardize and all...
<Runs before lightning bolt can strike>

[The Tone God]

Is this the same platform and software that Sensei Snowberg has been referring to?  I mean, if we're gonna standardize and all...

Depends on which platform Sifu Snowberg recommended you are refering too. If you take a look a this thread:

http://www.elixant.com/~stompbox/smfforum/index.php?topic=42360.0

you will notice that he does recommend the samething for uCs as I am.

<Runs before lightning bolt can strike>

Ah thats not me. Thats somebody else. I won't say who but I'm suppost to "do lunch" with them (their words not mine) sometime this week. I gotta talk to them about few things in regards to that whole world peace thing I keep pushing.

Andrew

[troubledtom]

Easy, guys.  We've got to do this thing in steps.  We need to crawl before we can walk.

Agreed but Dude, chill. Your spazing a bit.

If we are going to do this together then we all need to be on the same page. Jumping around platforms and languages is not a good idea. There are few advantages to it and MANY disadvantages.

This is the way its going to go down.

Platform: Atmel AVR 8-bit RISC


andrew is 100% right!!!!!!
    peace,
        - tom
Processor: Tiny13
Kit: Atmel STK500
Lanuage: Embedded C
Software: AVRStudio for editing, emulation, and programming. WinAVR for the C compiler.

This is a VERY good setup for a beginner IMHO. Others with experience can comment if they wish. This setup should cost at the most $100 for the hardware. The software is free. If someone wants to deviate from this and learn something else then they are on their own.

Andrew

[Peter Snowberg]

We have lots of folks here who have worked with both AVRs and PICs. I think there is plenty of room for both in effects land.

For a getting started in programming course, there are a whole bunch out there for any platform you would like. I recommend that once people become familiar with one platform they should check out the rest of the options out there. Each family of parts has strengths and weaknesses.

For the getting started articles around here, we must use what the authors want to use.  After all it's their choice.

For the microcontroller stuff, there are multiple people who are wanting to use the Atmel STK500 so that makes a natural choice. It's a really great platform too.

As for the uC we focus on, Sensei Andrew-san has selected a WONDERFUL chip IMHO.

[R.G.]

kewl... we'll all write our own introductions and lessons... 

[Peter Snowberg]

kewl... we'll all write our own introductions and lessons... 

The more, the merrier!

I would LOVE to see PICs and AVRs covered in parallel. Both families are great products that do amazing things.

[R.G.]

OK, start the Atmel/AVR stuff with this:
http://www.xdesignlabs.com/guide/index.html

[The Tone God]

kewl... we'll all write our own introductions and lessons... 

I would love to see as many other platforms covered. We may even want to come up with a common lesson format for each platform for consistency and comparision sake but that would be up to those preparing lessons.

I thought about doing something like this for a few years now but I would become apprihensive about the matterial. Truth be told I still am. I have/had concerns that this forum would be become populated with questions about "How do I make an pin input ?" and "Whats the difference between a char and int ?" which really are not what this forum is for.

As I am starting to lay lessons/articles out I'm having to decided what to cover and what to leave out. I don't want retread the old "stick the uC in to the socket" material as that has been done before. Nor do I want to spend time teaching C / embedded C per se. Those getting into this should have a fairly high level ability of independant learning. I really want to just get the point and talk about uC use in effects.

Andrew

[R.G.]

I thought about doing something like this for a few years now but I would become apprihensive about the matterial. Truth be told I still am. I have/had concerns that this forum would be become populated with questions about "How do I make an pin input ?" and "Whats the difference between a char and int ?" which really are not what this forum is for.

I think you may be disappointed. The "how do I make a pin an input?" stuff is inevitably going to be a big part of what happens here. Even if it is not at first, it will be as new people join who have not read the first material. It's simply going to happen.

As I am starting to lay lessons/articles out I'm having to decided what to cover and what to leave out. I don't want retread the old "stick the uC in to the socket" material as that has been done before. Nor do I want to spend time teaching C / embedded C per se. Those getting into this should have a fairly high level ability of independant learning. I really want to just get the point and talk about uC use in effects.

Again, I think you're doomed to be disappointed. The range of programming backgrounds here is huge. I've done so much of it I don't care what language is to be used. Others can quote C in their sleep. There are many people with questions like " Kewl! A microcontroller. Can I just run audio into any pin?" and those who don't know what a modern language looks like.

There are several major hurdles to be overcome.
(a) the concept of programming; many have done NO programming, so explaining what syntax is and why it has to be followed is going to be a major concern. The lure of using programming to make effects becomes a hook to reel in those that have resisted learning programming otherwise. As you might guess, some of these also have little aptitude for it, or they'd have tried it earlier in their lives. But they're going to be here. Frankly, that's the big reason I'm thumping the tub for BASIC. I know that there are so many references for learning BASIC that I don't have to feel guilty telling someone to go read it and come back when they need a pointer, not a lesson in the theory of programming. C's great, but it's not where to start someone who doesn't know structured languages from Inuit.
A corrolary is
(a1) the idea of putting digital electronics down on a PCB and getting it to work. Digital debugging is both easier and much more complicated than analog. All of the old analog hangups transfer over, and yes, putting the uC in the socket properly will bedevil those who've never quoted DeMorgan's Theorm before.
Once you're over that, you'll run into
(b) Teaching C to those that don't know it, teaching embedded C to those who know unlimited C, and dealing with how C the abstract language gets restricted down and unrestricted up to manipulating the bare iron for I/O on a uC, as well as doing the right-down-to-the-bare-metal stuff to get the uC's I/O to work. Packaged libraries are great, but elegant work on a uC won't live with that restriction.

Until you can get people to quit asking about those, you can't really get down to how clever the uC apps are.

We might even need a separate forum for each of
1. Introduction to programming
2. Programming in embedded C
3. Prototyping digital logic

Without that, the environment will rapidly condense down to people who already know most of it - that's you, me, and a few others - or will drown in beginner questions. After all, this is for the beginners. Or should we have an entry exam for getting access to the DSP/Digital forum?

[Peter Snowberg]

Lots of good points there.

I don't think we need an exam, so much as a "start here" post with links to other web resources. It doesn't make much sense to duplicate what so many other have already done, unless we can do something along the way to make it more applicable to the effects world.

Giving some basic lessons with the effects angle is a good thing I believe. People can see similar examples in other applications, but now there is a frame of reference established that says, "OK, if we want to build boxes around this stuff, this is how it is different."

When it comes to "how do I make an I/O pin... questions", I think we can refer most people to other sites to get more background, once they have that, they should be able to digest the articles here.

[Connoisseur of Distortion]

peter has it. Send links for people to read and study on their own time... like me!

i built my first DIY pedals completely independent of the forum. I thought i was rummaging over old ruins of websites before, because I was studying schematics that didn't appear to be maintained or updated. It was VERY HARD to get that first electra distortion built, because I didn't even have an understanding of soldering at that point.

I am no stranger to private study, but I want to get this right. All i really need is stuff telling me where to get things, how to use them, and maybe a few sample projects.

also, a consensus on the stuff to use would be cool... 

thanks, guys, for putting up with the silly questions.

[The Tone God]

I think you may be disappointed. The "how do I make a pin an input?" stuff is inevitably going to be a big part of what happens here. Even if it is not at first, it will be as new people join who have not read the first material. It's simply going to happen.

Perhaps I wasn't being clear or atleast not specific enough. My concern awhile ago was that these types of questions were going to be leaking into the general forum and cause possible problems which could have effectively been my fault. I did not want to cause that. Now that this area has been created I'm not as concerned about it, well other then the possible extra work for Aron and Peter to move and moderate threads when need be.

Another reason I did not go forward awhile back is that there are plenty of resources available to learn about uC. What there is lacking is how to use them in effects which is where I believe we should come in. I share the same opinion of others. Those asking the "how do I make a pin an input?" questions can be directed to other resources.

I have no idea who is involved in what around here or what they are planning on doing but I get the sense that our small group here are going to be the initial guru/sensi/sifu of a particular speciality that each of us has to offer. You have PICs and I believe BASIC. Peter has AVR, assemble, and DSP. I have AVR and embedded C, and so forth. So for now when someone has a question on a specific topic it will probably end up being that person to step up and field the question. It will probably be touch and go at first and it might even fall flat on it's face but for me I always like going against the grain. Atleast I can say I gave it a kick instead of sitting on my ass watching it fail. Thats just me.

Andrew

[varialbender]

I saw this new section, and havn't popped in until now. I'm gonna have to read every single post on here tomorrow to get caught up.
I'm still a complete n00b to circuits, but hopefully I'll be able to keep up without being tooooo annoying.
I'm specializing in DSP for EE, and am still in my second year, and have learned nothing compared to what I've learned on here.
I've learned some different languages, like Java, C, and some low level stuff on the ARM, so that's gonna help a lot.
You guys seem so tight that I always hate asking questions, as they've all been answered before, but hopefully I'll be able to grow more into this section.
Looking forward to these lessons.

[gaussmarkov]

i think this whole project is another HUGE gift. 

Code Select Expand

#include <iostream>

int main()
{
    std::cout << "thank you!\n";
}