Good bell. Not sure if it's possible to get its recorded ringing sound.
BTW, does it make sense to use bell harmonics as theremin voice? Or it's supposed to hit the bell by fast volume hand move/acceleration?
Did you try to simulate wind instruments?
"Good bell. Not sure if it's possible to get its recorded ringing sound." - Buggins
I think a better recording of it is possible. That one is so distorted / weirdly EQed / compressed / artifacted - and there seems to be some sort of wow & flutter going on. It probably started out life in a sorry state and got further mutilated going through the video compression puke funnel.
"BTW, does it make sense to use bell harmonics as theremin voice? Or it's supposed to hit the bell by fast volume hand move/acceleration?"
Not a lot of sense, more or less honing my analysis / synthesis skills. Though it did prompt me to significantly expand the high end of the filter Q control (lower end of damping, actually) by making it exponential. For stimulus I'm using either pulsed noise or the steep falling edge of the oscillator (max harmonics ~= sawtooth) at subsonic frequencies. I could set it up so that fast movements of the hand would trigger it too.
"Did you try to simulate wind instruments?"
I've done a human whistle, muted and unmuted trumpet, as well as trombone and tuba, and intend to try for more.
[EDIT] I don't think I've read anywhere that the damping control could / should be exponential, but it makes sense to do this as the frequency is exponential as well, and they are both feedback / feedforward terms in the state variable loop.
More Mock-uping
Playing with the cardboard mock-up again:
The black Sharpie line at the top is at 17" tall from the bottom, which is the max for 1/2" plywood and 16" smoked Lexan forming the control panel / bezel. I've got the tuner located right at the very top which seems OK in terms of viewing angle, I don't have to crick my neck too much to watch it while playing.
Side view shows the plate angles which seem perhaps the most comfortable to play. The body is angled back more than 45 degrees, this angling places the pitch plate at a good distance past the volume plate. The pitch rod is centered for gravity reasons on the mock-up, and not what I intend for rod users. External coils here are just 2D. I want the plates & coils to fit in the removable lid of the enclosure, which seems maybe possible with the sizing shown here.
Anyway, I'm doing this more for rough dimensioning, to see how the ergonomics might work out. No clue on how to attach anything to anything. Owners would pick between a rod or a plate on the pitch side, and not have both as shown here.
"Did you plan for the elbows to be almost fixed while hand moving?" - JPascal
Yes, exactly, that's the general plan, where the upper arm is more or less immobile and next to the body, particularly for the volume axis.
[EDIT] Another ergonomic factor I didn't mention that is at work here: I don't feel comfortable having my hands come very close to the plates when I play, maybe 4" or 6" minimum. Some players routinely interact with the volume loop at much closer distances.
Warm Boot Bug Squashed
For several months now it's been the case that a processor reset via the register set would lock up the D-Lev, and only a power cycle ("rolling a truck") would bring it back. I decided to get serious in tracking it down yesterday, and found the issue just now. The length of the SW load in EEPROM is stored at the beginning as 4 bytes, and the CRC is stored at the end as another 4 bytes. The stored length value includes these 8 bytes, but I wasn't taking that into account during the SW load from EEPROM to RAM, which caused the extraneous byte count to overwrite the first 8 bootcode bytes in RAM, hence the boot once OK but boot twice lockup situation. And when thread 7 locks up I lose the ability to debug via the CLI.
Boot code is one of those chicken / egg things. The boot code is resident in the FPGA load and is never replaced unless the FPGA configurator FLASH device is repumped. But after FPGA configuration it exists in FPGA RAM, so it's volatile.
[EDIT] There are certainly many possible ways to update the bootcode in SW, like load the SW section and then jump into a copy at fixed location in the SW itself while writing the bootcode space - maybe if the coding & build process were more complicated / out of control. Being this "close to the metal" I haven't found a need to even implement a watchdog timer - I'm not even sure how one might optimally do it with 8 threads of assembly churning away.
Curses
Light posting to this thread lately due to two vacations, outside demands, and switching my PC from WinXP to Ubuntu 18 LTS. I haven't had time to play my D-Lev much either, or work on presets, which is kind of a bummer.
For the past several days I've been trying to get my Hive simulator / assembler compiling and running on Ubuntu. I found the nice lightweight C++ IDE "Geany" and after some editing got the code to compile. I replaced the console display code with ANSI escape characters, and am getting a decent display in the console. But the way Linux handles the keyboard is so different that I'm wasting days trying to get back to where I was in XP. The functions "getch()" (blocking keyboard character read) and "kbhit()" (non-blocking keyboard character read and flush) don't have any analog in the Linux world, which handles keyboard input in a per-line manner (return key initiates things).
I've tried other's code snippets but so far I can only get a byte at a time, which isn't entirely useful as the escape key code is the same as the escape code that preceds many non-printing key byte strings - the only way to distinguish between ESC the key and escape sequences is via timing, which is fairly insane, but there it is. I'm looking into the ncurses library which provides this very functionality, but it wants to control everything going on in the console, including display. It's supposedly "portable" so maybe that's how I should have gone in the first place.
It's weirdly difficult to do GUI stuff. You have to research and try a ton of stuff just to know what not to do, and even then the prepackaged solutions fight you tooth and nail.
2019-10-05
Not a lot of movement to report, there has been so much to come up to speed on after switching to Ubuntu (you forget how much time you've invested over the years finding, acclimating to, and becoming proficient with various SW). I installed MS Visual Studio for Linux (via the Ubuntu package installer) and that looks pretty nice though I haven't done much but fire it up and install C++ support. People say it's one of the nicest and most powerful IDEs around, and MS for some reason ported it to Linux too (perhaps to support their Linux "subsystem"?). Found a couple of very nice videos for using it with wxWidgets to do GUI development:
https://www.youtube.com/watch?v=FOIbK4bJKS8
https://www.youtube.com/watch?v=FwUGeV2fnfM
Wow, even with the gentlest of intros, wxWidgets still looks like way too much confusion / work!
The default text editor in Ubuntu is gedit - I've noticed that it does syntax highlighting for various languages and uses an XML file to describe those. But Geany is looking like the editor / IDE I think I'll stick with for a while. It's a lot like notepad++ (which is only available for Win unfortunately) in that it remembers all the files you had open previously, and it's a lot like Dev-C++ in that it's a lightweight IDE for quick smallish projects. I hope I can figure out how to configure it to highlight my HAL assembly code (notepad++ conveniently has an interactive dialog for this). Linux has tons of IDE's / editors, I suppose because it's heavily used for code development.
It's too bad modern operating systems can't all pick one graphical framework to draw to the screen. So much redundant effort, so much incompatibility, so many wrappery things like wxWidgets trying to pull everything back together up at the top, adding their own set of issues and dependencies. nCurses wants to take over all I/O, when all I need for it to do is give me getch() and kbhit(), but it seems like it's all or nothing with nCurses. Serial port communication looks like it might be a similar nightmare, with gobs of half-baked / half-broken / non-portable / creaky-assed legacy SW between you and the port IC.
If you think you might switch to Linux as some point, do yourself a favor and start using as much cross-platform SW as you can right now, as that will go a long way to easing the transition. I can't see myself ever going back to MS (or for that matter ever going to an Apple) - Linux and Linux SW are really mature and entirely satisfactory at this point for just about everything.
[EDIT] Adding: 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.
You must be logged in to post a reply. Please log in or register for a new account.
