I don't want to sidetrack this interesting thread with general MIDI discussion. It is probably beter that I start another conversation. Anyway I'd be very happy if you participate.
D-LEV theremin looks nice even though I feel a bit lost within these 252 pages. I saw the site that you are preparing, it is a very good idea.
Are you about to present a stage of your work ?
A model that one could build or get ?
"I don't want to sidetrack this interesting thread with general MIDI discussion. It is probably beter that I start another conversation. Anyway I'd be very happy if you participate." - Mr_Dahm
I think it's very relevant, and appreciate your input! This thread has long passed the point of pithy...
Mr_Dahm, are you the person who implemented the MIDI code for the Open.Theremin? I've examined that code quite a bit and very much appreciate that it is open source.
"Are you about to present a stage of your work ? A model that one could build or get ?"
I hope so! The hardware has been in pretty good shape for a while now, with only minor additions lately for MIDI out and LCD backlight dimming. The software feels very close to finalized too. Right now I'm working on a user's manual for it.
"Yes, it me, Vincent Dhamelincourt." - Mr_Dham
Very nice to meet you Vincent! Your Open.Theremin MIDI code got me off to a running start when developing the D-Lev MIDI module. They say a picture is worth a thousand words, but there's nothing like a working code example to answer a million questions.
"D-LEV theremin looks nice even though I feel a bit lost within these 252 pages."
There's an index on the first page of this thread (which I need to update) that might help you.
Glad to chat with you too Eric!
I read what's going on at Thereminworld from time to time. I log in when I think I can contribute. This thread is so high level...
Yes, the index is a great improvement, it works very well to redirect the reader to the encyclopedic knowledge of this forum.
It's more if a newbie wants to start a project, find the schematics, source code, etc. that it's not so easy. But I guess that's the goal of the upcoming D-Lev website.
Anyway, I'm ready to contribute. On the MIDI or maybe just to have a newcomer's eye on the project if needed.
Moon Himher
While working on the pitch preview (PP) section of the manual I got the idea of routing the PP signal over to the triple oscillator section when PP was disabled. This interesting because there are various PP pitch correction (PC) & quantization options which are independent of the regular preset voice. So applying PC to the preset but not to the PP gives a nice voice doubling type effect: [MP3]. The preset here is one that sounds male on the low end and female on the high end.
Man don't never got enough oscillators...
Hi,
One very last post about MIDI here.
Just to say that upcoming MIDI 2.0 covers properly the 16bit 32bit topic and things like baudrate (it is "communication layer agnostic").
So I don't think it worth trying to make non standard solution in MIDI 1.0 and you are right saying:
Going against the standard seems riskier than going with it...
So as a conclusion : Keep MSB before LSB in a single "rolling status" packet, it is the best choice.
I think I'll align on same design in Open Theremin With MIDI.
Mo' MIDI, Mo' MIDI, Mo' MIDI
Several days ago I made Mute 0=>1 send MIDI note-off and all sound off. The "all sound off" command is rather mis-named, as any note that is playing will not stop (!) hence need to send a separate freaking note-off (actually note-on with velocity = 0, which should be a damping command if you ask me, but MIDI's gotta MIDI, everybody does it, etc.). I've read that sequencers deal with this (yet another) glaring hole in the standard by sending out a flurry of note-offs just to cover this hugely uncovered base. I also made MIDI chan=0 (an oddly invalid value which causes all sorts of mayhem at the lowest level dealing with it - "do you mean the real channel 1 or the user channel 1 (0)?" - and how do you represent it in SW, as -1? If so you have to make sure you don't actually use it as a channel!) now inhibit all MIDI TX activity, including these mute commands, which seems like the right thing to do. Also shuffled the knobs a bit and renamed the tloc knob to vloc, to make it clearer that it corresponds to the velo sense point (this is also the note on/off trigger point).
If one were guaranteed a wide pitchbend on the other end, one thing I was thinking would be to permanently center it on like A440. This would guarantee no retriggering going on outside of what can otherwise be a rather random range. Maybe move the fixed center point around with the oct knob? Just a thought.
For the past few days I've been really giving all SPI EEPROM code a thorough comb-over. In the process I've managed to erase my entire user preset space (not the read-only space, which figures) and of course I'm an idiot for not taking like one minute to back everything up. But not too much of an idiot because I tend to snag presets that I like with the librarian. Was able to get my system preset back by looking at editor screen grabs posted here to TW (OK, I'm an idiot) then found the ptoe_sys, ktoe, and etok commands would do it too in a roundabout but faster way. Broke my P3 for over a day which always freaks me out for some reason, computing is a house of cards all the way down, and I guess I find staring that fact in the face for any length of time fairly unbearable. Part of it was not quitting for the day and archiving it when it was working, but instead going for the gold and ending up holding a turd. Part of it was not holding my jaw right when rebuilding the FPGA, confounding what revision I was even working with. Much of it was changing too much at once and getting lost in the complex symptoms. It's always something stupid.
Anyway, P3 is back in business with much more consistent chip select management (the first line of defense is keeping the chip de-selected whenever possible). These changes have rippled over to the librarian code too. It turns out I actually located the preset and SW EEPROM regions correctly for optimal write protection, and I've got a subroutine to expose / protect just the preset region while keeping the SW region protected (but have that commented out for now, one thing at a time).
The default FPGA SW load could/should have something indicating to the user that an error has occurred in loading the EEPROM version of the SW. Processor insanity could possibly corrupt the SW region, but it could be uploaded again with the librarian. I could put a jumper on the EEPROM write protect pin, but that would leave the presets more exposed with no write protection possible, and would make updating the SW more fiddly for the user. The boot code is actually a subroutine, and my plan is to have that return a flag or other value indicating good/bad boot, with non-boot code writing this status to the LCD somewhere / somehow. Boot code is rather set in cement in the FPGA, and unfortunately (or fortunately!) can't be updated with the rest of the software, so it needs to be kept as small, simple, yet flexible as possible.
Hi,
On Mute:
As a Theremin player,
I want that my Theremin ends the note(s) that I played from the Theremin istself when I switch Muto Button 0->1.
This mute buton should only apply to the channel that I selected.
Mute button is not a "Panic Button" that mutes every sound from every channels and devices... (This task belongs to my distant synth or to the sequencer)
Normaly
"All note Off" should do if I want to hear sustained note (sustain pedal on) and release.
"All sound Off" should do if I even do not want to hear sustained note (sustain pedal on) and release.
Any way it reaches a limit because some "Omni ON" synth decided to ignore it ...
If theremin programm knows the note that it initiated, sending their respective Note Off will do as well.
(with great chance to be understood by the external synth). Sustained note (sustain pedal on) and release will continue to be heard.
On Single note + wide pitch bend range:
Yes it is an option. I had one Interlocutor who implemented it on his MIDI open theremin for his own needs.
Pros :
It simplifies code on both side of MIDI cable
One known note to turn off/on
Cons:
Some synth have limited PB range
Synth can't be configured to play bended note on one layer and pure note on the other (ignore pitch bend) to create harmonic tensions and resolutions.
Walter MIDI
"On Single note + wide pitch bend range: Yes it is an option. I had one Interlocutor who implemented it on his MIDI open theremin for his own needs." - Mr_Dham
Ah, interesting Vincent, thanks! It should be noted too that MIDI mute is more than sending "quiet please!" messages, one also needs to inhibit new note-on events during mute. If I were designing the MIDI standard I'd have done all sorts of things differently. It's like the spec was designed in a vacuum. It kills me whenever basic stuff is clearly and fundamentally out of whack.
================
Things You Have To Be Told
Got EEPROM write protection working finally. The 25LC1024 datasheet doesn't cover some very important things very well (if at all). It has a lot of words, most of which are informative, and much is really spelled out for you, but it leaves out critical information:
1. Max operating frequency @ 3.3V is unspecified, use 10MHz (max for 2.5V).
2. You MUST issue a WREN before ALL writes, including to the WRSR reg!
3. You MUST either wait or check RDSR[0] (WIP) after ALL writes, including to the WRSR reg!
4. You MUST raise CSn at the end of ALL writes, including to regs, for them to take.
5. You SHOULD raise CSn at the end of ALL reads, including to regs, for safety.
Keeping CSn high at all times is like holstering your gun - everyone feels a lot safer but you can still shoot yourself in the foot. Using the write protect feature is like clicking on the safety - where everyone including your foot can breathe easier. Nothing is perfect, and a wild write could still tickle code that unlocks the EEPROM and performs a write - the idea is to reduce the size of the target. [/gun analogy]
I have no idea how long the non-volatile write to the WRSR register takes (not specified in the datasheet) so the code continuously checks the RDSR WIP bit until it clears. I had no idea that writes to this register even needed time to "take". Input is ignored during this time, and I think this is how my presets got wiped, who knows what the thing thought of the data coming in when it came back to responsiveness.
You must be logged in to post a reply. Please log in or register for a new account.
