Frank, Although you're an accomplished programmer of many years standing and I'm just a dabbler, I'd like to say from a users perspective: -
1. Aren't the relative benefits of graphical programming versus text based programming down to what you prefer to work with? Look at the rise in popularity and power of LabView - e.g. used by NASA for control of quite a few deep space missions. Many people who have to get results fast say they prefer it because of the head start it gives them and the speed of development. It doesn't come without some performance penalties I would guess, though. 2. Text based programming has been around even longer than graphical programming. I'd say that was pretty 'old' too ;-). I was intrigued by the Synthedit project because it was (a) low cost (b) popular (c) an open system capable of modular expansion by relatively unskilled programmers. 3. If not enough thought was put into the modules that made up the graphical palette - then I agree - the system would rapidly start to feel 'old' - by which I infer limited in potential or prone to go obsolete. 4. On the other hand - (I run a small EMC test lab) - I use a specialised graphical programming language called TILE to create test programs to control the instruments in our lab. It amazes me how versatile the system is in meeting new challenges, despite the fact it has such a small icon palette (about 20 modules). I can use the same old hardware in so many different ways I couldn't do with the closed system we had before. The 20 modules together with the ability to do math, create graphs and tables provides a very flexible control and measurement system. 5. The great thing about a graphical programming language - albeit only if structured well - is that the program can be essentially self-documenting and extremely modular. You can glance at a flowchart and get the gist of the data flow and overall purpose - which is not the case with a page of text program language. PowerSDR source presently has very little comment and no top-level specification to guide the stranger into the project - understandably, given the constraints you guys are working under. I'll be very interested to see where the SDR1000 control software development goes next - the above is just the hankering of an enthusiast to open the radio up to more people like myself who aren't advanced programmers. If the Python system gave us the transparency that is needed in terms of data flow and relatively short learning curve, then I'm all for it - despite it being text based ;-) I'm very happy as a radio operator with PowerSDR as it stands - the above is just constructive criticism by a hardware engineer that wishes he could contribute more to the project. Keep it up and best regards, Bob G4BBY