DSP Robotics Support

I work with people from time to time, and what I've learned is this. No matter how I shine with my knowledge and sophisticated details - there must be some hierarchy, fragmentation and directionality of what I have to say to others. Otherwise - no matter how wise and smart it sounds - I can't make that person to follow the idea I have to share; (yup, scientific books are cool - you can read them again and again, because each time you forget most of it ).

So I usually split the context into input/output example (how you can get what you want + why you want to get it first), and then, if needed, step by step - unfold the background. It's like knowing something, and for the rest - reaching to wiki or something like that.

Explaining - at least in my view - should be like SM/FS programing. Modular, visual, intuitive. On second place is the flow and know how (despite the fact, that the flow is the core; it's the core of environment, and not programmer).

One thing I did noticed with programming - it affects the ability to smoothly communicate with verbal words. It's not the english or whatever, but the natural thinking and experiencing process, that is exchanged into FS-like internalization. After several hours of work - I'm not able to digest a text longer than few lines, that why I feel the need for simplicity. After these hours of work - I'm no better than my computer. Cognitive neuroscience vs visual dataflow programming.

tester wrote:One thing I did noticed with programming - it affects the ability to smoothly communicate with verbal words. It's not the english or whatever, but the natural thinking and experiencing process, that is exchanged into FS-like internalization.

Couldn't agree more, as pointed out just a few days ago...

philton wrote: from now on i definitly think trog is a computer with VERY well programmed human skills

(though I'm not so sure about "VERY well programmed"!! )
That's what comes of being a programmer for 25 years, I guess - and until joining the SM forum only a few years ago, with very little communication with other programmers. So you make a good point I think; the thinking process it too much like the machine to make the transition to a more humanly readable explanation. Better for helping an experienced programmer with a troublesome schematic than for teaching first principles, for sure.

tester wrote:Modular, visual, intuitive.

A better way to collate the information would help here I think - the immediate "call and response" format of the forum makes it more difficult to deal with these things in a structured way. Tutorials get broken up by other posts, and good examples become hard to search for.
I feel I have done a better job in the past with patiently considered .pdf presentations etc. - but that is just so time consuming to put together. Likewise with visual presentation - I find step by step video tutorials to be one of the most effective on-line learning tools, but again they are very laborious to construct.
If DSPr could be successful enough to employ another worker, I'd strongly suggest to them that the education aspect should be made a priority - it requires a trained person employed for many hours to do a really good job of it.

'Intuitive' is a tricky one, as that is so different for every person. I have had to be trained to observe and use body language and eye-contact because to me they were not intuitive - quite possibly why I get on so well with computers; a human may invert the meaning of their words with little more than a change in vocal timbre, whereas computers deal only in literal meaning. (No violins required - thanks to some great therapists, I lead a very fulfilling existence!).
A greater body of users of varying capabilities would help, so that more natural combinations of tutor/student can be found that work well together. Some "theorists" who can deal with advanced problems will always be useful to have around - but I feel we do need some people here who are more talented in "translating" the valuable information into something easily digestible - and somewhere tidy to put the lessons they produce!

By "intuitive" I mean something like what happens when you work with SM/FS. You just put correct things together before you start to think on "how it works". This is the "flow" aspect of visual programming, literally like playing with lego blocks. Trouble begins with ambiguous things or math formulas for filters (if you have to build them on your own) for example. Some time ago, I had a problem with certain math formula. I read it and read it and read it, and there were too many tiny symbols and elements connected with each other. So instead of processing these things mentally, I split it in a SM/FS way, made a schematic and had that "aha" moment of understanding. Usually what matters here, is what you put in, what you setup, and what you get out of it.

I'd agree up to a point. The maths is not my strong point either - the difference is that, with my programming experience, I can understand it once I see an example code. Even if it's in a different programming language, I can usually get close enough for trial and error to complete the job.
Like you, I'll often look up a filter etc. on the internet, and not understand a word of what is written on it's Wiki page - "Z-planes", "Laplace transforms" - eh? A tiny little bit might be understood with each read, but it will always be beyond me, because I don't understand the mathematical concepts behind those things.

There has been, and always will be, a certain "threshold" in SM/FS - the point at which the ready-made primitives no longer do everything that we need. It would be an impossible task for the developers to attempt to provide a primitive for every situation - so code/assembly are there so that users can extend the collection of tools for themselves. We may consider that this "threshold" is currently set too high or too low - but that is besides the point; there will always be somewhere that we cross from using FS as "Lego bricks" and enter the world of software development.

The trouble then, is that we all want our schematic working right now! You are not alone in wishing for simple explanations for how certain codes work etc. - I remember feeling just the same way when I was learning. But the simple fact is that there is certain "a priori" background knowledge that is required even to understand the explanations sometimes. And that often means putting one's current project to one side, and taking time out to study and understand the underlying concepts. 90% of the schematic files on my system are nothing more than experiments to determine the behaviour of specific commands or principles - I share as much of what I have learned as I have time to, but no-one can condense years of SM/FS experience into a handful of bullet points or a canny visual metaphor.

You say you'd like a more modular way to learn these things - well that is what I'm talking about too. What you are attempting is like entering a university programming course half way through the second year. The visual style of SM/FS allowed you skip over the first year "modules" about binary representations, bitmasking, memory addressing, machine abstractions etc. etc. Once the comfortable graphical abstraction is removed, these principles are revealed, which the primitives have not prepared us for - and we have to back-track and learn those "year one" modules that we missed out on. It's been a shock to the system for a lot of people over the years!

There's no shortcut through this "apprenticeship" - so long as you don't know "how it works", as you put it, programming in code, and particularly assembly, will elude you. Some pretty diagrams and visual metaphors might help a bit to help get the information across - but you are getting into coding at the level where you must deal with the machine as the actual thing that it is.
I'm sure that DWB, MyCo and all the other coding "gurus" here will have been through the same frustrating experience, I know I certainly did. It is a daunting learning curve, and I won't pretend otherwise.

This is often why I include extra information in my explanations - the old "give a man a fish or teach him HOW to fish" metaphor. I don't pretend for a moment that I do this particularly well; but the background information is intended as a springboard for your own research so that you can become more self-sufficient in your coding.

There are billions of coding problems and bugs out there - do you really want to have to ask every single time, and learn only the specific "workaround" to individual problems? Or to take a longer term view, and learn to work them out for yourself from first principles? Or maybe find a collaborator to share the project? Or just hang about waiting for another forum user to write your code for you? Or just hassle Malc until he puts what you want into a primitive?
I'm not saying that any of these approaches is necessarily "right" for any particular problem, or passing judgement on anybody - it's simply a statement of the choice to be made for anyone in the same situation.

You simply cannot learn to be a coder by working backwards from specific answers to specific problems - the general principles need to be there first to build upon.
Until our heads all have a USB socket in the back for downloading knowledge - there's no avoiding the time that this takes.

I'm sorry if that makes me seem like a harsh schoolmaster - but you have said yourself in the past words to the effect "I just want to get this working, I don't want to spend years learning X, Y, Z...". That's up to you, and I am no more or less inclined to try and help because of it - but you will keep on returning here with one problem after another so long as you cling to the expectation that coding can somehow be made as simple to comprehend as chaining modules together - it can't; and if it could, there would have been no need for SM/FS in the first place!

In some points I agree, in some points I disagree with you.

I noticed, that a part of learning process resides in the background, and that this part can be trained. As an example - last year I did not know what to do in code, and it was rather painful for me to deal with it. I left my projects behind, because I did not knew how to do certain things. But playing with lego bricks, and familiarizing just by observing, plus time for internalization - made, that this year - I just go inside and rather understand what I do, than don't. I guess in a year or so - I will discover, that I do understand the mechanics of filters and coefs, maybe assembler and so on, without knowing how did I learned that; of course it will depend on my priorities. You may disagree with me, but this is how it works with me even if it does not works with you (but the fact that it works with anyone, means that this can work with everyone). I don't need to interactively/consciously (in pre-described way) participate in my learning process, I can use shortcuts and still learn.

We just express different paths of learning. As you noticed - year ago - I just started with programming at all. As you noticed very soon - my projects seemed to tend to go beyond ordinary frameworks very quickly. Specify your need and be creative on that - then you will learn what you need for it, and this is practical way of learning too.

Your 25 years of experience made you rigid in some points; go beyond that, pretend "as if". Did you noticed how the "new generation" learns to use electronics? "Intelligent monkey style" so to speak. We say that it's natural for them, but consider for a moment what it really means. 5 year old kid knows more in computers than their parents; do they understand the science behind?

p.s.: I guess, some of the best - learned through reverse engineering, so this one is also a path of learning.

p.s.2.: No matter how it sounds for you, encouraging others to do a part of the job for you - is also a part of learning. We start to live as a "network", not individuals from scratch. Look at professions - we are a species that promotes diversification.

p.s.3.: Old school question: "Why should they have easier than me? I had to spend years on learning things, and they want to have the results instead of learning the thing I had to learn, in my way I had to learn it". I noticed, that this internal conflict cause more problems, than anything else. Work of older generation is a legacy for newer one, otherwise we wouldn't reach new levels of expression.

i think trog is right with all the things he said, when i found SM i thought "cool i do my own plug ins and in a year i can make my own company" but after a year i decided to buy books and visit some courses at school because i know now after one year experience that there are loads of things to learn and also lots of things which are not that funny like just putting some cables together, things that cannot be answered in a few sentences here in the forum, sure i learned a lot of things here and in SM forum and with experimenting at home but thats far not enough, some things (lots of things if you want to be pro) need to be learned from books or higher schools or big expierience but YOU have to learn it and it will need time doesnt matter how many different ways troggluditte or some other helpful person will answer your questions,...

With Trog, we rather discuss the ways of learning in general, and I decided to touch "sensitive" topics/aspects of that by purpose. In our Country we have a broad discussion about what is taught in schools or institutions like those responsible for car driving licences. Two models are crashing with each other. Memorizing things, and adapting to reality. It appears, that in many aspects - we are taught to memorize stuff, not to use it. This year for example, they changed rules for car driving licences (from memorized to more real-life), and passing the exam dropped from 70 (as far I remember) to 10%... Some ways are better than others, and ways of learning depend on context. Learn about learning, and you won the game. You insisted on "YOU have to learn", but missed the point called "HOW", and this makes big difference (like year vs month; time is crucial here, isn't it?).

tester wrote:With Trog, we rather discuss the ways of learning in general, and I decided to touch "sensitive" topics/aspects of that by purpose. In our Country we have a broad discussion about what is taught in schools or institutions like those responsible for car driving licences.

Indeed, we certainly see some things very differently - but I much respect any person willing to debate, who will humour being disagreed with, and does not expect everything to be reduced to trivialities.
And I would also concede that through these posts, you have uncovered the primary reason that I could not be a schoolteacher - I lack the patience!
Interesting that you say "in our country". From my experience of people of other nationalities, I'm am often struck by the though that the English speaking peoples are often the least curious and keenest to trivialise. A gross generalisation of course, but I am far from alone in making that observation.

tester wrote:p.s.: I guess, some of the best - learned through reverse engineering, so this one is also a path of learning

It certainly is, I did not intend to suggest that other learning should be to the exclusion of looking into the anatomy of existing models. Rather that the objective is best achieved by coming at it from both directions - research into the first principles provides the "dictionary" or "glossary" that allows the examples to be interpreted more easily.

tester wrote:p.s.2.: No matter how it sounds for you, encouraging others to do a part of the job for you - is also a part of learning. We start to live as a "network", not individuals from scratch. Look at professions - we are a species that promotes diversification.

I've been around the forum many years - clicked the download button hundreds of times - said thankyou a thousand times to the people who taught me what I know today, and who's modules and codes I use in my schematics.
And there are no prizes for re-inventing the wheel.
A quick ready-made solution is sometimes what is called for when working on a project - a perfectly valid route to a working solution. My point was that there is a trade here - the instant solution is unlikely to teach as much as a well worked example based on sound principles We each choose at any given time where we wish to be on this scale - but something which is both fast and convenient, and also a rich learning experience, is unlikely IMHO.

tester wrote:p.s.3.: Old school question: "Why should they have easier than me? I had to spend years on learning things, and they want to have the results instead of learning the thing I had to learn, in my way I had to learn it". I noticed, that this internal conflict cause more problems, than anything else. Work of older generation is a legacy for newer one, otherwise we wouldn't reach new levels of expression.

You should be hand-converting assembly into hexadecimal from a paper chart like I did when I were a lad - and if you can't calculate your own memory addresses instead of using these new fangled "variable" thingies, then frankly you shouldn't be allowed anywhere near a computer!

My teaching style and your learning style may be incompitible sometimes - but I'm still here checking out people's schematics, posting stuff I think people might find handy, promoting good Ruby practice so that we can build a library of useful things we can share. And I am grateful to the many other people who also do those things, and have enriched my knowledge and my toolbox - and the people who bring inspiring ideas, which can be just as important as the technical knowledge.
I'm also perfectly happy to use modern 'labour saving' devices - such as graphical programming environments that make building my projects so much easier.
No-one is saying that you shouldn't have it easier. I certainly could not have shown my code to someone in another country, and got a fixed version back minutes later, when I was first coding. Unless you had other geeky friends, there were just books - and no de-bugging tools. There's no need for anyone to do it that way any more, and I wouldn't wish them to.

DSP programming and assembly are quite unusual - the need for speed encourages the programmer to avoid high-level, very abstracted languages because they tend to be less efficient. With the abstractions taken away, it much more closely resembles the working practices of an earlier era of computing. That's not to say that we must do or learn everything in archaic ways - rather that that in this context, knowledge of the computing/mathematical theory becomes much more useful in solving practical problems, or just establishing the cause of a bug.
I wouldn't suggest anyone learn it just for fun, or feel that they are implored to - I only do it myself for the end results, not the enjoyment of it! But it seems to me that the level of your programming has reached the point where a little more background knowledge would help all the little scraps of information on the forum hang together.
The theories behind all that haven't really changes in my lifetime. It's not a case of sticking with old models from some sense of inertia or nostalgia - it is,as you say, intended as "making things easier" and "passing on the legacy" by passing on the experience of thousands of past programmers - that there are certain things that are really useful to know when you're attenpting to do certain kinds of things.

If my style doesn't suit you then than is unfortunate - that is just the way it is sometimes. I'm not one to hide behind the facade of an internet avatar - I come on the forum as myself, complete with whatever ego, neuroses and annoying habits that implies. I take an interest in whether the advice I offer is helping as intended, and try to make it as understandable as I know how - but I am still an amateur just like you really, with only a little time to be on the forums.

And my apologies if my previous post seemed particularly bad tempered - I had the grumps from having to work the weekend and I should have wound down a bit before I posted.

Dear Trog - I don't blame you for your style Not at all!

If I don't understand something, or it's too much for my eyes or to my brain at the moment, then i just write automatically something like "yyyym... simpler please?" or "it's too complicated for me in this form?" I address the issue, not people.

I don't know, maybe that part of my english expression is not perfect, or it's just the fact that such talks sound very different in written word than spoken face to face on live meetings (I noticed the same, when reading some books that followed video lectures; books were just non-readable, while video showed the context and it was the opposite). I just made some thoughts, with no intention to insist anyone to follow my experience. But it's my belief, that from time to time - it's good to talk about such varieties.

p.s.: You and lack of patience? Hmm...

tester wrote:from time to time - it's good to talk about such varieties

Yes, I believe that too - it would be a shame if the forum were only some kind of FAQ or repository for downloads. It good to talk about what we want to use it for, why we make the things that we do, or make them in some particular way. - and to be reminded that there are many views of the same problem/solution.

My earliest experience with computers and programming were very social.
When the first 8-bit home computers came out, they were a bit of a craze with spotty boys of a certain age, but still too expensive for many people to afford one. So there were many informal clubs and groups of friends who would gather to share a machine, often to play games, but also programming was surprisingly popular too - the attraction of being able to do something that our fathers were unable to , no doubt!
Computer programming was taught in at least an introductory way at most schools at that time in Britain too. I understand that learning how to use applications is also a valuable skill, but that has completely eliminated any teaching of programming for most school children.
That leaves these 'remote' ways of learning, like this forum, as the primary learning resource for most people - certainly those not intending to pursue it professionally. They are very valuable, and I would not wish to be without them, but they can be an uncomfortable medium to learn from for many people who have the potential to be good programmers.