Let's Design and Build a (mostly) Digital Theremin!

(risking repeating myself... this built-in editor is an ABOMINATION, you hear me?! Bloody abomination!)

In code samples, I had to replace greater/smaller symbols on includes (which are normally required for system file includes, although some compilers are lenient) by " ", because the code tag does not disarm html and the pointy braces are swallowed...
(next to all the other shenanigans the editor does)
NOTE that it also stripped some comments apparently, because of an unfortunate sequence of symbols, i saw one where the comment text is there, but not the comment-starting characters... so that won't compile.

even though the guy is quite entertaining and provides world-class hand holding, I couldn't make it more than maybe 1/2 way through his videos (pointed to above) without going cross-eyed.  I'm probably not cut out for this kind of SW work.

Well, C++, especially in the form used by that venerable library (which I have not used myself but it rings very familiar, must be around for ages), is only called "high level language" by close-to-hardware people  High level concepts will look verbose in it.
But also, a full fledged GUI toolkit will support a certain expected complexity of UI, and to achieve it in a uniform way, there is a raised bar wrt minimum effort to make even less complex things. At least with that kind of language.
I wonder whether, if it exists, a GUI toolkit designed for C++11/14/..., could be more slim with regards to boilerplate code. But I'm not up to date there.

I quickly looked at the video, the idioms used in wxWidgets seem pretty familiar (well there are similar ones across GUI toolkits, but sometimes subtly different, which can be confusing).
It looks reasonably lean for that kind of stuff.

One guy there mentioned this, to reduce the manual coding effort:
https://en.wikipedia.org/wiki/WxFormBuilder

Geany, heh. Not looked at it, but it sounds like one of those billion come-and-go little tools in Linux. If it does what you want and it's not too bad if in a year support (bugfixes, development) is ceased, then I guess it's ok.
If you'd like to consider something more time-tested and probably worked on for a while:
Well, a lot of people use Eclipse with CDT plugin for C++ development. If your computer was new when XP was current, I'm not sure how much fun running a current Ubuntu and then Eclipse would be, though... it does not have the reputation of being the snappiest of software... Well it's Java based.
There is also Code::Blocks, which has been around for over 10 years, and is a lot "old-computer-friendlier" than Eclipse. Like Eclipse, it can be customized heavily, which can at first also be a burden. (the last stable release is from 2017, but don't be fooled, there are very current "nightlies", there is active development).
Btw, Code::Blocks uses wxWidgets for its GUI stuff, IIRC.

There is something from MS which is IIRC open source and much leaner than the actual VisualStudio, it's called "visual studio code", it has been 2..3 years since I used it, but it was nice as a lean editor with a couple of handy IDE-like features, without the bulk.

Serial port: Look into how to set it to "raw mode", that deactivates all the HW terminal nonsense for stuff that was cool before I was born.
It is mentioned e.g. here, and there are code samples for different setup scenarios:
https://www.cmrr.umn.edu/~strupp/serial.html

But yeah, this stuff carries a lot of historical baggage.
If you want to spend the time, this text was quite illuminating, but I forgot 80% of the details again
https://www.linusakesson.net/programming/tty/

As for console I/O:
I have not used it yet, but ncurses is definitely the go to thing these days, it is very widely used.

You *can* get something like kbhit and getch, but it seems very cumbersome, and you can screw things up and then your terminal doesn't work properly anymore if your program exits and you didn't set things back to normal properly

I will throw in some code here for both, no guarantees, from when I fiddled around with this once.

Serial port: you'll have to look what the serial drivers are named on your system and replace the string with "ttyTHS", perhaps, this was on some embedded system.
This opens one with some common options. For details, refer to the links in the comments, I probably won't remember them, I' very poor at remembering such things and almost always have to look stuff like that up.

#include"fcntl.h"
#include"unistd.h"
#include"termios.h"
#include"sys/ioctl.h"
static int serial_init(int uartNum)
{
    static const auto filePath = std::string( "/dev/ttyTHS" ) + std::to_string( uartNum - 1 ); // e.g. "/dev/ttyTHS3"

    int fileHandle = -1;
    if ( (fileHandle = ::open(filePath.c_str(), O_RDWR | O_NOCTTY | O_NDELAY))  raw mode: https://linux.die.net/man/3/tcsetattr
    cfsetospeed( &options, baud );
    cfsetispeed( &options, baud );
    tcsetattr( fileHandle, TCSANOW, &options );
    tcflush( fileHandle, TCIFLUSH );

    return fileHandle;
}


static int serial_shutdown(int fileHandle)
{
    return ::close( fileHandle );
}

static int serial_echo_once(int fileHandle)
{
    static const char prefix[] = "ECHO: ";
    static const int prefixLen = sizeof(prefix)-1; // without the terminating 0.
    char buf[ 128 ];
    strcpy( buf, prefix );
    int numbytes = ::read( fileHandle, buf + prefixLen, sizeof(buf)-prefixLen );
    if (numbytes > 0)
        ::write( fileHandle, buf, prefixLen + numbytes );
    return numbytes;
}

KBHIT: Yeah, here also a kind of raw mode is enabled... to disable the normal handling of key presses by the system.

#include "sys/ioctl.h"
#include "termios.h"
static void raw_mode_enable()
{
    termios term;
    tcgetattr(0, &term);
    term.c_lflag &= ~(ICANON | ECHO); // Disable echo as well
    tcsetattr(0, TCSANOW, &term);
}

static void raw_mode_disable()
{
    termios term;
    tcgetattr(0, &term);
    term.c_lflag |= ICANON | ECHO;
    tcsetattr(0, TCSANOW, &term);

    //---
    tcflush(0, TCIFLUSH); // Clear stdin to prevent characters appearing on prompt
}

static bool kbhit()
{
    int byteswaiting;
    ioctl(0, FIONREAD, &byteswaiting);
    return byteswaiting > 0;
}

The usage would be like this:
- enable raw mode on terminal
- call kbhit
- after it returns, get the char with getchar() and process
- disable raw mode again (or the console won't work properly)

Let me add:

Your mentioning of escape characters reminded me of this stuff, if you want to move the cursor or clear a line etc:
https://stackoverflow.com/questions/38770996/linux-moving-the-console-cursor-visual
http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x361.html
https://stackoverflow.com/questions/1022957/getting-terminal-width-in-c

All of this cumbersomeness seems like this really should be handled by someone else (e.g. ncurses devs)
(although I have used bits & pieces like those for tiny programs where I didn't feel like getting into elaborate libraries for)

"(risking repeating myself... this built-in editor is an ABOMINATION, you hear me?! Bloody abomination!)"  - tinkeringdude

Yes, I've found that I have to be careful which browser I use to do the editing, as one of them often throws blank lines inbetween everything when editing. Thank goodness for the "view source" button on the right (for pasting & cleanup - which I ironically can't refer directly here by typing the less than and greater than symbols!).  Pasting seems to be a bit better lately?  Just don't try to paste real code (as you have discovered)!

"Well, C++, especially in the form used by that venerable library (which I have not used myself but it rings very familiar, must be around for ages), is only called "high level language" by close-to-hardware people  High level concepts will look verbose in it."

Yes, I imagine so.  C++ isn't my favorite (what is?) but I've used it long enough to understand and work around the quirks I encounter.  Languages themselves seem to be such a moving target lately I'm not sure how SW folks get anything done.  The silicon world is like this too (strapped to an unguided nuclear rocket)  but at least some of that is constrained by physics, rather than pure imagination.  So much of the SW world seems to be driven by fashion (this from someone mostly outside looking in).

"But also, a full fledged GUI toolkit will support a certain expected complexity of UI, and to achieve it in a uniform way, there is a raised bar wrt minimum effort to make even less complex things. At least with that kind of language."

It seems there could be more of a middle ground for noobs like me.  Much of my stuff can run off of pop up dialogs, and just having a set of those would go a long way.  TeraTerm has a nice set but it's not portable (and the TTL language is just for scripting).  An easy way to make the main window "dialog" would be nice.  And I'd prefer to write the inner polling loop (hence my need for getch()) as it forms a nice framework for my code, and I can control all the nuance from there.  Though of course I then have to recreate pesky things like backspacing and such.

"One guy there mentioned this, to reduce the manual coding effort:  https://en.wikipedia.org/wiki/WxFormBuilder"

Yes, he mentions that in the videos too.  He says he uses it all the time, though to get around the limitations one has to really understand the code it produces as no GUI builder tool can cover all the bases.  I'll give it a shot, but I have to assume it's over my head.

Even if one has the code all ready and in place, I'm worried that I'll run into build and dependency issues that I won't be able to resolve on my own, even with all of the advice on the web.  One of those video commenters said he had to delete the contents of a working project and fill it with his own code in order to get it to compile!

"Geany, heh. Not looked at it, but it sounds like one of those billion come-and-go little tools in Linux. If it does what you want and it's not too bad if in a year support (bugfixes, development) is ceased, then I guess it's ok."

Story of my life.  I become rather proficient with a piece of software and the next operating system blows it away.  One of the few programs that hasn't experienced this sort of demise for me is MS Office 2003 (though the sort field buttons in Outlook tend to disappear).  But, again, not portable, so WPS Office has been a godsend.  But I've relied on Dev-C++ for my small coding projects, and it's not been maintained for a while (not portable).  And TeraTerm, which was revived at one point and improved.  The photo editor I really know, Paint Shop Pro, was "maintained" to the point of unusability IMO, and the old reliable version won't run on Win7 (graphics issues), so the latest GIMP is actually looking OK to me.

"If you'd like to consider something more time-tested and probably worked on for a while:

Well, a lot of people use Eclipse with CDT plugin for C++ development. If your computer was new when XP was current, I'm not sure how much fun running a current Ubuntu and then Eclipse would be, though... it does not have the reputation of being the snappiest of software... Well it's Java based.

There is also Code::Blocks, which has been around for over 10 years, and is a lot "old-computer-friendlier" than Eclipse. Like Eclipse, it can be customized heavily, which can at first also be a burden. (the last stable release is from 2017, but don't be fooled, there are very current "nightlies", there is active development).

Btw, Code::Blocks uses wxWidgets for its GUI stuff, IIRC."

Yea, for some reason I highly value the editor popping up quickly and being just the right level of lightweight.  I briefly tried Code::Blocs (hate the name!) a couple of years ago when searching for a replacement to Dev-C++ but it was sluggish and weird feeling.  Will install Eclipse and give it a spin, thanks for the pointer!

"There is something from MS which is IIRC open source and much leaner than the actual VisualStudio, it's called "visual studio code", it has been 2..3 years since I used it, but it was nice as a lean editor with a couple of handy IDE-like features, without the bulk."

Over the past couple of years it seems to have become be THE main cross-platform IDE.  I have it installed but haven't played with it much.  Coming from MS is a knock against it (call me crazy) though it is open source.

"Serial port: Look into how to set it to "raw mode", that deactivates all the HW terminal nonsense for stuff that was cool before I was born.

It is mentioned e.g. here, and there are code samples for different setup scenarios:

https://www.cmrr.umn.edu/~strupp/serial.html

But yeah, this stuff carries a lot of historical baggage.

If you want to spend the time, this text was quite illuminating, but I forgot 80% of the details again

https://www.linusakesson.net/programming/tty/"

Thanks!  The first is POSIX, which is Linux / OSX, but not Win, correct?  This is why I want to avoid those types of solutions, though I've coded them and played with them to try to get around my issues.

"As for console I/O:

I have not used it yet, but ncurses is definitely the go to thing these days, it is very widely used.

You *can* get something like kbhit and getch, but it seems very cumbersome, and you can screw things up and then your terminal doesn't work properly anymore if your program exits and you didn't set things back to normal properly

I will throw in some code here for both, no guarantees, from when I fiddled around with this once.

Serial port: you'll have to look what the serial drivers are named on your system and replace the string with "ttyTHS", perhaps, this was on some embedded system.

This opens one with some common options. For details, refer to the links in the comments, I probably won't remember them, I' very poor at remembering such things and almost always have to look stuff like that up."

I believe termios is POSIX?  I'll probably end up going with nCurses as they claim it's portable, though not being able to use iostream things like cin and cout is a pain.  Seems there are many others noobs on the web with my same problem, naively asking the same questions in fora and being pointed to POSIX solutions or nCurses.

"Let me add:

Your mentioning of escape characters reminded me of this stuff, if you want to move the cursor or clear a line etc:

https://stackoverflow.com/questions/38770996/linux-moving-the-console-cursor-visual"

I've actually converted the cursor movements to ANSI escapes, and it works fine in the Linux console, but that isn't portable to Win (yet?).  The last response there mentions Dialog, which is a set of script launchable widgets, but I don't believe they are portable, nor well maintained?  And they seem to introduce a level of complexity beyond their worth?

"All of this cumbersomeness seems like this really should be handled by someone else (e.g. ncurses devs) "

The problem with that is the programmer is then often required to get at least partially inside the head of the cumbersomeness handler(s), which is usually a much more daunting job than the task at hand.  And then maintenance evaporates down the road and you're left with an uncompileable blob of code, searching for the next big thing coming down the pike.

Maybe I should just switch to Python and use the guaranteed (whatever that means) built-in Tkinter, but the language feels too "overgrown scripty" to me.  I actually have a portion of the HIVE sim in Python, but that would mark my 4th rewrite of something that has very limited use.  At this point I can't tell if it's me or the SW world that's got the problem here.   There's a giant leap to UI programming that everyone seems to be aware of, but few seem compelled to address?

Thanks much for that VS Code tips video!

I don't know what comprises POSIX precisely. I have not used a POSIX book. At some point I somehow slipped into doing stuff for Linux as a target, and came into contact with various things and how they might be done for Linux, and inevitably, a lot of that will be under the POSIX umbrella, with some Linux-specific deviations or extensions for practical reasons. It doesn't really tell you when you're using it what's what, wouldn't it be nice to see lines like #include "posix/feature123.h".

I think Windows only has some parts here and there that are, to some extent, POSIX-compatible, but not as a complete layer. And for the available parts, one still has to change some things sometimes. Like in winsock for networking, most of the familiar things are there. Sometimes different name, sometimes slightly different function signature or FLAG_MACROS.

I don't know Win32 API too deeply either. The first time when I really made standard-on-platform-looking GUI applications was with early .NET, and that seemed all rather sane and well put together. Roughly the right amount of abstraction to do that kind of work fluidly. In between I briefly looked at MFC and those 3 letters still make me shudder. (and before, well, games custom drawing everything, whether it's a DOS VGA or DirectX pixel buffer doesn't matter much - who plays games which look like office apps, that screams "boring!", and you need to learn to write pages of boilerplate code to display a rectangled window with a button? Seemed like building a Rube-Goldberg machine to just do the thing at the very end - which I already knew how to do.)

As for maintenance evaporation - I don't think ncurses will go anywhere anytime soon. I would be less sure about any GUI related stuff, but how much is console I/O (requirements) going to change? It seems more like a "*finally* someone took care of this mess and made it usable" project.
There are many for-developers projects which itself are being depended on by developers which use ncurses, like Yocto / OpenEmbedded.
I think the Linux kernel menu-config utility itself also uses ncurses.

And about software going crazy, fashion. Well at least it seems to me that they are stuffing languages too full of stuff too quickly. I like some of the additions to C++ because I have to use C++ and am familiar with the concepts behind some of the things they added (even though it's still more awkward to use than in more modern languages), and for somewhat higher level stuff, it decreases the amount of work to be done. But C++ code and ways of doing things of today is hard to recognize from the view of pre-2011 C++. Things have become "deprecated". C# is much younger, but still they are cramming stuff in high-speed, and sometimes "ok, to make XYZ easier, we introduce this". Next round: "ok, yeah, that was kinda ugly. So now we bend the meaning of your beloved keywords ABC in some contexts, which now makes XYZ even easier!" Meanwhile, there are several different ways to do the same thing, and you have to understand them all to maintain code written in that language, even though some of the things shouldn't be used anymore in new code. And a newcomer has to learn it all to be employable, depending on the company and the code in need to deal with, I guess.

While there are moving fashion trends with regards to designing software structure (how how to do software projects, for that matter), the GUI end of things is, not so surprisingly, more affected by fashion trends than other things. It's much closer to visual designers and those who constantly need to changed things to be new and interesting, starting from the surface, and permeating somewhat underneath. I guess smartphones were a big booster for that fire. They are fancy status symbols, even among kids. Must be shiny and trendy. And we are in the "post PC era", they say. Which I ignore, as I don't regard a phone screen to be adequate for a whole lot of things and it seems funny in a slightly perverse way to watch people using unproductive, dumbed-down apps made "usable" on tiny screens, while I'm sitting behind a multi monitor PC setup with lots of stuff opened that helps be do my work. I wonder where that will go...

The generally accelerated change everywhere, I can only speculate how much it's due to us just having more powerful tools to make more change, a lot more people involved (who made software of some sort in the 90's versus now?), everything being more computerized more deeply and thoroughly, and then also more interconnectedness of everyone and everything, and quicker feedback of perceived needs (for changes), of course, entirely without some sort of big masterplan or supervisor watching from a healthy distance, leading it all in a sensible direction.

Maybe this is all one huge system that's starting to self-oscillate and explode at some point
(that was not an endorsement of another (gang of) deluded, grandiose "chairman" stepping up to come up with a geat masterplan to leap forward, 2 feet before the abyss).

Oh, and if you want to try Eclipse, be sure to install a pre-packaged "for C++" one, all typical things needed for C++ development are in there.
This looks like about it:
https://www.hiroom2.com/2018/05/14/ubuntu-1804-eclipse-cdt-en/

If you found Code::Blocks overwhelming, be prepared for this big clutter box called Eclipse.

BUT, the number of people using it is far greater than C::B, and thus the likelihood that a usage or problem scenario will be covered in more than one forum thread somewhere and be among the first few google hits, given a good choice of search words.

This can be made quite usable. But initially it can be exhausting, when a lot of things need to be set up. Some subtle, IMO unusual little behaviors of the editor, despite general high customizability, cannot be changed, and sometimes I'd like to have a word with the responsibles...

The GDB integration certainly makes it more efficient to use vs. poking around in cmd line GDB for most everyday use, esp. wrt live variable & memory views that are quickly (re-)accessed, changing data types/formats of things displayed, auto-highlighting memory regions which changed since last run etc.
But those features have their quirks and not 100.0% reliability - at least with remote targets, especially bare metal, but I guess that's not unlike with other tool chains on those kind of targets.

As an editor, I found VS code much more pleasant to use. (after some tweaking, of course).

wow very nice.

Dewster,

What parts are used in your design as optical (toslink) transmitter and receiver? 

I've found new Teensy MCU - v4.0 with S/PDIF input and output. Trying to find out what footprint to use for optional S/PDIF transmitter and receiver on theremin PCB.

"What parts are used in your design as optical (toslink) transmitter and receiver?"  - Buggins

https://www.goldmine-elec-products.com/prodinfo.asp?number=G16911B

Roger (pitts8rh) could probably get you a footprint.

Also, the D-Lev will be segueing over to electrical SPDIF out, rather than optical, for feeding the SPDIF D/A converter boxes.

I was reminded of this add-in for VS code:
https://marketplace.visualstudio.com/items?itemName=mshr-h.VerilogHDL

Depending on how nice the editor of your FPGA toolchain is, that may be i nteresting or not

(there is also VHDL, but I believe over the pond y'all are using Verilog, for whatever reason? (what I'm wondering about is the more or less sharp geographical dividing line))