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

"So it seems the system puts a time delay between putting the key code byte sequences in the internal buffer."  - tinkeringdude

I think this is due to the web interface.  If I press two function keys together on my local build I sometimes see them concatenated:

1b5b31387e
1b5b31387e
1b5b31377e1b5b31
387e
1b5b31377e

"This is just code pasted verbatim (sans line numbers) from this tutorial:"

Thanks!  I was on that site a while back when checking out ncurses.  I couldn't get a lot of the examples to run, which was discouraging, but I was probably doing something wrong.  I couldn't get a good enough feel for ncurses to want to use it, it seems really ancient, like a pile of hacks on top of a hack.  And I couldn't tell if it was really, genuinely, truly, airtight, guaranteed, cross-platform.  And it takes over the screen, which I didn't want at all.  Like all this GUI stuff, you have no idea where you'll finally end up after putting in a lot of time learning how they demand you do things, or even if it's right (or worse, wrong) for your project.  And what if after all that it works fine in Win32 but is somehow slightly busted / less than ideal in Linux (or vice versa)?

"Have you tried running that program on you machine as-is?"

Yes.  I think the problem is what the OS is doing with the keyboard port in between reads, when the mode is switched back.  If you have a tight loop like in the toycode then it spends the vast majority of its time in read mode and doesn't seem to act up.  In that scenario, could the mode switching itself be optimized out by the compiler?

Hrm, weird. On my Linux VM it also works as described.

Some bigger software packages implement separate native GUIs for different OS distributions, especially very demanding or fancy looking stuff, and keep only the core code cross-platform. That requires a certain level of abstraction and not designing things closely coupled to GUI framework specifics.

QT does seem to work reasonably well cross-platform, if you use their QtCreator IDE. I just don't personally enjoy working with it (the whole framework). And it's not free to use for commercial stuff, which may make it impractical for small projects. A lot of their mechanisms have become obsolete with current C++ and are more cumbersome to use than the latter (although this may have changed since I last used Qt).
But it's also not a magical "make it work everywhere button", cross-platform is always extra effort, especially if windowing systems are involved.
Especially the closer to the metal some development environment is, the more annoying it is with all the dependencies.
And while C++ & something may seem high level to a FPGA designer, it's still low level enough to be a pain to get this to even just compile & link on more than one platform, with all libraries needed.
That's why I initially suggested something like Python. There may be a host of different libraries for it, but for every kind of task / topic area, there is usually the one library that's clearly the most popular and hence most well tested and supported. Like everyone I know uses Numpy, and certain (math-aware?) drawing package for visualization of stuff, and a bunch of other packages that often come included already with a Linux installation.
(or for that matter, even Java and it's most recent GUI lib, I guess there is also one defacto standard one next to a lot of smaller efforts.
At least Java is somewhat related to C/C++, so there's some familiarity)

Anyway. If you're ever at the point of being fed up with all this mess, and you'd just like to have a damn pixel buffer like it was a hardware LCD in some HW project and don't care about implicatons of different desktop resolutions or stuff looking foreign on a GUI desktop with a certain windowing system and stuff, you could also use SDL (simple direct media layer), ask it do give you a window with a pixel (double) buffer, as well as raw keyboard and mouse input, and pretend you are making a game or DOS program with GUI
They still have an additional TTF library for drawing text, all else is homework.
Even though you seem not to be recreating the MS Office GUI, this also is not without effort, of course - just that there are less things "actively" in the way.
The latter seems to be your main frustration right now, which is the only reason I'm suggesting this, even though many people would find this silly. But that's probably a matter of requirements and priorities.

"That's why I initially suggested something like Python."  - tinkeringdude

I do appreciate that, and I imagine you're right.  PySimpleGUI seems really nice.  The Python community seems intent on making programming easier, and I'm all for that.

For the Hive simulator / assembler I was mostly worried about speed / sluggishness, and also natively modulo math, so kinda Python scared me there.  But for the librarian, maybe Python is the way to go.  I really miss the file picker widget in TeraTerm.

I did the auto upgrade on my Linux Mint Chromebook from 19 => 20 and a billion messages flew by for Python.

It's fair to say it is widespread

I guess that's the big plus. While it's a "weird" language in that it deviates in some major paradigms from C/C++ like languages, as soon as the basic hurdles are overcome, being able to do something in Python will at least enable you to also better understand how some automatted things in current Linux distributions work. You can take note and maybe do similar tasks yourself. It's probably a lot more pleasant than older scripting languages of the Unix world (like bash itself, and awk, which is perhaps not coincidentally the beginning of "awkward")
I still have that on my todo list myself, like many things...

There's still NetBeans IDE with its GUI builder for Java, for assembling basic GUIs per drag & drop, auto-generating all the typical Java verboseness.
I've never used that either, though. And one would still have to engage in Java verboseness for everything else
But at least setting things up to actually compile etc would certainly be a lot less painful than using Qt for cross platform programs.

"While it's a "weird" language in that it deviates in some major paradigms from C/C++ like languages, as soon as the basic hurdles are overcome, being able to do something in Python will at least enable you to also better understand how some automatted things in current Linux distributions work."  - tinkeringdude

Thanks!  I'm taking another look at Python for the librarian, which is a better fit I think than the simulator / assembler, and a smaller, reasonable, and tractable first project.  Interaction with the OS filesystem and manipulating file data is probably simpler to do in Python.  I'm looking at the miniterm code for reference and they (ironically?) seem to play the same games with termios and canonical mode and all that, but the have a nice port picker that lists the available HW serial ports.  PySimpleGUI seems a little clunky, but simple and probably highly useful.

Once one knows another language or two (SystemVerilog, VHDL, I guess I know C++ OK, MS Visual Basic at a hack level, of course HAL assembly which I wrote, OpenSCAD a bit) it's hard to sit through noob type tutorials.  I seem to learn much more quickly by examining good code, googling, and consulting cheat sheet type references (of which there seem to be many good ones for Python), and of course having a good first project as impetus.  A cheat sheet is the basic language syntax from a thousand feet up, something tutorials don't / can't ever seem to do.

There's a simple way to turn Python code into a single stand-alone MSWin executable, I'll be investigating that too.

You ever use the PyCharm IDE?

No I've not used an IDE for python. All I ever did so far is make changes / add something to scripts someone else wrote to e.g. access hardware features he designed and I'd add some convenience options to a pretty linear script so I could work with it better.
For that a somewhat code-aware editor was enough. I wouldn't call myself exactly fluent in that language, but I run across it somewhat frequently, not least because that one EE colleague does "everything" with it, and from playing with Linux distribition customization.

These here are what I see a lot of people use... maybe not intersting for the librarian, but more generally, as an aide to figure things out.
https://www.scipy.org/

Lists some more than the above
https://wiki.python.org/moin/NumericAndScientific

Examples
https://towardsdatascience.com/interactive-data-visualization-using-plotly-and-python-4846dd510678

https://realpython.com/numpy-scipy-pandas-correlation-python/

You'll also find that, for some funny reason, python is big in machine learning, in conjunction with TensorFlow.
I get e-mails every couple months for "webinars" about using those tools and then some ST Micro provided stuff to transform neural networks developed with those tools into code running on ST's microcontrollers. Apparently "IoT" devices need to be smrt now, too.

What I sometimes encountered on systems where both, python 2.x and 3.x, mutually incompatible, are installed e.g. for compatibility with older scripts, that calling the installer "pip" or python itself required to explicitly tell everything you want 3, elel "pip3 ...", "python3 ...", and sometimes for more complex command lines where at some point such a command would be relative to an already invoked python3 base, it would then not be "pip3" but only "pip" again.
That could be somewhat confusing when just trying to paste command lines from tutorials with different setups - just as a warning
Python 2 is a deadend, nobody I heard recommends learning that.

Thanks again tinkeringdude!  I encountered that python3 / pip3 thing yesterday when downloading python packages and trying to run demo code.

PySimpleGUI isn't working as well as I'd hoped, so I'm looking at Tkinter.  Most simple calculator demos don't display correctly as there seems to be a tension between font sizes and pixels at work.  I was also hoping for more serial port and keyboard functional encapsulation, they're playing many of the same tricks (read: hacks) one ends up playing in C++.  The multi-threading is interesting though.

Wasn't PySimpleGui the one that sits ontop of Tkinter? I guess that's simplyfying things, at the price of less flexibility/power, as it tends to be.

Hehe, I was just wondering whether anyone had done this... and what do you know:
https://github.com/taxpon/openpyscad

Now this has the dangers of any one man project (e.g. might get bored and problems never get fixed), but I guess *if* this turned out to be really useful and have some flaws or things missing, from the looks of the managable size of this, one could take it on oneself I guess.

Now at a first glance some of the examples look to be a bit longer than resulting OpenSCAD code.
But potentially the power of such a libarary would be in weilding the powers of python to create some things procedurally on a level one step or so higher than OpenSCAD and make things easier.
At least that would be my hope towards something like this - I'm not deep enough into what this actually does and what OpenSCAD can (not) do (easily) to make that judgement.
(and this take at what I talked about some weeks ago is of course also one step further removed from actually seeing what one is doing, in the live view of OpenSCAD)

"Wasn't PySimpleGui the one that sits ontop of Tkinter? I guess that's simplyfying things, at the price of less flexibility/power, as it tends to be."  - tinkeringdude

Yes, and probably.

Today I went through this excellent Tk tutorial: https://tkdocs.com/tutorial/index.html.  It's kind of a Rosetta Stone as the examples are shown in Tcl, Ruby, Perl, and Python (Tkinter).  I looked into getting Tk working with C++ but couldn't figure out how to do the build and gave up (this is common for me, compiling and linking C++ is so incredibly arcane).  Python gives instant gratification, just run the damn thing and up pops a window with functioning buttons and stuff.  So I'm trying to learn Python for the third time...

"Hehe, I was just wondering whether anyone had done this... and what do you know:"

At this point it doesn't seem to be much more than another layer, and I've learned to distrust that sort of thing unless it's highly polished and really value-adds.  Where I worked they had an in-house C like language that cranked out VHDL, and was to be used by SW types that didn't understand the parallelism of FPGA HW logic (whereupon hilarity ensued).  The code it generated was a read-only mess, with all the asynchronous stuff in one blob, and the synchronous in another blob.  And of course all nuance was either lost in translation or not made available to the programmer in the first place.  This kind of automatic code generation remains a forever out-of-reach holy grail for the FPGA industry.  Languages often exist to solve a problem, and if you're doing digital logic work you should learn SystemVerilog as it will be part of your solution.

One of the problems with OpenSCAD is the generators are somewhat broken, so defining something like a screw thread is much more complicated and involved than it needs to be.  And you add one little feature to a simple shape and the rendering time mysteriously goes through the roof.  It feels like assembly that got semi-promoted to C, with all the legacy cruft remaining, and in fact being heavily relied upon to function.  Routine, though necessary, little crap like adding a radius or fillet can take all day to figure out.

A major issue it seems with every language is the need to define the basics and then bang on it a lot to see what else you might need, but by then it's too late to fix inconsistent syntax, and people have written tons of code in it, which tends to set everything in stone.

[EDIT] One of the biggest issues with OpenSCAD is that real circles don't exist in it.  Everything is approximated with line segments.

Btw., for a while now you can explicitly state types in Python, where you think it counts.

https://docs.python.org/3/library/typing.html