Post by: Max on April 04, 2020, 09:35:28 PM
Good evening everyone,
I would like to introduce you to my polyphonic MIDI interrupter, which I gave the fabulous name "Syntherrupter". Here's how it sounds:
And here's how it looks. First picture is SimonNwardUK's version with 4 outputs, second one shows the internals of my single output Syntherrupter (with an excessive optical receiver)
(https://raw.githubusercontent.com/MMMZZZZ/Syntherrupter/dev/Documentation/Pictures/Syntherrupter_SimonNwardUK_Top_Both.jpg)
(https://raw.githubusercontent.com/MMMZZZZ/Syntherrupter/dev/Documentation/Pictures/Syntherrupter_Max_Internal.jpeg)
Motivation
Netzpfuscher's UD3 (https://highvoltageforum.net/index.php?topic=188.msg4678#msg4678) has awesome features but many people prefer "simpler" drivers like the UD2.7. However, most normal standalone interrupters that are readily available have rather rudimentary features. The very popular Onetelsa MIDI interrupter f.ex. can only play two notes simultaneously and even that not very well (popping noises, only limited safety features). This is where Syntherrupter comes in. It aims to be the most feature-rich standalone interrupter that works with any tesla coil.
Key features
- Open Source and documented (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki#readme) (mostly)
- A unique and truly awesome name: Syntherrupter. ;D
- Easy to build. Except for the optical transmitters the other parts are "ready to use" modules that can be connected without soldering or custom PCBs.
- Over 10 voice polyphony including effects like pitch bend, modulation and different "instruments". Yes, you can - within limits - change how your coil sounds.
- Control up to 6 independant tesla coils with only one interrupter. And yes, each output can play different notes. Simply select which output should listen to which MIDI channel.
- Set and change hard limits for each coil. They will be stored even when powered off and assure that you don't fry your tesla coil no matter how crazy the MIDI file is.
- Advanced stereo features. Notes and MIDI channels can seamlessly change between multiple coils, creating fascinating visual effects.
- Lightsabers! An ESP8266, an IMU and a battery form a lightsaber that connects to Syntherrupter and allows "lightsaber-effects" to be played on your tesla coils! (credits: Netzpfuscher)
- Different users with different limits. This is useful if you want to rent the coil to someone else who does not know the coils (thermal?) limits as well as you do.
- Sounds boring, but for me it belongs to an interrupter as well: Normal interrupter mode where you can control the ontime, BPS and duty cycle.
Getting Started
For a comprehensive step-by-step getting started guide, click here (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Getting%20Started.md#readme)!
Discussions about bugs and features belong right here, while questions and issues around building your own belong to the Help and Issues topic (https://highvoltageforum.net/index.php?topic=1780).
MIDI Setup on the PC:
Open and play MIDI files with SynthFont (for good sound quality: download the SGMv2.01-Sal-Guitar-Bass-v1.3 (https://sites.google.com/site/soundfonts4u) soundfont). You can select a different output for each track which we can use to send some tracks to the interrupter. You might want to change the instrument of these tracks to use the envelope feature (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Envelopes.md#readme).
SynthFont allows you to send MIDI data directly to a serial port (=Syntherrupter). The baud rate is 115200baud/s.
If you want to use another Software you'll need two little tools that are very easy to use: Hairless MIDI<->Serial (https://projectgus.github.io/hairless-midiserial/). and loopMIDI (https://www.tobias-erichsen.de/software/loopmidi.html). When you start loopMIDI it creates a virtual MIDI device that you can select in any MIDI software as output (or input btw). And hairless MIDI<->Serial makes the bridge between this virtual MIDI device and the serial COM port.
This sounds complicated but since the last both programs remember the settings, you only have to start them - no other click needed. The setup has proven its reliability and usability many times and many hours.
Kind regards,
Max
Edit 21.05.20: Since the first release there have been quite a few significant improvements, like polyphony. I'm working on this post to keep everything documented. Most things are up to date, but not all. If something is still in work, it is noted there.
Edit 05.11.20: Most of the Information has now been migrated to the wiki. Hence this post got much shorter and easier to read.
Edit 28.01.21: Feature list now matches the GitHub readme. Includes direct link to the wiki.
Edit 26.04.21: Added SimonNwardUK's pictures, adjusted the getting started part, included link to envelopes wiki page.
Edit 14.10.21: Added links to the new Help and Issues topic (https://highvoltageforum.net/index.php?topic=1780).
Post by: Max on April 07, 2020, 01:10:30 PM
Smoke on the Water is a pretty good demonstration of its Pitch Bend, Modulation and ADSR capabilities, although the last one is less noticeable (Especially in the second half of the video!)
Kind regards,
Max
Post by: Mads Barnkob on April 13, 2020, 09:47:58 PM
It does however seem a little overwhelming and complicated, but once you show the picture of the inside, it seems a little simple again. But all the uses of different software and "conversions" could be a problem in the future? Instead of just having a MIDI interrupter appear as a MIDI channel on a USB->MIDI interface? You are running a seriel through USB jack communication?
How would you adapt this to something like 8 channel/voice MIDI interrupter, maybe a bit overkill, but I am looking into driving 4 coils at once at some point and would construct something in one unit at a point.
Is there a lot of custom MIDI editing to implement all the features of your driver or how well does it take a MIDI file straight from the internet?
Pitch bending on metal, sounds awesome, that ring down of the metal vibration is priceless.
Post by: Max on April 14, 2020, 02:46:08 AM
Thanks for the reply! Its actually pretty simple - in all the points you mentionned. I guess I have a complicate sounding way of describing stuff...
Software vs Hardware MIDI adapter: how difficult is it to use the hardware converter? Plug in, plug in, done. In software: double click on exe, double click on exe, done. The two programs, hairless midi serial and loopmidi are really simple. In hairless midi serial you select your input, output and baud rate - all of which is remembered when closing the program. The serial port is even determined automatically in case you change the USB port. Loopmidi is even more simple: start/stop - that’s it.
Both programs are small, free, stable, without noticeable latency or other bottlenecks, and have been around for years. In my opinion this solution has no disadvantage over the hardware solution. The latter would require me to buy a MIDI to USB adapter, a MIDI cable, MIDI connector and add some circuitry to the interrupter as MIDI requires an optocoupler on the receiver side.
Additionnaly I can plug my keyboard (which has USB) to my PC and switch with two clicks in hairless MIDI serial between keyboard and MIDI file. I prefer this over changing midi cables (especially during a live performance).
Multiple Channels: now this is an interesting idea. It would actually be pretty simple to modify the midi class for listening to certain chanels only. You could then have multiple instances of this class running. They would all receive the same data but only react if it belongs to their channel(s).
I guess the limit would be the amount of timers used to generate the output signal; which means you can have up to 6 independent outputs.
The biggest amount of work is without any doubts the user interface. I guess you‘d need at least to set the volume and midi channel for each output. This is still not a lot of work but for sure more than the changes to the „actual“ code.
You mentioned 8 voices for 4 tesla coils. This of course requires polyphony which I tried a loooong time to get working - without success. As I have no idea how to solve them I don‘t think I‘ll try it again anytime soon. I also lost interest because I really don‘t miss it. Listening to my favorite tesla coil title Counting Stars I don‘t know which other voice I‘d like to play on the tesla coil, too. And this is true for almost all of my MIDI files.
MIDI file preparation: usually none at all. 8) Most of the work is finding good MIDI files. I‘m looking for two things. First, the melody is monophonic it is no problem if it switches between tracks but there shouldn‘t be anything else on these tracks. Second, there are „meaningful“, rich other voices that can be played on regular speakers. This is even more important than the first point because you can easily copy/move notes to a separate track. Writing your own accompaninent is way harder ;)
I haven‘t done any other MIDI file modifications yet. The Counting Stars video above, the Smoking Water video in my previous post and the Pirates of the Carribean video in the first post all use an unmodified MIDI file. The only change was me setting the modulation manually in the Pirates video (you could save that change to the MIDI file with ~two clicks).
In theory you don‘t need the other voices but in my opinion it adds so much to the overall sound that I don‘t (want to) use any of these prepared single/dual voice MIDI files for tesla coils.
I have to admit I can‘t see what other processing you would need to do with other MIDI interrupters except for changing the channel number.
Hope this sounds less complicated and more helpful ;)
Kind regards,
Max
Post by: Max on April 23, 2020, 09:25:46 PM
So Mads input motivated me to do two things: 1. create an english version of the GUI and 2. implement the possibility for multiple tesla coils.
When I said I didn't want to touch the GUI anymore it was mainly because when I first created it, fonts looked really ugly. Therefore almost all Text in the GUI are actually pictures. Looks fine, but is a pain in the ass to work with and even worse to create translations.
Since I was almost a "day 1" nextion user, they had quite some time to improve their software. As of today, most fonts look quite good. So I decided to start from scratch and implement the new functions. This time I try to make it as easy as possible to change the language afterwards (basically a list of all strings which then can be replaced with content in your language). I'm documenting the code that runs on the nextion, too (was not well documented). The new GUI can be found in a separate branch on GitHub: https://github.com/MMMZZZZ/Syntherrupter/tree/GUI-Redesign (https://github.com/MMMZZZZ/Syntherrupter/tree/GUI-Redesign)
Here's a little preview. The GUI has space to select from up to 10 coils which shall receive the new settings. The Tiva microcontroller can only handle up to 6, but there might be ways to increase the number.
[ Invalid Attachment ]
I'm thinking about adding other features, like changing the ADSR parameters in the GUI. Your input (or even contribution) is highly welcome!
I haven't touched the Tiva code yet. I'll start working on that once the GUI gets usable.
Kind regards,
Max
Post by: futurist on April 24, 2020, 01:19:44 PM
Hairless midi to serial with loopmidi is really easy to use, I use same setup with onetesla interrupter on atmega328p mcu
What was wrong with polyphony? Can you describe why the coil sounded bad?
Post by: Max on April 24, 2020, 02:18:51 PM
Thinking about USB... it just came to my mind that the microcontroller actually has full USB functionality so it could be possible to make it identify as MIDI device without additional cables, adapters or software. That would be awesome! I'll have to check that.
Considering polyphony... I tried the following: A sample-ISR is called at 55kHz. Each call increases the "tick count" in an array. A second array stores the ticks necessary for 1 period of an active note. Once that value is reached, an output pulse is generated and the tick counter of this note is set back to 0. That idea was proposed by Netzpfuscher and basically I don't see many other ways of doing it.
The first big problem is: Two pulses can follow each other very shortly. 1 "tick" is not enough time to ensure primary current has ringed down to 0. That means you have a high risk of hard switching on the next ontime (UD1/UD2 drivers always switch at the beginning of an ontime to start the oscillation and only after that first kick start using ZCS. UD+ (which I have) is even "worse" as it has a startup oscillator switching at least twice). This becomes even more of a problem when low notes (allowing looong ontimes) are mixed with high notes. Therefore a minimum offtime needs to be ensured between notes. How? Well I implemented three different ways:
1. Skip. If the next ontime is too close to the current, skip it.
2. Delay. Wait until the minimum offtime is over before generating the pending ontime.
3. Merge. If a ontime shall be generated, "look ahead" if another one is too close. If yes, merge them, meaning generate a pulse with the sum of both widths. I thought this should be the best sounding option.
The issue with all three was - if i remember correctly; that was at least a year ago - it sounded very distorted even with only two notes. Playing three notes I could no more identify the notes playing. The three variants all sounded a bit different, and even without a minimum offtime it didn't sound good. The most demotivating thing for me: on the scope the output signal looked just the way I expected it. This means, I had a perfect overlay of two tones, just like if you had or'ed them together (plus the offtime thing). So my code worked fine, or in other words: I had no idea how to make it sound better. I never tested it with an actual coil but only with a piezo and my oscilloscope. I absolutely want to ensure proper operation before attaching it to anything that can blow up. And I didn't implement any other basic features, like receiving MIDI data. Notes, ontimes etc was all hard coded (and perfectly fine for such first tests).
Additionnal issues: The skip/delay and especially the merge code took quite some time, actually about 50% of the CPU time. this does not leave a lot of time for servicing UART interrupts or MIDI processing like I'm doing now. I'd have to look into things like uDMA to gain time but as of now this is above my skills.
Bottom line: I waste most of the CPU time generating a signal that sounds worse than a single note and I have no idea how to improve sound or CPU time.
I attached that old code below in case anyone is interested. It is more or less commented. The whole nextion stuff can be ignored. What I described above happens inside "notesSampleISR", "newNote" and "main".
Kind regards,
Max
Post by: Netzpfuscher on April 24, 2020, 04:56:15 PM
I heaven't read the datasheet of the tiva but the big ARM micros can chain timers, so a sound generation like mine in the UD3 can be possible. I haven't found anything that sounds better and it need not so much CPU cycles. You don't need a super high clocking ISR for sound generation. Only like 10 times the highest frequency you want to play.
You need a free running hardware counter/timer the frequency from like 100-300kHz without interrupts. Then you need a 10kHz sample ISR and a One-Shot timer for the Ontime.
You can take a look in the midi ISR from the UD3:
https://github.com/Netzpfuscher/UD3/blob/master/common/ud3core/tasks/tsk_midi.c#L241
In essence you generate your pulses in the ISR and write the Ontime in a FIFO, you don't send them to the One-Shot timer. At the end of the ISR where all of your pulses are generated and stored in the FIFO you take the first item out of the FIFO and send it to the one-shot timer. (The coil fires one pulse) then you exit the ISR. The next time you do the same. The ISR is 10 times faster than your highest tones so you call the ISR at the worst case 10 times before a new value is pushed to the FIFO, so the FIFO will not overflow and the next pulse repetition rate can only as high as 10kHz so you have enough space between the pulses. You get Jitter on the pulses because timing for a single channel can be delayed until the ISR is often enough called. But it sounds good.
If you can chain timers you can use a second timer for the offtime. Which get started with the falling edge of the output of the one-shot timer, it contains the minimum time for a next pulse. If the offtime ISR get's fired you take a value from the FIFO, if its empty exit, otherwise load the pulse in the one-shot timer. Then you generate the pulses faster than the 10kHz from the sample ISR and still be safe not to overlap pulses.
If you need more help we can make a skype call, then I can guide you through my code.
Post by: Uspring on April 25, 2020, 01:00:19 PM
This also works for more than 2 voices with the caveat, that tick frequencies can become too large, implying too small burst spacings. From the point of view of musical harmony, these cases are somewhat exotic and probably uncommon. But tastes differ.
Post by: futurist on April 26, 2020, 01:37:40 AM
The first big problem is: Two pulses can follow each other very shortly. 1 "tick" is not enough time to ensure primary current has ringed down to 0. That means you have a high risk of hard switching on the next ontime (UD1/UD2 drivers always switch at the beginning of an ontime to start the oscillation and only after that first kick start using ZCS. UD+ (which I have) is even "worse" as it has a startup oscillator switching at least twice). This becomes even more of a problem when low notes (allowing looong ontimes) are mixed with high notes. Therefore a minimum offtime needs to be ensured between notes. How? Well I implemented three different ways:
1. Skip. If the next ontime is too close to the current, skip it.
2. Delay. Wait until the minimum offtime is over before generating the pending ontime.
3. Merge. If a ontime shall be generated, "look ahead" if another one is too close. If yes, merge them, meaning generate a pulse with the sum of both widths. I thought this should be the best sounding option.
This is polyphony on my coil, onetesla interrupter, UD+ with SKM400GB123DH6 halfbridge
It's crudely implemented, if second note plays when first is playing, the second note is ORed together but limited to some max. pulse width
Interrupter occasionally misses some notes, makes random pulses, but the actual result is decent and so far it isn't destroying IGBTs :)
https://highvoltageforum.net/index.php?topic=160.msg1049
Maybe in addition to limiting pulse width there should be some minimum dead time between pulses. If some pulses are omitted you probably wouldn't notice any sound difference
Post by: Max on April 26, 2020, 04:42:40 PM
Thanks for the replies and ideas!
@Netzpfuscher:Sorry for misunderstanding/misquoting your idea and thank you for the explanations. I tried to understand them and your code, unfortunately without much success. I'll have another look at it once I get the current changes to my software done (see below). If then I don't manage to understand your idea, I'll happily accept your kind offering for sykiping!
@Uspring:
Had that in mind, too, at the beginning (mainly because it simplifies the code). However to avoid too close pulses this would require to start any note in phase with all the notes that are already playing. This requires delays that increase with every additionnal note playing.
If you want to use the coil together with a normal synth like me it would probably sound pretty bad (some pieces/notes more than others) because your intonation is different
@futurist:I'd have to have another look at his code. I knew that ORing different notes together is the idea behind polyphony and that it works pretty well in quite a few coils. It was my idea, to, and it was what my code seemed to do. As I said, I couldn't really find a reason for the bad sound.
Edit: I overlooked your link. Interesting problem. I haven't had that on my old quick 'n dirty ATMEGA MIDI Interrupter and not on the Tiva one either. The ATMEGA one has probably played around 5 hours total and the Tiva (release version 1.1) around 2 hours. As I stated before I use MIDI files from various sources (whichever sounds best) and mostly unmodified.
What I did in the meantime... I mostly finished the work on the multiple coils part. You can now control up to 6 coils (won't increase it further) independently of each other. Simply select the coil(s) to which you want to send your next settings. In MIDI Live mode you can select for each coil to which MIDI channels it shall listen. More details about new features can be found on the release page (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v2.0-beta-1).
I looked into the Tiva USB functionality. In theory it is well possible to write software that makes it identify as MIDI device. In practice this is A LOT of work; you have to write your own USB stack since there's no MIDI-USB library available for Tiva. I don't know if I would get it to work at all and even if so, it would cost me days and days. Comparing that to the easy to use hairless midi<->serial and loopmidi solution its not worth the time at all for me.
More interesting is the EEPROM. This seems to be quite easy to use so I'll work on that in the next days. The idea is that you can change as much settings and limits as possible without reflashing the Tiva or Nextion. After this I may restart working on polyphony.
Finally I did a quick video demonstrating most of the new features (using a pencil that costs more than the whole interrupter ;D ). Note that in the microcontroller source code the max coil limit was set to 3, hence only three coils showing up in the GUI.
Kind regards,
Max
Post by: Max on May 06, 2020, 01:16:53 AM
This means many things that were defined at compile time can now be changed at runtime. F.ex. set the absolute maximum ratings for each coil, change display brightness, etc. In case anyone uses this interrupter and misses some settings, feel free to leave your feedback ;)
At this point I have pretty much everything completed that I wanted to do, and I like the user interface. I'd consider this release as ready to use with no known bugs or problems.
Only missing thing is ADSR... those values can't be changed at runtime yet. That aside, I can now have another look at Netzpfuschers polyphony code and maybe try to implement it.
Kind regards,
Max
Some examples of the new GUI. Note: If the Syntherrupter is configured with lets say 2 instead of 6 outputs, the outputs 3-6 and their settings won't be displayed.
Settings page for the tesla coils:
[ Invalid Attachment ]
Page for the user settings:
[ Invalid Attachment ]
A new keyboard...
[ Invalid Attachment ]
And brightness control
[ Invalid Attachment ]
MIDI Live Mode when configured to three coils only:
[ Invalid Attachment ]
Post by: Max on May 14, 2020, 01:11:36 AM
Thanks to Netzpfuschers explications I finally got some promising results for polyphony! As of now the interrupter is configured to play up to 4 notes on 4 independant outputs, making a total of 16 independant notes with ADSR.
It already sounds quite good, but there are still lots of problems to solve.
- I need to get the timers working as oneshot timers instead of PWM + ISR stopping the gimer after each pulse
- The code misses some notes; not exactly clear why.
- One midi file causes way too high ontimes, and prevents the interrupter from normal operation. Very strange... probably too many commands at the same time.
- Minor bugs...
Kind regards,
Max
Post by: Mads Barnkob on May 14, 2020, 11:26:23 AM
Thanks to Netzpfuschers explications I finally got some promising results for polyphony! As of now the interrupter is configured to play up to 4 notes on 4 independant outputs, making a total of 16 independant notes with ADSR.
It already sounds quite good, but there are still lots of problems to solve.
- I need to get the timers working as oneshot timers instead of PWM + ISR stopping the gimer after each pulse
- The code misses some notes; not exactly clear why.
- One midi file causes way too high ontimes, and prevents the interrupter from normal operation. Very strange... probably too many commands at the same time.
- Minor bugs...
Very nice progress, I am following this project with great interest in building my own version of it one day :) You are in a terratory where I have little to none experience and have failed to localize time to get it.
The notes you are missing, are those very short or very long notes? There could be some racing conditions at play...
It could also be related to the overflow of MIDI commands, I recall that I read about that being a problem with other MIDI interrupters.
How well does the same MIDI file scale on to lets say a small 300 kHz DRSSTC making 40 cm sparks compared to a 40 kHz DRSSTC making 4 meter sparks? There is differences in their ring-up times and thus it would be awesome to have some auto-scaling features to adapt on-time on the fly for the resonant frequency of the connected coil.
Post by: Max on May 14, 2020, 12:14:33 PM
Thanks! Since I only have one single tesla coil, resonating at around 65kHz, I can't test what effect such drastic differences have. However... The non-polyphonic release of my interrupter (https://github.com/MMMZZZZ/Syntherrupter/releases) is tested and works well, even with furious MIDI files. And it already supports what you thought to be useful. If you have a look at my video a few posts ago (https://highvoltageforum.net/index.php?topic=1020.msg7396#msg7396) you can see how to set different ontimes/duties for different outputs. This means that you can set 100us for coil 1 and 500us for coil 2 and the MIDI velocity of a note will be matched to the different range on each coil, allowing you to compensate the described effects.
Maybe one word about the third slider in the video, which became a button (visible in the screenshots in the post next to the one linked above). Constant duty is fine because it assures a pretty constant volume. However it causes rather weak arcs with deep notes, since the duty cycle gets very small. On the other hand constant duty leads to very weak high notes, since the ontime gets too small. Therefore the default mode is "auto", meaning that low notes will be played at constant duty, and high notes at constant ontime.
Remember, if you know the "safe operating area" of your coil(s), you can save these values in the settings, and you can enter whatever you want on the MIDI page, the Interrupter won't leave the SOA. Therefore its safe to play around with constant duty / constant ontime!
Considering the missing notes I don't think their length is the problem. To me it seems more like it simply misses the MIDI command because it's too busy doing other stuff. I "simply" have to improve the efficiency of my code.
Kind regards,
Max
Post by: futurist on May 15, 2020, 12:45:31 PM
I have one small and one medium sized DRSSTC, and friend has big CM600 coil so we could test the interrupter on 3 independent outputs
Where is the best to buy arm dev. board and display?
Post by: Max on May 15, 2020, 09:15:48 PM
Thank you! Looking forward to your experiences!
I bought my Tiva LaunchPad directly from TI: http://www.ti.com/tool/EK-TM4C1294XL#buy (http://www.ti.com/tool/EK-TM4C1294XL#buy)
Shipping is currently 7€. That's pretty high if you order one single dev board (I didn't... ;D ) The TI page says that aside from themselves only Mouser and Digikey have them in stock. I never had issues with mouser; prices aren't especially low, but ok. Their biggest downside for me is that they ship from the USA, which means around 20$ shipping costs. However, orders above 50$ ship free :) Can't say anything about digikey.
The Nextion Touch display can only be ordered from their site: https://www.itead.cc/nextion-nx8048t050.html (https://www.itead.cc/nextion-nx8048t050.html)
Actually I'd love to find an as easy-to-use alternative since their customer support seems to be pretty bad (never had to use it). However it seems like there is no real alternative out there; only a few more professional and way more expensive solutions.
Edit 2: You could actually buy the 7inch model (65€) instead of the 5inch one (56€). Both have the exact same resolution, therefore no changes to the GUI are needed. Depends on whether you prefer bigger buttons and fonts or a more compact interrupter :)
Edit: If I'm already writing here, I can report about my progress as well. I fixed the issue with the missing notes and I managed to assure the minimum offtime after each note. Sounded even better; I'm really happy with that :D . After fixing another issue, namely that all notes were assigned to the same channel, even if they came from different channels, I now get a fault interrupt. No real clue where that comes from, and it is rather annoying to debug.
Yet another edit: duty cycle limiting is actually not hard at all. Aaand the annoying bug is gone. I'll implement duty cycle limiting, allow in the GUI to modify the minimum offtime and then I think I'm done. It looks like the total voice limit lies around 16, maybe higher if time critical effects like pitch bend are not used. On a piezo it sounds good up to 4-5 voices; any higher is very noisy. This would mean that you can control up to 4 coils with 4 voices each.
I guess with some optimization effort it could be increased, but it would probably need significant changes to my code...
Kind regards,
Max
Post by: Max on May 18, 2020, 04:15:16 PM
Actually the 6 voices is not a hard limit and can be increased to whatever number you want (though I didn't test any further). The problem is that above 4 notes the sound quality suffers, at least on my piezo I used for testing (should be a bit better on a tesla coil). Looking at most midi files, you rarely see more than 4 notes for second voices, so you can still have a two voice melody.
I didn't want to offer binaries for other maximum voice counts, since that would multiply with the maximum coil count, both settings which have to be set before compiling.
Also included: duty cycle limiting, minimum offtime (to prevent that two pulses follow each other immediately and the driver (hard)switches while there's still primary current flowing).
I'll try to make a video with static load in the next days. However it doesn't sound better or worse than the short demo above. It's just not skipping notes anymore ;D
Edit: Well, that excitement didn‘t last for too long. I‘m missing data in some cases. Whether I use the 16 byte hardware FIFO, or a 128 Byte buffer, whether that buffer is filled by polling or by an ISR, whether I enable or disable compiler optimizations - NONE of all the combinations makes a difference, and I miss/overwrite every single time the same bytes. That makes me wonder if the issue is really due to my code or if it might be hairless midi<->serial... I‘ll check that tomorrow.
Edit2: Release is fine. Explanation in the next post.
Kind regards,
Max
Post by: Mads Barnkob on May 19, 2020, 09:26:06 AM
You are also at a high pace in new releases, my best advice is to slow it down abit and do sprints on very few features at a time, get it to work 100%, then move on to the next feature. Else you quickly end up in your current situation where you are not sure what effected what :)
Best of luck and really looking forward to see your final result
Post by: Max on May 19, 2020, 11:49:02 AM
While I couldn't hear any missing notes so far, I found out during the debugging process that the 16 Byte FIFO is actually too small (the FIFO overrun bit was set). Therefore I'll keep the bigger buffer. It costs a little bit of CPU time but it won't miss any data for sure. Maybe I'll have a look at uDMA to eliminate that additional CPU usage. However if by CPU is too busy there are many other more time consuming things to look at.
Oh, and I found another small bug in the MIDI processing which is actually there from day one, and through all the hours (!) of testing for v1, v2, v3 I never noticed it.
After some more testing with loads of serial data I'll update the releases.
Kind regards,
Max
Post by: Max on May 20, 2020, 12:15:43 PM
The impact of the optimizations was actually bigger than I thought (should probably have waited with my last reply...). I can now play 8 voices with less jitter than before.
This time I tested it pretty hard, passing all 16 MIDI channels to the interrupter, which should play on all 6 outputs around 6-10 notes from 4 out of the 16 channels (the other 12 were only to see if it processes the data fast enough) Result: noisy, but no missed notes. That noise increases with the output count, so you should use a Tiva firmware with as few outputs as possible. If you don't use one of the outputs, unassign all channels; this helps reducing the noise. With only one or two outputs, which will propably the case for most people, you can barely hear any noise.
I've successfully tested release v3.0.1 on my DRSSTC (static load) for over an hour with all kinds of MIDI files and I really like the way it sounds. I'll probably edit this tomorrow but as of now I think I'm pretty much done with the code. I do have some ideas for future improvements but honestly I'm too happy with the current state to start working on something new. ::)
This video demonstrates pretty much everything. Just to remember, this is an unmodified MIDI file I found when searching for the song. Simply pass the channels you like to the interrupter, and you get this. Many voices, fast notes, ADSR, effects. Note that I reduced the constant duty for low notes at around 01:00 to protect my poor breakers ;D
While the video above is for sure more impressive, I wanted to share this one too, because a) I have an earworm and b) I really like the staccato ADSR sound. The slight reverb comes actually more from ADSR than from the metal / the room.
I'm really looking forward to the next possibility to run the setup as tesla coil again, instead of cooking some steel...
Kind regards,
Max
Post by: futurist on May 21, 2020, 12:16:04 AM
Post by: Max on May 21, 2020, 07:46:28 PM
An interesting observation: While my oscilloscope tells me that duty cycle limiting works, there are some note combinations that cause really high peak input currents. I already noticed a long time ago (before this project) that same duty does not mean same power. So it could simply be a particular "bad" combination within the limits... I'm interested if this will cause bigger arcs, too. However, it looks like ironically, I will not be the first one to produce any arcs with my interrupter ::) It'll take weeks until I get access to a decent test location.
Edit: Just wanted to notify everyone that I rewrote the first post. It is an almost complete documentation of the Syntherrupter's features*. I'll add the missing bits over the next days.
*which it already was more or less for firmware v1.x, but that wasn't really helpful anymore.
Kind regards,
Max
Post by: Max on May 24, 2020, 12:12:36 PM
Unfortunately I have no MIDI cables or optocouplers I'd need for testing. So in case anyone has the motivation and materials needed, I attached the binaries.
Edit: Attachment removed since it has been published on GitHub. Please check the release page (https://github.com/MMMZZZZ/Syntherrupter/releases) for the current firmware.
Kind regards,
Max
Post by: futurist on June 13, 2020, 10:39:23 AM
What is the best way to power everything? USB or internal battery?
Do I need any additional switches, power switch, or safety switch for turning off outputs?
Before I do anything I have to ask my local machinist to cut out a hole in aluminium enclosure for the display
Post by: Max on June 13, 2020, 01:25:41 PM
The best way to power it is over USB. That can be your PC (500mA min!) or a powerbank. A normal battery is problematic since the Nextion display requires regulated 5V, otherwise you damage it! With this in mind I oped for the powerbank; cheap, regulated and with charge controller.
The software has a safety feature integrated which turns all outputs off if you hit the white background below the control sliders. If you don’t trust that you can of course add a safety switch which cuts the supply or the connection to your optic transmitter(s).
Although there is a standby function which turns off the display backlight, it is not a soft power off. So if you‘re using batteries, you need a power switch.
The hole for the display... yeah I wanted to do it on a CNC to get a nice chamfer around. But thanks to lockdown I ended up doing it by hand. Looks better than expected!
Kind regards,
Max
Post by: futurist on June 13, 2020, 03:42:50 PM
How did you cut hole for the display? Turned out very nice
Post by: Max on June 13, 2020, 04:26:50 PM
I used a dremel to cut a first window, leaving around 3mm to 5mm on each side. And then filed, filed, filed. First with a rough one, to remove the material, then took it with a finer to the final dimensions. Finished with 800 grit sand paper to break the edges.
Finally, if you have no chamfer you might want to paint that "vertical inner" surface of the hole in black. then it doesn't look as thick (I forgot to do it...). Material thickness is 3mm btw.
Kind regards,
Max
Post by: Mads Barnkob on June 22, 2020, 10:21:15 AM
But I can not get the 5.0" 800x480 version of the display, only if I take the 7.0" can I get that resolution. Would that work?
The Tiva kit seems to be the same price everywhere.
I like the screw fibre optic transmitters and receivers, so thought about trying out these broadcom ones, not cheap, but not SUPER expensive either. Mouser does not sell the IF-D97 / IF-E97 anymore :(
[ Invalid Attachment ]
Post by: Max on June 22, 2020, 11:02:24 AM
Yes, Tiva is pretty much the same price everywhere. Except that in the TI store you don‘t pay taxes. Don‘t ask me why. And it passed customs with no problems either. This however only makes sense if you order >2 boards.
I like the screw fibre optic transmitters and receivers, so thought about trying out these broadcom ones, not cheap, but not SUPER expensive either. Mouser does not sell the IF-D97 / IF-E97 anymore :(What a bummer. I haven't seen them anywhere else. Or at least not for <10$.
Oh I didn't know Mouser has Nextion displays - or at least a few of them. As long as your display is a genuine Nextion one (seems to be the case) and has a resolution of 800x480 it should work almost (!) out of the box. You have to open the Nextion file in the editor and change the device to your model. Since the resolution is the same, no other changes are necessary.
You‘re right, Mouser doesn‘t have the 5 inch version. The 7 inch version is from the "Enhanced" series (instead of the "Basic" series) which offers a few more features and costs ~20$ more. If you really want to get it as soon as possible no worries, AFAIK it will work just fine. Just know that those features (like GPIO pins or a RTC clock) are useless since the firmware is written for the "Basic" version which doesn't have them.
Otherwise I would recommend to order the display directly from the manufacturer. Saves you ~20$ for the 7inch or ~30$ for the 5inch display.
The Nextion Touch display can only be ordered from their site: https://www.itead.cc/nextion-nx8048t050.html (https://www.itead.cc/nextion-nx8048t050.html)
You can find them on ebay, however that are incompatible twins - always. They look the same but they're only meant for the chinese market and can't be easily programmed.
[...]
Edit 2: You could actually buy the 7inch model (65€) instead of the 5inch one (56€). Both have the exact same resolution, therefore no changes to the GUI are needed. Depends on whether you prefer bigger buttons and fonts or a more compact interrupter :)
Kind regards,
Max
Post by: Mads Barnkob on June 22, 2020, 12:33:51 PM
I will try it out with the 7" and just get it all from mouser for making it easier for myself. It is after all the opto parts that make up the biggest part of it anyway. Unless I find a cheaper alternative, not ordering right away :)
Post by: AstRii on July 02, 2020, 05:34:23 PM
I would love to build one, but before i go and buy the components i have a couple of questions.
I can't see a reason why not, but just to be sure, can you use a software like FL Studio to send the MIDI data to the interrupter? Or what software would you recommend?
You said the output pins from the board to the optical TX are 3.3V @2mA, so i guess i also need some transistors to switch the 100mA OPF1412T right?
Post by: Max on July 02, 2020, 07:04:55 PM
I can't see a reason either :) You can try it out before building one. Install the program "loopmidi" (Details in the first post. Maybe use CTRL-F to find it quickly) and check if FL Studio finds the virtual MIDI port.
You're right, the pins can only provide 2mA. In further revisions I might be able to increase it to 8mA, but not sure. So yes, you definetly need a driving transistor.
Kind regards,
Max
Post by: AstRii on July 02, 2020, 11:17:48 PM
Post by: Max on July 04, 2020, 12:17:47 AM
I released a new beta firmware. I won't be able to do any testing for a couple weeks but since there are no "safety relevant" changes, I see no risk in using it with a tesla coil. The only thing I do not know is if the new features work as expected.
The most important changes are support for MIDI "Expressions" and custom pitch bend ranges. Expressions are used for nuances, like crescendos (increase in volume). Some pieces set a custom pitch bend range f.ex. to perform larger "sweeps". Until now this sounded awful and made the file or at least parts of it completely unusable.
Of course, the additionnal MIDI UART is part of this release, too (see previous post (https://highvoltageforum.net/index.php?topic=1020.msg7796#msg7796)).
As always, the details are listed on the GitHub release page (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v3.1.0-beta.1).
@AstRii: Looking forward to your experiences with FL studio! :D
Kind regards,
Max
Post by: Max on July 09, 2020, 09:09:08 PM
As I said in my last post I currently do not have access to my interrupter, so I couldn't test anything. However, I found a spare Tiva LaunchPad so I can at least test with speakers.
First of all, the untested beta I released with the last post contains some dumb copy paste errors making it useless. I hope I fixed all of them by now (still can't test the MIDI input).
Just to be clear, the latest stable release is absolutely fine and contains none of those errors.
Now the interesting part. I added a new feature, stereo sound! You can place each coil with a slider between "left" and "right". If the MIDI file uses the pan command you can hear how the sound moves from left to right or vice versa. When testing it (with speakers), I liked it so much I wanted to build a second DRSSTC to get that effect ;D Ok, admittedly it is not better than normal stereo but still. Imagine up to 6 coils in a row and a "wave" of music going through them.
You can disable it if you want. In that case the coil ignores the "position" of the sound. This is the power on default.
Picture of the new menu with the slider:
While playing around with the code I found that pitch bend is actually not that smooth at all. I never really noticed it, but with the latest changes it got worse for some reasons. I realized quite soon that the way I generate the output signals was absolutely not "pitch bend friendly". So I rewrote it in parts and pitch bend is now as smooth as it can be. I think I managed to get an overall better sound quality but especially with many voices (and I mean full 8 voices on all 6 outputs) it may sound a bit worse in some cases. Shouldn't be a big issue though.
Since I tested it as good as I could I released a new beta. It still has the beta status because the MIDI UART is untested. As I said way back, I have no possibilities to test it. Other than that I'd consider it safe to use.
All details on the GitHub release page (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v3.1.0-beta.2).
Kind regards,
Max
Post by: TMaxElectronics on July 13, 2020, 01:20:59 AM
Quote
Ok i checked, FL Studio does recognize the virtual port. So i just bought the components from the links you provided
I just tried my Synth with FL studio and ran into a problem:
When playing midi with the default settings, the notes are off beat (in a random direction for each note), but that can be solved by switching Settings -> Audio -> Playback tracking to "Driver"
After that I have yet to find any issues.
Just thought I'd put this out there in case anybody else has that issue (i tried things for probably an hour to figure this out :P)
Post by: Max on July 14, 2020, 12:03:47 AM
There was one last thing left that allows a very easy and important optimization. Since the first v3.x.x release I re-calculated all notes for every single MIDI command - even if only a single note was affected. This of course is horribly inefficient since up to 47 notes are processed in vain. With the latest beta I finally fixed this and guess what - it made a big difference ;D
6 outputs with 8 notes each? Easy, no problem. Tons of CPU time left. So why not ... increase the note limit to 16. Yes, that's right, it is now possible to play 16 notes on each of the 6 outputs. However, this doesn't mean that 16 notes on each output make sense... Take your usual duty limit of 10%. That leaves only 0.6% duty for each note, or in other words: almost nothing. However, if you have a robust DRSSTC or even a SSTC which could handle 50% duty, the 16 notes could be useful.
Since the useful voice limit might be different for each coil, you can now set your own limit - ranging from 1 to 16 - under Settings -> Coil Settings.
Oh, and a higher number of outputs no more means noisier music. ;)
Details and Firmware as always on GitHub (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v3.1.0-beta.3)
In the next days I'll try to upload a video demonstrating 6 outputs with stereo.
Kind regards,
Max Zuidberg
Post by: Max on July 15, 2020, 09:35:15 PM
First video demonstrates "normal" stereo operation. The MIDI file had plenty of pan commands, letting the voices bounce around from left to right. The 6 outputs were configured to be evenly spread across the "left-right"-range. The resistors are there to connect the 6 outputs to the left and right audio input of my PC so that I can record the result in stereo.
While this is already quite fun to play with, you're actually a bit limited; many MIDI files do not play with stereo effects. Most of them simply place each channel somewhere around the center and that's it. To get those nice stereo effects without too much MIDI editing, I added some non-registered parameters (basically MIDI commands that are used to configure any configurable parameter of your synth. It's no more than "set ADDRESS to DATA"). These allow to map - for each MIDI channel - a note range to a stereo range. F.ex. the well known guitar in Thunderstruck plays notes from 59 (B4) to 71 (B5). This is my input range. Now I can define where those notes will end up. If I want them to play in the left half I set the output range to be 0-63. To play them in the right half the range needs to be 64-127. If you want the highest note on the left, and the lowest note on the right, you simply swap the range limits and set it to 127-0 instead of 0-127.
Note: Do not confuse this with the coil positions that you can configure on the touch display. Those positions define where each output "listens". What I discussed here is where the notes will appear. Both are independant from each other.
I wanted to upload a third video, demonstrating how a "rich" MIDI plays with 6 outputs, loading the interrupter with about 25 simultaneous voices. Unfortunately I goofed up the audio so I'll have to do that again.
If you want to use the stereo features described above, here are the non-registered parameters you need. If this is the first time you hear "non-registered parameter" you may want to check this tutorial: https://www.recordingblogs.com/wiki/midi-registered-parameter-number-rpn (https://www.recordingblogs.com/wiki/midi-registered-parameter-number-rpn)
| Parameter Function | NRP Number (Coarse) | NRP Number (Fine) | Data Entry (Coarse) | Data Entry (Fine) |
| Mode | 42 | 0 | X (don't care) | 0=Mapping off, 1=Mapping on, 2=Omni Mode |
| Input range | 42 | 1 | Upper End (0-127) | Lower End (0-127) |
| Output range | 42 | 2 | Upper End (0-127) | Lower End (0-127) |
I attached the modified MIDI file used in the second video. Channels 3, 4 and 10 were modified and passed to the interrupter. Since NRPs are manufacturer-specific, and since I chose a range that's not used AFAIK, the modified MIDI will play perfectly normal on any other synth or interrupter. The original file can be found here: https://bitmidi.com/acdc-thunderstruck-k-mid (https://bitmidi.com/acdc-thunderstruck-k-mid)
Edit: Finished the two missing features (NRP reset and omni mode) and released it as v3.1.0-beta.4 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v3.1.0-beta.4).
Edit2: If you wonder what that omni mode does, here's again Thunderstruck but this time with one channel in omni mode ;)
Edit3: fixed NRP table
Kind regards,
Max
Post by: futurist on July 18, 2020, 09:37:00 AM
Can't wait to test new features :D
I finally managed to finish mechanical part, now I have to wire everything
How do you connect 1414T transmitters (to what pins, how large is the resistor)?
Post by: Max on July 18, 2020, 11:42:49 AM
Congrats to the mechanical part. I‘d love to see your finished interrupter!
It‘s been quite some time since I made that little print for the transmitter. Here is what I remember:
The transmitter is just an infrared LED. Three of the four center pins are cathode, one is anode. From the datasheet I determined Vf and If which gave me a resistor value of 60Ohm when using it with 5V. Again, thats what I remember, you should check the values. Current was around 60mA so a BC546C was sufficient. This transistor has enough gain and speed for this application. Many other standard transistors should work, too. Final schematic: Resistor to 5V, Anode to resistor, cathode to collector, emitter to ground, base to a 560Ohm resistor which goes to the pin with the interrupter signal.
I use the 5V instead of the 3.3V because the 5V come directly from the USB port. The 3.3V are provided by an onboard regulator where I don‘t know how much additional current it can handle.
Kind regards,
Max
Post by: futurist on July 18, 2020, 03:06:21 PM
Duty cycle is very low so it could probably be powered directly from processor, but in any case I'll use external transistor
I'm little short on THT components, but I managed to find four old 2N2222 transistors, I'll post some photos later today or tomorrow
Post by: Max on July 18, 2020, 03:20:16 PM
Therefore I'm glad you still had those transistors! :)
Kind regards,
Max
Post by: futurist on July 19, 2020, 05:12:49 PM
edit: where do I connect LCD?
Post by: Max on July 19, 2020, 05:44:34 PM
@futurist:
You can see the PCB USB traces in the following documentation from TI, page 26: https://www.ti.com/lit/ug/spmu365c/spmu365c.pdf Hope this helps you.
Display connections and setup is described in the very first post of the topic, under "Replica with touch display".
Other news:
A new version of the Nextion Editor has been released (v1.61.1) which breaks the option to upgrade the Nextion firmware over USB. It's fixed in the source code but I didn't want to draw yet another beta release just for this fix.
The developper of SynthFont, the MIDI Software I'm using for years now, has offered to make SynthFont send MIDI directly to a serial port. No MIDI to USB converters, no MIDI serial bridges needed :D I really appreciate his support and initiative!
Kind regards,
Max
Post by: futurist on July 22, 2020, 12:33:12 AM
[ Invalid Attachment ]
[ Invalid Attachment ]
Turned out nice, can't wait for the next weekend :)
Post by: Max on July 23, 2020, 02:44:14 PM
Quote from: futurist
Turned out niceAgreed! I like those 4 transmitters in a row.
... and I didn't know that Broadcom, formerly Avago, once belonged to Agilent. Interesting how many companies are in some way connected to HP.
By chance I read about a MIDI feature called "running status", which is used by some MIDI devices to reduce the amount of bytes necessary to send. It is explained over here: http://midi.teragonaudio.com/tech/midispec/run.htm
While this is not important if connected to a computer (it's not used there since MIDI USB data rates make such tricks needless), it could be relevant for MIDI In which still operates at the slower 31250baud/s.
When reading about running status I realized that my code does not handle MIDI real time messages correctly. They would lead to missing or hanging notes. I didn't know that since I never used a MIDI program that sends them. However, i heard FL Studio does.
Support for running status and the fix for real time messages will be included in the next release.
Kind regards,
Max
Post by: davekni on July 24, 2020, 03:26:07 AM
Post by: TMaxElectronics on July 24, 2020, 04:48:34 AM
The midi out from hairless midi serial certainly does not use the running status (at least I have never noticed), neither does the USB audio implementation that I'm using for my interrupter (though the bandwidth of that is of course quite a bit higher :P ).
@futurist
Are those four tx modules all going to be used or are they just for future expansion? I'd love to hear some of the stereo effects with more than two coils. If it sounds cool enough I might just
Post by: Max on July 25, 2020, 01:53:30 AM
@TMaxElectronics: watching you... (https://www.youtube.com/watch?v=QCOXARv6J9k&t=1m36s)
@davekni: "running status" is not part of the USB MIDI specifications (at least that's what I read on midi.org). That's probably the reason why no MIDI program sends "incomplete" packages - which is more or less what TMaxElectronics said, too. A tool like hairless MIDI serial could reintroduce it, since it is "serial" MIDI and not USB MIDI anymore, but it doesn't.
My very first MIDI interrupter was able to parse MIDI0 files. I don't know where my MIDI0 files came from, but the few I tested didn't use running status... (Bad) luck I guess.
Kind regards,
Max
Post by: futurist on July 25, 2020, 04:22:11 PM
@futurist
Are those four tx modules all going to be used or are they just for future expansion? I'd love to hear some of the stereo effects with more than two coils. If it sounds cool enough I might juststealcoincidentally have the same idea for my midi stick :P
I have two coils, medium SKM400 halfbridge and small TO-247 halfbridge, so I'll definitely try the stereo option
Friend has CM600 coil and it would be great to test all three coils, but we have to find a place to do it
Post by: Max on July 28, 2020, 02:05:18 AM
*actually only futurist could do it AFAIK... ;D
Nextion source file with new sliders can be downloaded here: https://github.com/MMMZZZZ/Syntherrupter/blob/v3.1.0-better-sliders/Syntherrupter_Nextion/Syntherrupter_Nextion.HMI
The compiled Nextion file is attached below.
Kind regards,
Max
Post by: Mads Barnkob on July 28, 2020, 08:36:14 AM
I have just ordered all the parts I needed from digikey, since they are the only seller of the locking screw head opto parts with a good enough price to justify the import tax.
Here is the digikey order numbers if anyone else needs them
Dev board:
296-37267-ND
EK-TM4C1294XL
LAUNCHPAD TM4C129X EVAL BRD
Display:
1597-104990606-ND
104990606
NEXTION ENHANCED NX8048P070-011R
Optic transmitter:
FB162-ND
IF-E96E
LED FIBER OPTIC 645NM RED
Optic receiver:
FB124-ND
IF-D95OC
DETECTOR PHOTOLOGIC 5 TTL
Post by: futurist on July 28, 2020, 01:11:56 PM
*actually only futurist could do it AFAIK... ;D
I will, I didn't have any free time this weekend to play with the coil
I'm going on vacation Thursday and I'll try new firmware asap
Post by: Max on July 29, 2020, 05:23:35 AM
Today I tried some MIDIs and realized that it is pretty annoying to edit the MIDI files each time. It would be useful to enable and configure the stereo note mapping directly on the Syntherrupter. So I added a new page which allows exactly this: edit NRPs and generally send any MIDI command you want. Screenshot is attached below. Haven't yet created a release.
Other ideas I'll implement sooner or later:
- Make ADSR parameters editable. Together with this change I'd probably add some other features to ADSR like exponential decay.
- Create NRPs or SysEx Commands for all settings of the Syntherrupter. Allow import/export from/to PC. Instead of modifying ontime, channel assignments, etc for each MIDI by hand it will happen automatically.
- Make volume logarithmic as described by the MIDI standard.
- Allow to compensate the non-linear volume behavior of a tesla coil. This is independant of ADSR exponential decay and the logarithmic volume.
- Firmware version check. Enable/Disable functions based on firmware combinations.
- Something something I probably forgot.
I'll try new firmware asapGreat! Thank you.
I'm going on vacation ThursdaySince you're currently the only one who could have played with real tesla coils, I don't like this for sure. However I hope you'll enjoy it! ;)
Looking forward to get this put together :) I must say that the Omni-mode is what I have dreamt about for years, I am really looking forward to use that feature (and not so much that I now have to build 6 identical coils)Honestly it already works pretty well with only 4 coils. However, having played with those features myself, I have to build 6 identical tesla coils, too. One day... ;D Maybe smaller SSTCs. Then I could even build 12 coils 8) Oooh so many ideas, so little time...
Kind regards,
Max
Post by: futurist on July 29, 2020, 06:09:14 PM
I'll try new firmware asapGreat! Thank you.I'm going on vacation ThursdaySince you're currently the only one who could have played with real tesla coils, I don't like this for sure. However I hope you'll enjoy it! ;)
By vacation I meant going home :) Now I have two tesla coils to play with
Post by: Max on July 29, 2020, 10:00:44 PM
Once I have the feedback for the sliders I'll throw out another beta release so that you can play with the NRP editor, too. It should make experimenting a lot easier.
While I give my best to keep the user interface as intuitive as possible I'm starting to think that I'll have to write a serious manual sooner or later... Again, any feedback is highly appreciated. Especially since you can play with the UI without buying any hardware ;)
Kind regards,
Max
Post by: futurist on August 03, 2020, 10:05:59 AM
/>
Duty cycle max. 5 %, max. on-time 300 us
I'm still getting used to UI, polyphony will probably sound nicer if I increase max. duty cycle
Sliders (unfortunately youtube rotated video)
Post by: Max on August 03, 2020, 04:31:04 PM
Thank you for the video. Unfortunately my timing is horrible: Today I finally got access to my interrupter, so I could play around with the sliders, too. Feels okay to me, but I added a rounding feature (value only increases in steps of 5 or 0.5), which gives a more "stable" feeling. How do they feel to you? Do you find it difficult to set the values you want?
You made me realize that the name "Max. Ontime/Duty" on the MIDI Live page is rather confusing, so I renamed them to "Note Ontime/Duty", which should be clearer.
Now concerning the strange behavior in your first video: I couldn't really find a combination that reproduced the behavior, therefore I'd ask you to tell me
- Which values you set on the MIDI Live page (Note Ontime/Duty) ("Screenshot" might be fastest)
- Which values you set on the "Settings->Coil Limits" page (Coils min/max settings) ("Screenshot" might be fastest)
- Link to the MIDI file
- List of the channels passed to the interrupter, and, if not saved in the MIDI file, the program number of each of these channels.
Since I was able to test everything today, I published Beta 6 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v3.1.0-beta.6). It includes the NRP editor, and the sliders futurist already played with. Oh and I kinda verified the running status feature, and it worked as expected.
Kind regards,
Max
Post by: futurist on August 04, 2020, 10:48:35 AM
You're right about min. on-time, I have 30 us min. on-time on onetesla interrupter. Do you plan to add min. on-time setting?
Can you suggest max. duty cycle and min. off-time?
Onetesla interrupter doesn't have duty cycle limiter and I didn't blow up the bridge. Here is same MIDI played with onetesla interrupter
/>
Currently I have max. on-time 300 us, min. off-time 0 us and max. duty 5 %. I'm waiting for wind and rain to stop to test it further
Post by: Max on August 04, 2020, 02:08:07 PM
As I said I'm still getting used to UI but for now everything works nicely and it isn't difficult to set the exact values I wantHappy to hear that! :D
Min ontime is planned, but as part of a more advanced feature (see https://github.com/MMMZZZZ/Syntherrupter/issues/5 (https://github.com/MMMZZZZ/Syntherrupter/issues/5)). It‘ll be interesting to get this to work with the duty cycle limiter...
This means that it will take me quite some time.
I‘d GUESS that you‘re around 20% duty. That’s a pretty common value for MIDI operation - especially with such high pitches like in Popcorn.
10% is commonly assumed to be safe for DRSSTCs, and if your peak current is not at the very edge of what your IGBTs can handle, 20% should be ok. But keep an eye on the temperatures! IGBTs, wiring, MMC and inner turn of the primary tend to get hot.
Another thing you might consider: my DRSSTC handles 25% duty without problems, but my fuses don‘t. For single phase input I have the limit at around 8%.
For the min offtime you have to watch your primary current with your oscilloscope and see how long it takes the primary current to ring down to 0 after the ontime ends. It depends on so many things that I cannot estimate it for you. It‘s like asking „at which ontime will the OCD trip“.
The purpose of the min offtime is to prevent any ontime while there‘s still current from the last one. Since two ontimes can follow each other with only microseconds inbetween, you could be hard switching at peak current otherwise. Pretty much all drivers switch „hard“ at the beginning of an ontime to get the oscillation started (and thus receive feedback).
Btw yesterday I finally found a way to test the MIDI In feature but it didn‘t work. However, I‘m not sure what‘s the reason. Looking at the serial data with my scope I don‘t recognize any MIDI commands... I‘ll let this aside for now, make some last improvements to v3.1.0 and start working on the feature mentionned above.
Edit: I attached "my" Popcorn MIDI file. Haven't found a better version yet. The only thing I modified are the MIDI Programs to use the ADSR curves I liked. For this reason you should set the Note Ontime to 1/3 or less of the coil's max ontime. If this is too low for your coil, you can increase it, but this will affect the sound (probably not much). Except for the percussion channel 9, you can pass any of the other channels to the Syntherrupter. Even all if you like.
Oh... and one thing you didn't mention in your last reply: To what value did you set the MIDI Voices limit on the "Settings->Coil Limits" page? It's the number of notes the Syntherrupter will at most play simultaneously on that coil. If you have no idea what value you should chose, 8 is a good start (and the default value I think).
Kind regards,
Max
Post by: AstRii on August 05, 2020, 08:01:11 PM
(https://scontent-dus1-1.xx.fbcdn.net/v/t1.15752-9/117014555_290451172053492_344595119118117971_n.jpg?_nc_cat=104&_nc_sid=b96e70&_nc_ohc=JuPrZz81rkIAX90Ixjo&_nc_ht=scontent-dus1-1.xx&oh=c1257bf70b0e5cda8545dd08d1e349b7&oe=5F516AD9)
I tried my DRSSTC I on about 50% the power, since it's already so loud it can be heard in the whole street, soon i wanna try it on full power.
Though i think there are some glitches or maybe they are features and i didn't fully understand the GUI. I hope i can provide some further feedback soon.
Post by: Mads Barnkob on August 06, 2020, 10:51:43 AM
Finally! Guys i recommend you to buy the display from mouser or some other local store, i waited for almost 3 weeks for it to arrive, but it's finally here. It works like a charm. I need to find some nice enclosure for it. Thank you Max for sharing the project with us! :)
(https://scontent-dus1-1.xx.fbcdn.net/v/t1.15752-9/117014555_290451172053492_344595119118117971_n.jpg?_nc_cat=104&_nc_sid=b96e70&_nc_ohc=JuPrZz81rkIAX90Ixjo&_nc_ht=scontent-dus1-1.xx&oh=c1257bf70b0e5cda8545dd08d1e349b7&oe=5F516AD9)
Did you make a output board yourself? Where you have the two optical emitters sitting.
Post by: AstRii on August 06, 2020, 12:59:03 PM
Yes i quickly designed it in EasyEDA. My previous interrupter was a mess, and i actually even fried it because of it. So i wanted a clean build with minimum wires, hence a PCB was born :)
I added some extra headers to connect some switches for safety and LEDs for indication.
(https://scontent-dus1-1.xx.fbcdn.net/v/t1.15752-9/117304619_242809933367198_8254849614620986566_n.png?_nc_cat=102&_nc_sid=b96e70&_nc_ohc=Kj_tdTUqZ9wAX_SHZ9B&_nc_ht=scontent-dus1-1.xx&oh=e6d4b579500bd9333a8214f482bb69a4&oe=5F507CE4)
Ordered from JLCPCB, it had arrived in a few days :)
Post by: Max on August 10, 2020, 02:07:26 AM
Yay, another one working (although not very hard yet ;D )! How much work was it to synchronize the audio track with the MIDI track? Oh, and since you're using FL Studio, could you have a quick look at the hairless midi logging to confirm that FL Studio actually sends MIDI Realtime messages (and thus that the Syntherrupter is handling them correctly)? Thanks!
Cool idea with the board! If there's a lot of interest, I can try to design one, too. Probably two versions; one like yours with a header only for the interrupter signals, and one that directly connects to the LaunchPad, which would allow for a very compact design.
Last week I found out by chance that I do have all the parts to connect my Syntherrupter to the MIDI Out of my keyboard. Aaaaand it didn't work. I'll have another look at it next weekend.
From now on I'll release the binaries for all the compatible touch screens. This not only includes the more expensive ones that Mads ordered, but also the cheaper ones. What does this mean? Nextion is in fact just rebranding displays from a company called TJC and asking at least 50% more for the same modules. Of course they prevent you from flashing Nextion firmwares to TJC panels and vice versa. But they can't prevent you from using the TJC version of their editor to compile a firmware for TJC panels. Long story short, with release v3.1.0 (non-beta ;) ) I'll provide the firmwares for all of the following displays. You can now buy almost anything that sound like it could do the job ;)
- TJC 5" Basic TJC8048T050_011R
- TJC 7" Basic TJC8048T070_011R
- TJC 5" Enhanced TJC8048K050_011R
- TJC 7" Enhanced TJC8048T050_011R
- Nextion 5" Basic NX8048T050_011R
- Nextion 7" Basic NX8048T070_011R
- Nextion 5" Enhanced NX8048K050_011R
- Nextion 7" Enhanced NX8048T050_011R
- The R at the end of the model number indicates that it is a resistive touch screen. Some of them are also available as N or C version. N means no touch at all (unusable for Syntherrupter) and C is capacitive touch screen, which might not work near a tesla coil. Resistive touch is "noise immune".
- I found out that Nextion/TJC changed the actual LCD module in their panel and the backlight is now a lot weaker. Since the Syntherrupter probably won't be used that often in plain sunlight I think it's not a big issue. Just wanted to let you know.
- Some of the ebay/aliexpress panels that are listed and shown as Nextion panels - with the nextion model number - are actually TJC panels. Simply try both firmwares if one doesn't work ;)
- Often the _011R suffix is not part of the item description; its rather tedious to search for these displays on aliexpress and I'm still asking around for the easiest and cheapest way to get them.
- The Nextion "Intelligent" series and the TJC X3/X5 series are not supported.
The release will be published soon; I still have to write the release notes.
Kind regards,
Max
Post by: AstRii on August 13, 2020, 02:09:13 AM
If you find the correct MIDI tracks, it's not hard to synchronize them, unfortunately majority of downloadable tracks are totally off the correct tempo and sometimes even the notes are all wrong! I usually download a MIDI track from somewhere and the vocals from YouTube, if the MIDI track has correct tempo, then it's a matter of one minute to sync them in FL studio. If the tempo is incorrect, it can be adjusted in MIDI Editor or FL Studio itself, so it takes a couple of more minutes. Sometimes the tempo is correct yet the notes are played at the wrong time anyway, in that case i adjust the timing of each note individually and that can take few hours.
I will check the hairless MIDI as you asked, when i will run the coil again. In a few days probably (I cannot run it anytime i'd like thanks to my neighbors).
The interrupter board as a shield for the LaunchPad is such a cool idea, it's a shame that i didn't think about it when i was designing the board, it would make it so much more compact and robust.
Post by: Max on August 13, 2020, 07:02:24 PM
Edit: Idiot. Forgot to mention the most important change since the last beta release: MIDI In finally works. I had yet another stupid copy paste error, that's now fixed.
@AstRii
Interesting that some MIDI files are "out of the box" synchronized with the audio version, or almost synchronized. I expected that you'd always have to adjust it note by note. This actually motivates me to try it one day...
Kind regards,
Max
Post by: AstRii on August 14, 2020, 01:04:06 AM
Also i noticed some strange behavior of the Syntherrupter:
On this video i scoped the interrupter signal for the coil.
You can see at the start i set it up to maximum ontime of 20us (Those blue cursors on the scope are 20us apart). Which seems to be working fine, but at about 20 seconds into the video, i changed the duty cycle.
And as you can see, the ontime of 20us is no longer applied. Seems weird to me, i thought the maximum ontime there is to set the maximum limit that the coil will never exceed, even if the maximum duty cycle is high.
I thought, that when the coil has the chance(allowed duty cycle) to use the maximum ontime, it will use it, otherwise it will restrict the ontime to keep the duty cycle limited.
Yet here it seems like it totally ignores the maximum ontime and it's only focused to keep up with the duty cycle.
Am i missing something?
Post by: Max on August 14, 2020, 02:12:16 AM
Considering your video: you’re not on the latest firmware; I changed the naming of the values in your video because they’re quite misleading. What you set on the MIDI Live page is the value a single note will have if it’s velocity and the channel volume, etc are at 100% (that’s why I called it „max ...“ first). But since ADSR parameters allow volumes of more than 100% those values can be exceeded. In newer firmware versions those values are called „Note Ontime“ and „Note Duty“. I‘d have to check the release notes to see in which beta I changed it. Somewhere in the last two weeks.
Why do you have two sliders? Well, the Syntherrupter will use whatever value will result in the highest ontime. Why would you want that? Explanations below.
What you thought it was is what you specify under „Settings->Coil limits“. The values on this page are the ones that wont be exceeded under any conditions. You might want to read the first post of this topic again; I rewrote it a couple weeks ago, aiming to explain this a little more. It‘s not complete, though. If you did read it and misunderstood it, I‘ll happily take suggestions on how to make it more clear.
(Here come the more in-depth explanations about what the settings and the Syntherrupter does)
Finally, let me talk about the note duty setting on the MIDI Live page (NOT the duty limit under Settings->Coil Limits!). The idea was that if you have a pulse skipping driver like UD2.9, UD+, SimpleDriver, etc, low notes could use this. High notes easily sit at around 1000Hz, where 100us already equal 10% duty. But for low notes, in the 100Hz range, 100us is nothing (1% duty). For this reason I thought it might be useful to let them play at a constant duty instead, f.ex. 5%, which would give 500us ontime at 100Hz. This will give a lot more intense streamers.
On the other side, you don‘t want high notes playing at the same duty as low notes; it makes more sense to play them at a constant ontime, especially since the ontime determines the note volume.
Combining these two things together gives us the following: low notes should play at constant duty, because constant ontime doesn‘t give intense streamers. High notes should play at constant ontime, because constant duty wouldn‘t allow intense streamers and the volume would change too much from note to note*. When should it change between both modes? Quite simple: at the point where constant ontime and constant duty would lead to the same settings. Let‘s take your example of 20us and 2.8%. We want the frequency at which 20us would give 2.8% duty. Since f * t_on = d => f = d / t_on = 2.8e-2 / 2e-5s = 1400Hz. This means that notes above 1400Hz will play with 20us ontime (leading to duties higher than 2.8%), and notes below 1400us will play at 2.8% duty (leading to ontimes higher than 20us). If you change the volume mode from Auto (what i just described) to „relative“, all notes will play at constant duty, and in „absolute“ mode all notes will play at constant ontime. Note that this button will disappear in future versions. If you look again at the math above, you might see that a duty setting of 0 implies that all notes are played at constant ontime (the crossover frequency would be 0Hz which is lower than any note), and a ontime setting of 0 implies that all notes play at the given duty value (crossover would be at infinity, which is slightly higher than most tones). Therefore a additional mode button is not required and you can leave it on auto.
Just as a reminder: everything I described in the last paragraph, about constant duties, ontimes etc happens within the range of the coil limits mentionned above. The coil limits are independent and applied at the very end of the „chain“**. The values discussed here are the starting point. Then they are multiplied with the note velocity, channel volume, channel expression, maybe stereo (all the values ranging from 0 to 1). On top of this are the time critical effects, namely ADSR and modulation. After all these effects are applied the „MIDI stuff“ is done. All commands and settings are applied; we can calculate total duty at this very moment, and, if exceeding the limit, multiply the ontime of every note gets with the same factor so that the total duty equals to the coil limit. After this the „final“ ontimes are checked against the coils max ontime limit.
All of this happens independantly for each coil.
* This is less of an issue with low notes. At higher ontimes the volume doesn‘t really increase anymore; only the sound gets „fatter“.
** I know I should draw a block diagram of the whole thing... and write a manual for it. But time...
Hope this cleared things up!
Max
Post by: Max on August 15, 2020, 12:28:18 PM
Edit: Fixed. https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v3.1.1 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v3.1.1)
I released it as new version because I changed the Tiva Firmware. As I described above it wouldn't have been possible to recover from the bad Nextion firmware by updating to a new one over USB (only via SD card) because you can't enter the update mode. With this release the microcontroller automatically enters update mode if the nextion firmware doesn't respond within 3 seconds.
Sorry for the inconvenience.
Max
Post by: Max on August 16, 2020, 05:13:19 PM
If you drastically reduce the BPS, e.g. from 1000Hz to 100Hz, the output can go high for a whole period, meaning for miliseconds (!). Since it is a hardware bug* none of the safety measures can prevent it.
Until I get it fixed, don't use Simple Mode. MIDI Live mode generates signals in a completely different way. Therefore it can't have this bug.
* Some timer registers don't synchronize the way they should. That causes glitches when making bigger jumps which happens if you sweep quickly though a frequency range. That's why it took me so much time the first time to "fix" it (rather mitigate it). I'll replace the whole stuff by the same code I use for the MIDI Notes. That's a complete overkill but at least it's been reliable so far.
I'm very sorry for this.
Max
Post by: Mads Barnkob on August 17, 2020, 08:25:24 AM
The thing that never ever should occur has occured. AstRii found a critical bug in Simple Mode that causes WAY too long output pulses. It is almost the exact same issue I had with v1.0, and that I fixed after lots of work in v1.1. Although I'm sure it was gone, it's back for some reason. Probably since v2.0.
If you drastically reduce the BPS, e.g. from 1000Hz to 100Hz, the output can go high for a whole period, meaning for miliseconds (!). Since it is a hardware bug* none of the safety measures can prevent it.
Until I get it fixed, don't use Simple Mode. MIDI Live mode generates signals in a completely different way. Therefore it can't have this bug.
* Some timer registers don't synchronize the way they should. That causes glitches when making bigger jumps which happens if you sweep quickly though a frequency range. That's why it took me so much time the first time to "fix" it (rather mitigate it). I'll replace the whole stuff by the same code I use for the MIDI Notes. That's a complete overkill but at least it's been reliable so far.
I'm very sorry for this.
Max
There will always be errors in software, especially when you have such a wide range of user inputs available.
Good job keeping the development going at this pace, but always give your self some time to let it all settle. I do not know how much about software development you know, but using sprints and iterations is a great way to implement one function at a time or fix one bug at a time. The idea is to work on very small scopes, but take breaks in between to allow for bug finding/tracking
I received all my parts for the syntherupter and last night I ordered a enclosure for it, it will be pretty epic :)
Post by: AstRii on August 20, 2020, 01:06:00 PM
I filmed a video about how to create playable MIDI files for a (DR)SSTC. Of course, i'm no musician, this is probably not a correct way of doing it, but it has worked for me to edit almost any song i wanted to be playable on an SSTC.
Max's Syntherrupter handles MIDI very well, so perhaps this can help some of you to edit songs which you wanted to play :)
Post by: Max on August 20, 2020, 02:02:06 PM
I don‘t agree with your statement that usual DRSSTCs aren‘t able to handle multiple voices. 4 voices should be easily possible on most coils. I can only recommend you to play around. At least in MIDI Mode the safety measures are working, so there‘s no risk in playing 8 or more voices on your coil.
The reason you hear most tesla coils playing only a single voice is because there haven‘t been many polyphonic interrupters available.
Edit: The video embedded in my first post here (I Want It All) has multiple voices (around 6 I think), and the duty limit was ~10%. The ontime might not have been high enough for actual streamers, but still.
Another note considering MuseScore: it is a great source for sheets music but not so much for high quality MIDIs. The reason is that they‘re computer generated based on the sheets and often lack nuances (every channel plays at the same, constant volume). Additionally they had to put the download function behind a paywall.
My top sources for quality MIDI files are:
- http://bitmidi.com (http://bitmidi.com)
Based on a 3GB MIDI collection someone posted on reddit. Of course it contains a lot of junk, but a lot of good stuff, too - from classic symphonies to Despacito. Search function ist not great. - https://mydwn.cx/kar-n/ (https://mydwn.cx/kar-n/)
This is the file server behind miditheka, which is pretty shitty to use (tons of ads and waiting times). However the collection is great. Well sorted, and with MIDI files I haven‘t found anywhere else. - http://en.midimelody.ru/ (http://en.midimelody.ru/)
A smaller collection, mostly high quality. Again with some files I couldn‘t find elsewhere. - http://www.vanbasco.com/ (http://www.vanbasco.com/)
This website has a search function for MIDIs. If you can‘t find a MIDI file in the collections above, sometimes this site can help you to find a site that google would never find.
Max
Post by: AstRii on August 20, 2020, 04:18:31 PM
Post by: davekni on August 21, 2020, 03:25:17 AM
Post by: Zipdox on August 22, 2020, 10:21:42 PM
Post by: Max on August 22, 2020, 10:59:55 PM
@Mads: I completely forgot to reply to your answer, sorry. I don't follow a particular developpement strategy. When I start working I usually have a list of features I want to implement which I do one by one. When I've finished "enough" features I start with testing them. This usually means that I use them with a couple different MIDI files, and try to verify the edge cases, too. After debugging them the cycle begins with the remaining features of my todo list. If I have enough verified features together which I think you should/want to have, I create a release.
Yes there will always be bugs that I haven't noticed or things that are missing. The idea is that I get the "core" extensively tested so that I (and you) can have confidence to it. This allows me to work on more complex features that are more likely to have bugs without having to fear I'll kill someones coil. It also means that I don't have to verify each release for hours with my scope attached to it, doing all kinds of duty, pulse with, ... measurements.
And it means that it's no risk for you to try any new (beta) release; worst case: unusable, but not dangerous.
So IMO it's no big deal if there's a bug in the UI, the MIDI processing, etc. Happens. But the core really shouldn't have had one - not such a severe, frequent and known(!) one. I can't remember enough details about the verification of v2.0 to find the reason how it happened. The only thing I can say is that I didn't test Simple Mode afterwards anymore since there weren't any changes (thus no chance for me to notice it after failing to notice it in first place). With v3.0.0 MIDI Live Mode got its own, new "core" that allowed polyphony, which again was heavily tested before releasing. And at least in that case it seems like I've done my job right. No critical bugs so far, only a minor issue with the duty limiter which reduced the ontime too much.
@davekni: That's something I wanted to do, too. Please keep us updated if you have any data about the sound impulse!
What I started in the meantime is by far the biggest change to the microcontroller code I've done so far. Basically I reordered and modified everything. GitHub says: 43 files modified, 2250 new lines, 1522 lines removed (https://github.com/MMMZZZZ/Syntherrupter/compare/master...dev) so far. The funny thing: pretty much all of this happens "under the hood"; nothing you'd notice. Maybe performance will even be a little bit worse.
And why then? Well the previous structure was somewhat limited, especially not capable of running different modes at the same time (more about that below). Quite a few parts had grown to the point where they really should've been rewritten.*
Sooo what will you notice once I get this done? The critical bug in Simple Mode will be gone forever. Aaaand you can keep modes running in background by holding the Return button on the touch screen. Why would you want to keep Simple Mode running when switching to MIDI Live mode? No reason. But I have ideas for new modes that would be interesting to run in parallel f.ex. with MIDI Live Mode:
- MIDI File Mode: playing MIDI files from an SD card. Set up MIDI Live Mode and switch to MIDI File Mode to
- Lightsaber Mode (thx Netzpfuscher for the great idea): Use a lightsaber with an accelerometer to make Syntherrupter generate the according sound effect. You have to run this while playing Star Wars MIDIs!
- (far future:) Audio In: convert an Audio signal to an Interrupter signal
However now there's a common "core" for all modes which basically contains the polyphonic signal generation from the MIDI Live mode. Instead of being tied to MIDI Live Mode and its MIDI notes, the core presents a uniformed interface for all modes. Every mode can add or remove a tone. This separation allows that all modes can independantly of each other add tones to the common core and thus run "in parallel". Additionally this "core" runs for each coil independantly. That's most of the explanation why so much of the code base changed: migrating from "one loop per mode that handles every output" to "one loop per output that handles every mode" is like transposing a matrix. Same data but pretty much everything got a new place.
* Footnote to make this post even more unreadable: Remember when I said that you can't use direct MIDI In and MIDI over USB at the same time? That was because both UARTs ("Serials" for the Arduino fans) wrote to the same buffer. Why? because it was easier. Another "easy" thing that was not good: the whole UART hardware interfacing (interrupt handling, ...) was part of the MIDI class. All of this got replaced by a clean UART class, where each UART object has its own buffer. The MIDI class has a list of all buffers that could receive MIDI data and handles each of them independantly. No more mixing of data that doesn't belong together.
Kind regards,
Max
Post by: Max on August 25, 2020, 01:47:53 PM
And here's the story:
- Audio quality was a bigger concern for me because the code got quite a bit more complex. So I spent some time on testing and optimization. Turned out to be okayish, but honestly not as good as I wanted. The surprise for me: it's pretty much exactly as good as the old code (v3.1.1). I never really noticed it but when you're simply holding a chord on a keyboard, it's not a "consistent" sound; it sounds more like if you have some interference. I already have ideas on how to improve this. Overall it will cost more CPU time but the load gets better distributed over time, preventing the time critical sound generation from being blocked/delayed.
- Although I pretty much copied the signal generation from the well-working MIDI, duty limiting got more complex. What previously were less than 10 lines of code are now almost 40 lines. After lots of refining it seems to work well but maybe I'll replace it in the future with another limiting method.
- Oh, something I forgot in my previous post: I implemented basic support for noise. I mean, controlled noise like for percussion. It's still completely untested and honestly I'm curious if this works at all.
- Although I have archieved the main goals for the redesign: new core, Simple Mode bug gone, maintained audio quality, I'll take more time til a release. I haven't verified anything with an oscilloscope yet and I feel like this needs A LOT of testing to make sure I catch every possible edge case, glich and bug. And I'll only start with testing after I've finished the major changes mentionned above.
- It should be easy to use. I had a look at the nRF24 but that thing is a beast! Way too much to configure to get the thing working. Yes, there're Arduino libraries but I don't have an Arduino and I don't want to migrate a library to a new platform. Something like the HC-05.
- Be able to work "reliably" near a tesla coil. I honestly have no idea how much of a problem this will be or not. I hope it wont - especially since I do not need a high data rate. even the basic 9600baud/s should be more than sufficient.
- It would be great to have one receiver for multiple transmitters. Two, three people with lightsabers, each one sending its data, and one receiver connected to the Syntherrupter.
- Easy to obtain and not too expensive. Of course this is a feature everyone with a Syntherrupter should be able to get and I honestly don't plan to implement 10 different receivers. Since the Syntherrupter itself is by no means a cheap device I really want to keep the price for additional features as low as possible. Some transceivers cost 10$ or more which sums up pretty fast, considering you need at least two, and possibly want 3, 4, ...
Btw. I'm seriously thinking about how I could make the Syntherrupter more affordable. The plan would be to get the cheap chinese version of the display and order only the TI microcontroller instead of the whole developpment board. The downsides: you have to order the display over a third pary firm because they're available in china itself. This makes much more sense if you order a couple of them. They'd probably be <20$ each, possibly getting the BOM costs for 1 Syntherrupter below 50$.
Programming the microcontroller wouldn't be a huge issue since it comes with its own bootloader (looks easy to integrate).
Oh, and ofc this would require the design of a custom PCB for the microcontroller... So nothing for the next weeks, but possibly for the future.
Kind regards,
Max
Post by: Hydron on August 25, 2020, 03:18:21 PM
Post by: Max on August 30, 2020, 10:21:38 PM
@Hydron: Thank you for the suggestion! I never really considered them but they do look quite powerful! Immediately ordered a couple.
Now considering my progress over the last days... I'm getting somewhere but I still do not like it. I have the feeling that I'm very far away from "KISS" and it hasn't got easier to debug. At the moment I have some kind of overflow issue when the Syntherrupter receives A LOT of MIDI data. Haven't found the reason yet.
I thought I'd create a more powerful code base but at least for now the "new possibilities" vs "complexity, efficiency" tradeoff does not look right to me. Considering efficiency: It bugs me that I can't do more in hardware; I feel like I'm not using the full potential of my microcontroller. At the moment I'm thinking about how I could use the tons of RAM this microcontroller has (256kB)... Does anyone know some good sources about synthesizer? There must be better ways to do it than what I'm currently doing...
Long story short it will be quite a while til the next update. Therefore I updated the first post in this topic, the GitHub Readme, and the v3.1.1 release notes with a big warning at the beginning. Maybe there will be a v3.1.2 disabling simple mode - just in case. What do you think?
Kind regards,
Max
Post by: Max on September 01, 2020, 03:56:20 PM
What's the easies way to get rid of a bug? Rewrite from scratch. In this case I replaced the array of MIDI notes by a doubly-linked list. Note-array-related bug gone 8) (And efficiency inceased)
More interesting: I pretty much solved the issue with the audio quality. I thought I'd generate the tones in a smart way, but actually it didn't have any advantages over the most basic way to do it. Only the disadvantage of worse audio quality. Long story short: tone generation got simpler, faster, better ;D
As TMaxElectronics commented: "now it sounds more like mine". Although you'd need at least six of those...
Since the code is stable enough to pass my MIDI torture tests, I'll verify the output signals with my scope in the next days; the final step before the next release. At least that's what I hope.
(The sceptical thoughts of the last post remain; I think quite a few things could be done better, just don't know how. But for now, we're back to "good enough" ;) )
Kind regards,
Max
Post by: Max on September 03, 2020, 08:35:29 PM
But wait, there's more. The actual reason for my tripple post is the release of v4.0.0 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.0.0). Yes I do feel confident enough to release it. While I haven't found any new bugs, there might be a ton of them hidden in some dark corner... This code simply has not the tens of hours of testing and evolution behind itself as the old one but we'll get there.
Additionally, there's the issue with my scope... I wanted to verify the duty limiter and all I got was this. Long story short, I verified it via the average voltage function which looked like it worked correctly and actually with the brightness of the LED which is a pretty good indicator whether the duty changed or not. However I don't consider either one as truly reliable test. It looks like it works - no more, no less.
As always, the release notes contain all the changes I could remember, you should read them :)
Edit: It helps to attach the scope pictures... Look what happens with the duty displayed in the bottom left corner. The signal is only slightly shifted such that the pulse at the left leaves the screen.
... the forum gives me an error because the pictures are ".jpeg" instead of ".jpg"? Really...? ??? Oh and, yes, when you get an error like this, anything you've written (or modified) is gone. If I'm already on this tangent, it would be nice if the forum was capable to upload pictures before posting instead of displaying "Invalid attachment" in the preview. Aaand the "(Insert Attachment x)" only inserts the text "[ attachment=x ]" without the "[ /attachment ]". After hitting "preview" it will be added at the end of your post instead (you might have seen this with some posts here, which have or other bbcodes at the end).
Kind regards,
Max
Post by: Hydron on September 04, 2020, 01:30:41 PM
I wonder if the scope is looking at the duty cycle over a single period (as if it were a PWM signal) rather than the full screen, in this case probably the first full period from the left of the screen.
In the 4.7% case there is a big gap from the first pulse to the next, whereas in the 18.2% case the gap is pretty small in comparison. If the scope is looking at the width of the first pulse from the left then comparing it to the width of the following low period then you'd get wild variation in "duty cycle".
Post by: Max on September 04, 2020, 03:36:02 PM
(Rather) quick note about ADSR: there are still two features missing (a useful editor aside). First it is not possible to define a meaningful release datapoint if the previous datapoint has already a target of 0 (that's because the calculations base on the differences between two data points). For any other datapoint this is not a big deal; its target value has already been reached with the previous point (effectively will be skipped). However a release can occur at any time. Not a big issue, just letting you know I know it's there :) The other missing thing is defining whether a datapoint is affected by the note velocity or not. Currently the velocity is handled like volume and scales the whole curve, but that's not right. Will be an easy fix though.
I thought it would be helpful to create a diagram about what n-tau actually does. Here it is. You can see how it affects the curve and clearly you can see where the datapoints are ;)
Edit: This is btw real data from Syntherrupter, read with the debugger. "None of that CGI rubbish!"
Best regards,
Max
Post by: Max on September 07, 2020, 01:10:01 AM
I got my ESP8266s convinced to organize themselves in a meaningful way such that the whole lightsaber thing will be pretty much plug&play. If you want x lightsabers you buy x+1 ESP8266s and flash them with the same firmware. One of them will be connected to Syntherrupter and act as receiver, the others will be sitting in the lightsabers and send data to the receiving ESP.
You'll have to assign a number to each of the sending ESPs so that Syntherrupter can distinguish the lightsabers and that you can select which lightsaber plays on which output. To do this you connect them to Syntherrupter instead of the receiving ESP, and set the number you want. The ESP will save the value in its flash.
After this initial setup it is as easy to use them as possible. Simply power them up; order doesn't matter. They'll find each other and connect. They'll also determine themselvers whether they are sender or receiver (since only senders are connected to an IMU).
So far so good I think. There's only one "issue" I'm not sure how to solve. I'd like you to be able to flash those ESPs without downloading the Arduino IDE and the whole Arduino ESP stuff. It's not difficult but I think it's a complete overkill for flashing binaries once (bugfixes aside, those things won't need any updates since the whole data processing happens on the Tiva microcontroller).
The Arduino IDE has the option to export the binary file so I thought there must be a way to flash this binary?
In case anyone is interested, here's the Arduino source. (https://github.com/MMMZZZZ/Syntherrupter/blob/841fa3f76d02139eb81441e94bf4f4545f053a55/Syntherrupter_Lightsaber/Syntherrupter_Lightsaber.ino)
It's been a loooong time since I did Arduino stuff the last time so there're likelythings that could be done better.
Edit: Ok I found out that there‘s a Python script from Espressif (https://github.com/espressif/esptool). This is already better than the whole Arduino IDE. If someone has a better option, please tell me. Oh and if a user already has to have Python installed, I could as well write a Python script for the Nextion firmware update. Then you wouldn‘t need the Nextion Editor.
Curious to hear your thoughts!
Max
Post by: Mads Barnkob on September 07, 2020, 09:13:15 PM
Hey Mads,
Yes i quickly designed it in EasyEDA. My previous interrupter was a mess, and i actually even fried it because of it. So i wanted a clean build with minimum wires, hence a PCB was born :)
I added some extra headers to connect some switches for safety and LEDs for indication.
(https://scontent-dus1-1.xx.fbcdn.net/v/t1.15752-9/117304619_242809933367198_8254849614620986566_n.png?_nc_cat=102&_nc_sid=b96e70&_nc_ohc=Kj_tdTUqZ9wAX_SHZ9B&_nc_ht=scontent-dus1-1.xx&oh=e6d4b579500bd9333a8214f482bb69a4&oe=5F507CE4)
Ordered from JLCPCB, it had arrived in a few days :)
I liked this idea so much that I wanted to use it on my own controller, with some more switches between regular analog interrupters and the syntherrupter and I also added the option to turn on a buzzer for no-tesla-coil-plugged-in-testing instead of just looking at LEDs.
Any apparent errors before I etch it?
[ Invalid Attachment ]
I will go for fiber, despite the fine work Max is doing on bringing in a ESP8266 wifi module based solution, I want to keep this controller as failure proof as possible. Which is why it will also have analogue interrupters built in.
Post by: Max on September 08, 2020, 02:14:32 AM
For <100mA a TO220 MOSFET seems like an overkill to me...? Or are they cheaper than standard TO92 BJTs? I somewhat doubt that since you’d need the logic level version of the MOSFETs.
I don‘t really get how the SW7-12 will be wired. Jumpers on the board...?
The buzzer header is connected via resistors to 3.3V. How/where do you connect the other end of the buzzers?
The ESPs were never intended for replacing the optical outputs. The idea was that you 3D-print yourself a nice Star Wars lightsaber, put a battery, IMU, ESP8266 in it and get the well known lightsaber sound from your tesla coil(s) when moving the lightsaber.
Here‘s a first „proof of concept“ video. Sound effect isn‘t great but that aside the new mode is already well integrated and works as expected. It is possible to connect up to 4 lightsabers to Syntherrutpter.
If anyone knows a reasonable „IMU to lightsaber effect“ code, I‘d love to hear about it! Code shown in the video cam be found here (https://github.com/MMMZZZZ/Syntherrupter/blob/eeb57178cd68f227399a1c213637c8f7ce8a5142/Syntherrupter_Tiva/LSData.h#L48). It is pretty basic (ignore the stuff commented out).
Kind regards,
Max
Post by: Mads Barnkob on September 08, 2020, 08:27:32 PM
@Mads:
For <100mA a TO220 MOSFET seems like an overkill to me...? Or are they cheaper than standard TO92 BJTs? I somewhat doubt that since you’d need the logic level version of the MOSFETs.
I don‘t really get how the SW7-12 will be wired. Jumpers on the board...?
The buzzer header is connected via resistors to 3.3V. How/where do you connect the other end of the buzzers?
The ESPs were never intended for replacing the optical outputs. The idea was that you 3D-print yourself a nice Star Wars lightsaber, put a battery, IMU, ESP8266 in it and get the well known lightsaber sound from your tesla coil(s) when moving the lightsaber.
Here‘s a first „proof of concept“ video. Sound effect isn‘t great but that aside the new mode is already well integrated and works as expected. It is possible to connect up to 4 lightsabers to Syntherrutpter.
I just use the same foot print for TO-220 and TO-92, they got plenty long legs to fit that width and its also to give myself some more room since I etch the boards myself, so there is no reason to go for thin as possible for me :)
The idea with SW7-12 headers is that this board just routes between the syntherrupter, the normal interrupter and the switches, so I can have it all put together with pin header plugs (to avoid that large spider web of soldered together boards). The switch would just be a NO-C-NO so the signal back to the optical board is on C and each interrupter on a NO.
The buzzer/speaker is driven along with the optical transmitter, the SW marking near it is the other end for the buzzer/speaker.
The light saber idea is brilliant! I mistook it for being a call-name for a wireless connection due to Hydron mentioning that :)
Post by: Max on September 08, 2020, 11:20:43 PM
Quote
I just use the same foot print for TO-220 and TO-92, they got plenty long legs to fit that width and its also to give myself some more room since I etch the boards myself, so there is no reason to go for thin as possible for me :)Assumed something like that. The main reason for brining it up was that usually TO-92 pinout is CBE (SGD for MOSFET) instead of BCE/GDS for TO220.
Okay if the plugs make sense it's fine. I guess I'll have a better idea of it once you've build it.
Quote
The light saber idea is brilliant!Remember, it's not from me but from Netzpfuscher :) But I agree 100%. I thought the same thing when he showed me his prototype.
Speaking of prototype, as my video in the last post showed, the Lightsaber feature already works. After a little bit more tweaking I thought you might want to play with it, too.
Here you go, a new beta (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.1) to play with. Beside the lightsaber mode I also started to document (https://github.com/MMMZZZZ/Syntherrupter/tree/dev/Documentation) the whole thing. While at the beginning Syntherrupter was made of two parts plus transmitters it is getting more and more complex. For now the documentation contains schematics, lightsaber wiring diagram, lightsaber how-to and data sheets. I'll fill it more and more and in the end it will hopefully become a useful wiki.
Best regards,
Max
Post by: Mads Barnkob on September 10, 2020, 03:07:25 PM
QuoteI just use the same foot print for TO-220 and TO-92, they got plenty long legs to fit that width and its also to give myself some more room since I etch the boards myself, so there is no reason to go for thin as possible for me :)Assumed something like that. The main reason for brining it up was that usually TO-92 pinout is CBE (SGD for MOSFET) instead of BCE/GDS for TO220.
Okay if the plugs make sense it's fine. I guess I'll have a better idea of it once you've build it.
Thanks for reminding me, I could have fooled myself in the hurry there!
Post by: Max on September 21, 2020, 02:59:47 PM
Finally I created an ADSR Editor. It is not the most user friendly but it does the job. Additionnally the new ADSR structure introduced with v4.0.0 allowed an easy yet powerful extension: loops! A random example of ADSR loops can be seen here (at 08:50): https://www.youtube.com/watch?v=1p675bxQwFg&t=8m50s (https://www.youtube.com/watch?v=1p675bxQwFg&t=8m50s)
Edit: As a starting point for playing around, here are the values that (more or less) reproduce the sound from the video linked above. Note how step 3 links back to step 2, creating a loop.
| Step | | Next Step | | Amplitude | | Duration [ms] | | n-tau |
1 | 2 | 1.0 | 500 | 2.0 |
2 | 3 | 0.0 | 200 | 2.0 |
3 | 2 | 1.0 | 100 | -2.0 |
8 | 8 | 0.0 | 100 | 2.0 |
Since editing envelopes with this editor is already hard enough, it would be good if you could save the curves, right? While programs 0-19 will always be the same at startup, programs 20-39 are stored in EEPROM. So you can create and save 20 custom programs. You can also edit the programs 40-63, but the changes will be gone after a reset or power cycle.
Third, minor change: increased ADSR step count to 8. Allows more complex envelopes
All of this has been released as v4.1.0-beta.2 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.2)
Edit 2: Just a quick reminder: you can keep MIDI Live mode running in background while you have the ADSR Editor opened. This means you can listen to your modifications without leaving the ADSR editor 8)
Kind regards,
Max
Post by: Mads Barnkob on September 25, 2020, 08:26:52 PM
Is the purpose here that you can take any "simple" MIDI file with just plain notes and then these loops are added on each note or how does it really work?
I wish I had more free time on my hands, you get out revisions of the software faster than I can even get the hardware out of the box ;) (making videos out of projects does however slow down things a bit)
Keep up the great work!
Post by: Max on September 26, 2020, 01:14:47 AM
I guess a simple google search would give you a faster and better answer but since you asked here I feel like I should try to explain. So MIDI is a digital format. It does not contain any analog information like waveforms. If you press a key on a keyboard it sends a "Note on" command, which contains thee informations: the channel, a number indicating what key you pressed, and a velocity that says how hard you pressed the key. That's it. If you release the key, same thing. "Note off" command, containing the note number that's turned off and how fast you released the key. So basically all the synthesizer gets during playback is when a note starts and when it ends. That's what i would call the "core" of MIDI. Almost all the other stuff is about giving the syntheziser more information about how it should form a meaningful sound. F.ex. the "Program" command tells the synth what instrument it should sound like. Program 0 is "Accoustic Grand Piano", Program 12 is "Vibraphone" etc. Again, this is just a number, not more. The actual sound still has to be generated by the synthesizer itself.
Now what are those MIDI "channels". Imagine you have not only one instrument, but 2, 3 or more. The guy with the drums doesn't want to sound like a vibraphone, right? So you have to distinguish them and that's what the "channel" indicates. Each instrument will be set to a different channel and the synthesizer will know what data belongs together and what not. So usually 1 channel is 1 independant instrument. MIDI supports up to 16 channels.
Now let's talk about ADSR. We know that the synth has to generate the sound from scratch since MIDI doesn't contain any actual sound. What characterises a sound is its amplitude and its frequencies. On an analog synth you would mix multiple waveforms together to get different harmonic content. This is what makes a piano sound different than a flute - even if both play the same note. Additionally there's the amplitude. If you look at an audio sample in a program like audacity you'll see a certain shape. Rising at the beginning, falling at the end - in very basic terms. If you zoom in closer you can see the actual sine wave(s). If you zoom out, you can see the overall "outline", called envelope. This envelope can have any form, but a very good approximation is to distinguish 4 parts: attack, decay, sustain, release. If you have no picture in your head, google is really the best option. A pic or even a short video really say more than a thousand words.
Here's an example: Think of a violin. You can play it in many different ways. If you play it with the bow, you start and stop rather slow. It is soft. However if you pick it, you get a sharper, short sound. In ADSR terms: the bow has a slow attack, that is not much higher than the sustain level, and a slow release. However the picking sound has a very fast attack, and it always drops back to 0 - rather quick, too.
Since we can't really control the harmonic content of a regular DRSSTC (the interrupter signal will always be a low duty, digital square wave), the envelope is the best option to change how the music sounds. Usually an interrupter plays a note at a constant ontime a "note on" command turns the output on, a "note off" command turns it of, no more. But as I just explained, the envelope of normal instruments is nowhere near of being constant. And that's what the ADSR feature allows you to do. Change the run of the amplitude after a "note on" or a "note off" command. You want a bit of an echo (not quite but something similar), increase the release time. The note won't stop right at the moment you release the key, but drop slowly back to 0. There're endless possibilities what shapes and patterns you can generate with this. And as I said before, I'm sure pretty much any youtube video about ADSR gives you a better idea than this ;)
Talking about fast revisions? Okay, here's another one ;D But this time no really big news. Check out the release notes for more details: https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.3 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.3)
What I can reveal is that it finally allows a more realistic piano ADSR curve. Try the following if you want:
| Step | | Next Step | | Amplitude | | Duration [ms] | | n-tau |
1 | 2 | 2.0 | 15 | 2.0 |
2 | 3 | 1.0 | 100 | 2.0 |
3 | 3 | 0.0 | 8000 | 7.0 |
8 | 8 | 0.0 | 200 | 4.0 |
Kind regards,
Max
Post by: Max on September 27, 2020, 12:52:36 AM
Kind regards,
Max
Post by: futurist on September 27, 2020, 12:24:20 PM
I couldn't test the coils during summer because of the neighbors >:(, then I found a suitable place in abandoned industrial complex and I borrowed power from a guy who has a workshop there
I'm only at home at weekends, however last 4 weekends it was either rainy or windy. Yesterday I finally managed to test the interrupter on my bigger coil and I ran into a few problems
I set coil limits to 300 us and 10% PWM
I'm still not familiar with volume setting on MIDI live and I couldn't figure out what each of the option does. I changed only on-time, didn't touch note PWM setting. However changing on-time didn't behave like changing on-time on my onetesla interrupter for some reason. I didn't have enough time to bring the oscilloscope and to examine what is exactly happening
Most of the midis played sound very nice, I couldn't record all of them so here are two short clips
Some songs sound bad because of (I presume) PWM limiter, it sounded like the note is "chipped". In super mario theme it's not that bad, but it can be noticed if you listen closely
At one point the coil made loud "pop" sound and it blew the 16A fuse. I quickly tried to shut down the midi playout but I then saw that the interrupter has crashed
[ Invalid Attachment ]
I was sure that IGBT died because of how the coil sounded when it blew the fuse, but luckily it didn't. OCD or UD+ pulse limiter probably saved the coil
Sorry for sparse write-up, ask if I forgot something :)
Post by: Max on September 27, 2020, 02:02:53 PM
Abandoned industrial complex sounds like a great testsite! Congrats!
Edit: The MIDIs do indeed sound good. They seem to be rather "simple" MIDIs, right? Tipp: Repetitive notes (without delay inbetween) are very hard to distinguish from each other when you do not use ADSR. This is especially audible at the beginning of the first video. For a start you could try program 1. Very basic, no surprises, except for that it is less loud. It also reduces the issue with the duty limiter a bit.
With 300us ontime you reach the 10% duty limit very fast - in many cases with already 1 note. That explains why the duty limiter has been active so often.
I‘m very curious to hear what you mean with „changing on-time didn‘t behave like [expected]“!
I gave my best to explain the „Note duty“ slider and what it does compared to the „Note ontime“ slider in the following post: https://highvoltageforum.net/index.php?topic=1020.msg8564#msg8564 (https://highvoltageforum.net/index.php?topic=1020.msg8564#msg8564)
hope it helps you!
I‘m very sorry for the crash you had to experience. And even more relieved that your coil survived!
Since you write you wanted to turn off the outputs - was that a reflex action or was it actually still generating an interrupt signal?
The bad news is: I’ve never seen that error code on a Nextion display nor could I find anything about it. But that might not be important, because I don’t think the Nextion display is the origin: the loud bang indicates that the Tiva microcontroller crashed. It‘s unlikely that the nextion screen caused a a true crash of the microcontroller and any „normal“ fault condition would not cause the output to stay high.
tl;dr
1. I won‘t be able to investigate the issue because I still have no test place for my tesla coil.
2. since the crash seems to have happened on the Tiva microcontroller, I suspect the external powersupply and/or the USB cable to have picked up EMI from the tesla coil.
3. Just a random thought: If your USB cable has too high resistance, it could cause the voltage to be much lower than 5V. 4x60mA for the transmitters plus 500mA for the touch screen is a decent amount of current. You should check that with you scope.
Out of curiosity: what firmware were you using?
Kind regards,
Max
Post by: futurist on September 27, 2020, 07:49:49 PM
Quote
I‘m very curious to hear what you mean with „changing on-time didn‘t behave like [expected]“!It seems that spark length is not changing as linearly with on-time like on my old interrupter, but it could just be my personal view
Quote
Since you write you wanted to turn off the outputs - was that a reflex action or was it actually still generating an interrupt signal?The coil continued to buzz, I panicked a little after I saw that the interrupter has crashed. I don't know why UD+ UVLO didn't trigger. All LEDs turned on, a pity I didn't record it.. very strange
I doubt it had anything to do with EMI, laptop and interrupter were far away and USB cable is short and shielded. Also I'm only using one output, so current shouldn't be a problem
I was using latest firmware
Do you think I can set duty limiter to 15-20%?
Next time I'll test two coils at once, does someone have MIDI files for playing on two coils simultaneously?
Post by: Max on September 27, 2020, 10:44:43 PM
I guess you're using a SMPS for the UD+? At least my Meanwell SMPS is able to maintain it's output for a few seconds even with two relais and the UD+ drawing current.QuoteSince you write you wanted to turn off the outputs - was that a reflex action or was it actually still generating an interrupt signal?The coil continued to buzz, I panicked a little after I saw that the interrupter has crashed. I don't know why UD+ UVLO didn't trigger. All LEDs turned on, a pity I didn't record it.. very strange
I doubt it had anything to do with EMI, laptop and interrupter were far away and USB cable is short and shielded. Also I'm only using one output, so current shouldn't be a problem
What LEDs do you mean? I can't see LEDs on your Syntherrutper so I guess you talk about those connected to the UD+? Which wouldn't be that surprising; although it's no real help either.
That's very strange indeed. Since it continued to buzz the Tiva microcontroller did obviously not crash* but then remains the question what happened.
A word about the error screen you saw. It is not part of my firmware. Its part of the Nextion bootloader, which runs my firmware. Usually you see a bootloader message only when there's no firmware, a corrupted firmware, or during a firmware update. But if the firmware has been compiled successfully and uploaded successfully, it shouldn't appear. Hence I've never seen that error, and I haven't found anything about it. I assumed that when the Tiva microcontroller crashed it sent a ton of gargabe to the Nextion, causing that one to crash, too. But since you say the microcontroller continued to operate, that makes not much sence anymore. Like the rest.
So here's the only other thing I can imagine to have happened. For some reason the Nextion screen crashed, and sent garbage to the Tiva which caused unexpected behavior. I don't see how but it's at least something I can test quite simply: send total garbage to the microcontroller and see if the output glitches or not ("fuzzing").
* Why do I think it did? The ontimes themselves are generated in hardware, meaning a timer is started that runs for the exact amount of microseconds we want. It's configured as oneshot, meaning it does this once and then stops. Additionally it's configured to set the output pin to high when it starts, and back to low when it stops. So as long as the timer module is still provided with a clock signal the ontime should definitely end after the specified amount of microseconds, not later. Once the program enables the timer, it runs completely independant. Interrupts, faults, etc they do not affect the timer in any way. Hence I thought the microcontroller crashed, because that's the only explanation I found that would stop the timer from running.
A single ontime is just a "pop" sound, but since you say it "buzzed", the microcontroller must have been actively generating new ontimes (remember, it's a oneshot timer, it has to be started by the program for every single ontime). This does not happen after a reset. This does not happen after any kind of fault condition. This only happens when it continues to run the code.
Do you think I can set duty limiter to 15-20%?Probably yes. Here's what I'd suggest. Increase duty step by step (5 percentage point steps sounds reasonable) and keep an eye on the temperatures, maybe on the current consumption, too. As long as nothing gets too hot or fries something like the input rectifiers (or the fuses) it should be no problem to increase the duty.
Next time I'll test two coils at once, does someone have MIDI files for playing on two coils simultaneously?Well... I posted a Popcorn MIDI (click (https://highvoltageforum.net/index.php?topic=1020.msg8493#msg8493)) in this thread and a Thunderstruck MIDI (click again (https://highvoltageforum.net/index.php?topic=1020.msg8343#msg8343)). Both have multiple channels that are suited for playing on tesla coils. I'd suggest to play around with the channels; which go better together (same coil) and which are better separated (different coils). Additionally you can even play a single track on two coils using the stereo features. F.ex. you could assign the channels with the bass line to one tesla coil, fully using the low frequencies for some pulse skipping, and the melody on the other coil, producing intense, high BPS streamers.
Just as a reminder: almost every MIDI file I have in my collections, any files I ever used for a demonstation are unmodified MIDI files from the internet. Except if you consider a change of the instrument as a modification. Nothing else is needed in 99% of the cases. Additionally I linked to a couple pages with really good MIDI files a few posts ago (click. you're welcome (https://highvoltageforum.net/index.php?topic=1020.msg8661#msg8661)). Look for anything that appeals to you and try it out. Since you don't have to modify anything, downloading and testing costs at most a few minutes. I do think that Syntherrupter makes it easy to try random MIDIs.
Admitted, the stereo features mentionned above do need a few extra commands which you have to enter with the MIDI Editor on the touch screen (proudly presented by me over here (https://highvoltageforum.net/index.php?topic=1020.msg8437#msg8437)). But even that becomes a matter of a minute at most once you've done it 2-3 times. And if you found the settings you like, you can include them at the beginning of the MIDI file for future playbacks. No idea what I'm talking about? No worries, the ACDC Thunderstruck MIDI already includes them. Just remember to enable stereo playback for both of your coils ;)
Kind regards,
Max
Post by: futurist on September 28, 2020, 09:52:47 PM
I guess you're using a SMPS for the UD+? At least my Meanwell SMPS is able to maintain it's output for a few seconds even with two relais and the UD+ drawing current.LEDs on UD+ and precharge controller, really strange. It all happened in a few seconds in the dark, so I didn't catch every detail. Next time I'll setup camera to record the whole test
What LEDs do you mean? I can't see LEDs on your Syntherrutper so I guess you talk about those connected to the UD+? Which wouldn't be that surprising; although it's no real help either.
That's very strange indeed. Since it continued to buzz the Tiva microcontroller did obviously not crash* but then remains the question what happened.I think we have to pretend it didn't happen until I test the coils again, with oscilloscope and camera to catch any problems
A word about the error screen you saw. It is not part of my firmware. Its part of the Nextion bootloader, which runs my firmware. Usually you see a bootloader message only when there's no firmware, a corrupted firmware, or during a firmware update. But if the firmware has been compiled successfully and uploaded successfully, it shouldn't appear. Hence I've never seen that error, and I haven't found anything about it. I assumed that when the Tiva microcontroller crashed it sent a ton of gargabe to the Nextion, causing that one to crash, too. But since you say the microcontroller continued to operate, that makes not much sence anymore. Like the rest.
I'm curious what was max. duty cycle with my onetesla interrupter turned to 300us max. on-time. I think I'll hook it on the oscilloscope and measure, I wouldn't be surprised that it's around 20% for MIDIs like popcorn. SKM400 halfbridge was barely warm with onetesla interrupter on max., MMC is overkill for this coil and is always stone cold. I blew few 16A fuses with the final countdown song solo partDo you think I can set duty limiter to 15-20%?Probably yes. Here's what I'd suggest. Increase duty step by step (5 percentage point steps sounds reasonable) and keep an eye on the temperatures, maybe on the current consumption, too. As long as nothing gets too hot or fries something like the input rectifiers (or the fuses) it should be no problem to increase the duty.
Can't wait to test the stereo feature!
Post by: Max on October 12, 2020, 03:47:24 PM
Part of my response to AstRiis build was development related so I moved it back to here where it belongs:
I had (and have) not much time and most of it went into the wiki. However I did extend the Firmware Update Mode a bit. It is now a general purpose serial bridge. If you enter that mode, the Nextions RX/TX pins are connected straight to the USB serial port (through software though). So you can send anything you want, or debug it - whatever. Additionally the same thing can be done for the ESP. So you don‘t need a programmer for the ESP and can do it through Syntherrupter, too. Only downside: it won‘t reset automatically after a Nextion firmware update anymore. You have to do it manually but that‘s not a big issue I think. The passthrough mode works for any baud rate up to ~512kbaud/s.
The new wiki can be found here (https://github.com/MMMZZZZ/Syntherrupter/tree/dev/Documentation/Wiki). Feedback is highly welcome as always!
Kind regards,
Max
Post by: futurist on October 12, 2020, 08:53:51 PM
It actually sounds much nicer in person, phone isn't suitable for recording such high volumes
< my new favorite DRSSTC midi
Sorry for vertical recording, this was a quick test. After 10 minutes of playing at full power secondary got pretty hot and I had to stop. Inverter and MMC barely warm, bus caps pretty hot
If I didn't mention before coil is powered with chinese 40N60 double half-bridge. It still needs tuning, otherwise my OCD LED will burn out. Settings are duty-limiter 15%, max. on-time 280 us
Post by: davekni on October 12, 2020, 11:11:15 PM
Post by: AstRii on October 12, 2020, 11:24:53 PM
Post by: Max on October 14, 2020, 04:34:43 AM
New release (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.5)! Among other things it includes dark mode! Remember to update the Nextion firmware before updating the Tiva firmware. This time it is particularly important.
Kind regards,
Max
Post by: Max on November 05, 2020, 01:31:56 AM
I spend some time to get that wiki filled. It's still nowhere near being complete but at least there's a new Getting Started Guide (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Getting%20Started.md#readme) among other things. I'd love to hear your feedback!
Since most of the information from the starting post is now available in the wiki I shortened that post. Much better now.
Edit 07.11.20: Documentation of the threee modes, Simple (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/UI/Simple.md#readme), MIDI Live (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/UI/MIDI%20Live.md#readme) and Lightsaber (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/UI/Lightsaber.md#readme) is done. What's missing are the various settings, although they're partially documented in the Getting Started article. Hardware is mostly documented, too. All in all I'd say 50% done. If anyone reads this and finds a broken link or another issue, please open an issue on GitHub. Doesn't need to be fancy, just quickly point out what's wrong and I'll fix it asap.
Kind regards,
Max
Post by: Max on November 06, 2020, 07:23:42 PM
I had a look at some videos where I tested the stereo mapping feature. The original idea was that you can visually separate the instruments/voices of a piece (= MIDI channels). However, because you're facing chords pretty often, you have not a single note moving around, but a group of notes. Hence you don't have 1 sharp position for this instrument but it's spread around. Add some more instruments and all you get is a mess. Take this video as an example:
At the very beginning you can see how the single note moves around. But as soon as the second instrument (with two notes, one at the left, one at the right) joins, nothing is clear anymore. And it only gets worse.
That's where the new stereo modes come in. They allow you to map an entire channel to the same position, instead of mapping each of its notes individually. This can be done based on the lowest, the highest, the average or the loudest note of this channel. Now that all notes of a channel land on the exact same spot you should get a clearer "image" in many cases.
I have no breadboard with LEDs at the moment (and for sure not a bunch of tesla coils) to test this feature. If anyone is interested I'll create a new beta release. FYI the NRPs needed to activate this stuff are documented here: Custom MIDI Commands (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Custom MIDI Commands.md#readme)
To make this feature possible I had to change the way the channels and notes are pocessed. Should be a bit more efficient now but as I said, untested.
Kind regards,
Max
Post by: Max on November 08, 2020, 09:05:29 PM
The QR code can be (de)activated on the Help and Info page.
Since there's not much space for a QR code, it's rather small and you may have to use the zoom of your camera (this is the case for my iPhone 8) . With zoom it works flawlessly though.
While the QR code is implemented on every page, the wiki is still not done, so the QR Code will link to more or less empty pages in some cases. The three modes (Simple, MIDI, Lightsaber) are pretty much completely documented, the settings however are still missing.
New release available: v4.1.0-beta.6 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.6)
Edit: Attached example screenshot
Kind regards,
Max
Post by: Max on November 11, 2020, 11:15:25 PM
So I thought I‘d share this graphic I made the other day. It shows the different „layers“ of Syntheruppter and what sits on top of what. Hope it gives you a better idea about how it‘s structured under the hood.
In case someone wonders what tool I used to create that graphic: Solidworks. And no, this is not what it was made for ::)
Kind regards,
Max
(https://raw.githubusercontent.com/MMMZZZZ/Syntherrupter/dev/Documentation/Pictures/Syntherrupter%20Structure.png)
Post by: Mads Barnkob on November 13, 2020, 09:53:53 PM
I flashed the Tiva without any problems, drivers and all that, just worked out of the box, literally.
However, it turns out its the "intelligence" version of the display that I have. NX8048P070-011R to be specific. So I assume that I can not use the very specific model files in the release? I also tried downloading the Nextion editor (v1.61.2) to just choose another model in the TFT file, but its not a project file and trying to run the TFT file in debug mode I just get this message "TFT file version is not supported" and another popup "invalid tft file".
Post by: Max on November 13, 2020, 11:29:49 PM
I flashed the Tiva without any problems, drivers and all that, just worked out of the box, literally.Glad to hear that!
However, it turns out its the "intelligence" version of the display that I have. NX8048P070-011R to be specific. So I assume that I can not use the very specific model files in the release?That‘s unfortunately true. Edit: Originally I thought the follwoing wouldn’t be feasible. However a quick check showed that it can be done. You can modify the source file such that it works. Some components have an additional property on the Intelligent series displays that doesn’t get a correct value automatically. Since I never expected anyone to pay the completely unecessary premium for the intelligent series I couldn‘t be bothered to do this for every series by hand.
- Download the source file from the repository (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Syntherrupter_Nextion/Syntherrupter_Nextion.HMI). If you want the source file for a specific release, just navigate to it from the commit that‘s linked on the release page next to the version number at the left.
- Open the file in the Nextion Editor. In the bar at the top with all the icons you‘ll find a button called „Device“. It opens a window where you must again select „Device“ in the top left corner. Now you can change the device to your model and leave that window by clicking „OK“.
- You need to modify every slider in the UI. Luckily there aren‘t that many. They are on the following pages, which can be selected at the top right of the editor:
- Page 3: Simple
- Page 4: MIDI_Live
- Page 5: MIDI_TC_Set
- Page 7: Lightsaber
- Page 9: Other_Settings.
- Once you clicked on one of those pages it shows up. Click on the slider. Its properties show up at the bottom right. You‘ll find the two attributes „pic“ and „pic1“. You need to copy the value from „pic“ to „pic1“.
- Repeat for every slider. Note that not all of them have the same value for those attributes so be careful with copy-pasta.
- Check your work by clicking the Compule button. If it gives no errors (red lines) you‘re good! Now you can either flash the compiled file directly by clicking the Upload button or you can save the compiled TFT file via „File->TFT File Output“. That one can be flashed just like described in the wiki (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Firmware%20Flashing.md#readme).
- Please remember that I have no possibility to check whether this actually works or not. And I hope you understand why I do not want to do this for every release when it can‘t be automated.
I also tried downloading the Nextion editor (v1.61.2) to just choose another model in the TFT file, but its not a project file and trying to run the TFT file in debug mode I just get this message "TFT file version is not supported" and another popup "invalid tft file".TFT files are like binaries, they‘ve been compiled for that specific target. You can run them (on real or virtual hardware) but you can‘t modify them.
The TFT file version error likely means that you tried to open one of the TJC... files. Any of the NX... files should at least run in the debugger (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Minimum%20Viable%20Setup.md#without-a-display). The thing is, while Nextion and TJC are the same hardware, all of their files are checksummed such that they are not interchangeable. TJC files can only be opened with the chinese version of the exact same editor. I can create releases for all of the displays because smart people found ways to f*ck this checksum rubbish.
8)Quote*Keeping my thread at the top* ;Dguess I can do the same :P So just a quick update:
Kind regards,
Max
Post by: Mads Barnkob on November 14, 2020, 12:12:31 AM
I tried opening both NX and TJC files in debug mode, same message on all the files.
Post by: Max on November 14, 2020, 12:14:49 AM
I‘ll investigate the TFT file issue tomorrow. Maybe its a problem because I‘m still on Nextion Editor v1.61.1.
Kind regards,
Max
Post by: Max on November 14, 2020, 12:10:31 PM
Sorry for this. I didn't know about that issue and it makes my life more complicated, too.
Kind regards,
Max
Post by: Mads Barnkob on November 14, 2020, 01:07:47 PM
Aaah shit. Sorry I was too late with my edit. Turns out it is possible because unlike i thought it‘s only one component type that needs to be modified. See my edit above. Still, I think you should get a Basic or Enhanced series screen if possible.
I‘ll investigate the TFT file issue tomorrow. Maybe its a problem because I‘m still on Nextion Editor v1.61.1.
Kind regards,
Max
I did not find source HMI files at first glance and only thought I had the TFT files available, so panicked a bit there ;)
I changed device, compiled and updated all pic to pic1 values that turned up errors and I could compile, create TFT file, download to display and start using it. No problems! Only need to do it again for darkmode, as that now has a white front image showing up :) Looking through the code to change to darkmode, its just 4 values, but where does the slider read "Settings.colorMode.val=1"
Do not worry about making special versions for me, I guess I could upload a branch to your releases that is updated for the intelligence displays.
I am properly not going to return this, since it works, I foresee that the basic/enhanced versions is less in stock than the intelligence is, at least judging from digikey stock numbers.
I could set up all settings, change users, browse around and overall its a very nice GUI you have made. Now I just need to test my optical PCB and it should be good to go for a first test.
Post by: Max on November 14, 2020, 01:48:42 PM
First of all, a separate branch is useless because Nextion is a binary format. Meaning Pull Requests/Merges won't work.
Now dark mode is a little bit hacky, because it hits a few limitations of the Nextion environment. So the way how dark mode works is that when the page loads, it checks the current color mode and sets the colors and graphics of all components. This happens by calling the fLoadColors Touch Press Event. Nextion does not know true functions but you can call press/release events of any component.
Next issue is that Nextion doesn't know "global" components (well it does, but not this way), meaning that this fLoadColors component is present on all pages and every change needs to be copied to every single page.
Since the slider on your screen has an additional property, we need to change that in the fLoadColors code, too. To do this you select the fLoadComponent somewhere in the top right corner, then in its Touch Press Event scroll down to the bottom and add the following line
Code: [Select]
b[sys0].pic1=b[sys0].pic
at the end of the last else if section:Code: [Select]
...
}else if(sys1==1)
{
// Types that have pic, pic2:
// slider
b[sys0].pic=b[sys0].pic%Settings.picCount.val
b[sys0].pic+=sys2
b[sys0].pic2=b[sys0].pic2%Settings.picCount.val
b[sys0].pic2+=sys2
b[sys0].pic1=b[sys0].pic // <= NEW LINE
}
}
Aaaand of course repeat for all pages...
Sure you want to keep your "intelligent" screen...?
Quote
I could set up all settings, change users, browse around and overall its a very nice GUI you have made. Now I just need to test my optical PCB and it should be good to go for a first test.Wohoo!
Kind Regards,
Max
Post by: Mads Barnkob on November 14, 2020, 04:31:43 PM
Its a terrible fix settings variables that does not exist, but then again its a terrible IDE/editor that doesn't even have search and replace :D
Post by: Max on November 14, 2020, 05:15:46 PM
I just tried adding in "b[sys0].pic1=b[sys0].pic" in the latest HMI project file from you with a NX4048K070 device selected, that does not generate any compile errors. Maybe you can just leave it inthere as dead code on the basic/enhanced models and to fix dark mode for the intelligent. Perhaps you could even just do the same for the slider pic1 ID reference? I got no basic display to test it on, if that illbehaves.The reason it doesn't give errors is because the array based addressing of components doesn't contain any checks whether that attribute even exists or not. However, during runtime it will generate an error message over serial (which you can see it in the debugger, too). The Tiva firmware ignores those errors, making it in theory possible to go for this "solution". However, I am by no means a fan of deliberately introducing errors into my firmware. And there are some reports that runtime error handling costs quite a bit of processing time on Nextion, so it might even slow down the page loading times (which wouldn't be noticeable in the debugger).
The "proper" way to do it would be to set pic1 only if the device is an intelligent screen, but this requires modifications on the Tiva side, too. The reason is that there's no command or system variable that would allow the Nextion firmware to find out the model it's running on. It can only be requested over serial as part of the firmware update protocol (without having to initiate an update though). So the Tiva would have to send the command, parse the return data for the version, and then set a variable on Nextion to allow or disallow the assignment. Sounds funny, right? ;D
Its a terrible fix settings variables that does not exist, but then again its a terrible IDE/editor that doesn't even have search and replace :DYou don't even want to know what's necessary to get a decent UI on these things... ::) If you look through some of the code and it hurts your eyes, it's not because I'm an idiot (well, not always) but because there's no elegant way to do it. It's somewhat similar to Arduino. Very easy to start and get basic things done. Even some advanced stuff works right out of the box. But if you want something custom and/or more performant it gets messy. quickly. One significant difference though: with arduino you're not forced to use the Arduino Methods, you can use your own functions, access registers, etc. Here you can't.
Syntherrupter is hitting Nextions limits on multiple occasions but there are no ready-to-use alternatives I'm aware of. Hence the plan (for the far, far future) is to leave the Tiva dev board and the Nextion screen behind and switch to an STM32F7 + normal touch display. Has a lot of advantages but will be much harder to get started and definetly require a custom PCB with SMD stuff.
The Nextion Intelligent screens are no alternative for me because they still have all of the limitations of the Nextion language. Additionally this would make the minimum viable setup of Syntherrupter even more expensive than it already is or than it would be with the STM32F7.
Kind regards,
Max
Post by: Mads Barnkob on November 14, 2020, 08:32:44 PM
While a STM32F7 platform might be "better", there is still a good deal of greener grass to that tale. I have worked with the STM32F746G-DISCO, the Discovery devkit that was a great bargain for a devkit with a touch screen piggybacked on it. But the software is complex to set up as you say and the HMI editor is somewhat better but still in a league of FAR FROM where other GUI building tools are in "modern" age. I have built displays on unix systems from the 90s that was more intuitive, user friendly and easier to start out on.
Enough with the ranting! I will keep the intelligent display as long as it works and changing 10 sliders and 16 pages is not a big deal, I can just jump some of the beta versions ;)
Post by: Max on November 17, 2020, 03:22:38 PM
Since I have currently no new features that I'm working on, I made a very small update that fixes a bug introduced with the last release. Details as always in the notes. https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.7
TBH I hadn't much time for extensive testing. So there may still be other MIDI bugs. Let me know if you find any!
Kind regards,
Max
Post by: Mads Barnkob on November 17, 2020, 08:43:47 PM
@Mads: Urks - more bad news... Do you know by chance whether lvgl is a viable alternative?
I did not know about that one, so I got nothing to say about that :)
Since I have currently no new features that I'm working on, I made a very small update that fixes a bug introduced with the last release. Details as always in the notes. https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.7
TBH I hadn't much time for extensive testing. So there may still be other MIDI bugs. Let me know if you find any!
Kind regards,
Max
I ran upon that in simple mode, with standard settings of 200us, 1000Hz and 10% dc limit, I can play with the us/Hz sliders in a way so that dc says 10% on the display, but only 7.3% on the oscilloscope measuring the output. I am not sure if this has to do with the settings for minimum off time?
This does however only seem to happen if changes are done fast, properly too fast for TIVA and Nextion to communicate properly?
Post by: Max on November 17, 2020, 10:50:21 PM
Even when I move the slider very fast for a couple seconds, everything is fine; the tones send to the core match the values on the screen. For 1 coil as well as for 6 coils.
There‘s one crucial difference between your setup and mine: your Nextion display has a 200MHz CPU, mine has a 48MHz CPU. Yours likely fires those serial commands much faster than mine - possibly too fast as you suspected. To test this hypothesis I attached a modified Tiva firmware with a bigger receive buffer size.
While testing this I noticed another bug related to dark mode. Actually not a bug of mine but one of Nextion. When switching to dark mode, hiding components doesn‘t work anymore because it always overdraws the component with the original background color - white. So I have to manually draw a rectangle in the correct color every time I hide a component... Even this is only half of the problem; the flickering remains, because Nextion draws a white rectangle before I can overdraw it with the righ color. I have to check whether I‘ll find a workaround for this, too.
Finally, while I investigated Nextions issues I found a couple minor oopsies of mine, too. The QR code was supposed to have a lighter color in dark mode for better contrast and the position of the Manual/Apply buttons in Lightsaber mode didn‘t match the positions in the other two modes. Both things are now fixed and will be available soon.
Edit: Attachment fixed. somehow it shrunk to 0kb during the upload..
Kind regards,
Max
Post by: Max on January 12, 2021, 09:28:57 PM
I tweaked the colors of Dark Mode. I think it looks quite a bit better now ;)
Wiki is mostly complete, lightsabers won't change/improve anytime soon, and no other bigger upcoming changes either. So I made some efficiency tweaks under the hood and released v4.1.0.
Neither futurists reported issue (not here, PM), nor Astriis, nor Mads issue have been addressed. Either it were (too) small issues or I haven't got enough info so far to find and fix them.
Release v4.1.0: https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0
Happy new year!
Max
[ Invalid Attachment ]
Post by: Mads Barnkob on January 13, 2021, 12:39:08 PM
I am planning to release the videos about my built on this in 7 and 14 days from today, still working on 3rd video as I am awaiting parts to arrive. 4th video is about the syntherrupter mounting and in that video I will include a firmware update, if I find anything before that I will let you know :)
Post by: Max on January 13, 2021, 06:51:17 PM
Kind regards,
Max
Post by: futurist on February 09, 2021, 10:17:20 PM
I didn't have any two channel MIDI songs unfortunately
Everything performed exceptionally well although it was set up in a hurry
It seems that quite some time has passed since last experiments, however I'm only home at weekends and I'm doing experiments outside, borrowing power from a guy who has a workshop in abandoned industrial complex, so I'm dependent on good weather and on the owner who isn't always available
Check out youtube playlist I made
https://www.youtube.com/playlist?list=PLlkH_ZpBGiexB1ahBjtajvHqJAfMIxrB1
Post by: Max on February 11, 2021, 07:57:09 PM
Thank you very much for sharing! Couple good songs among those clips. And some really intense arcs as well. Did you push the limits or are these coils capable of even more?
What happened at 1:47 in this video??
What do you mean by „two channel MIDI“? Or in other words, what midi are you looking for?
Recently I noted that Syntherrupter still seems to have timing issues. In simple mode, some frequencies just don‘t sound right, 850Hz f.ex. Well it turns out this is caused by a delay of only 30us every couple periods. It obviously happens when the periodic checks for new data, effects, etc block the pulse generation. Tbh I didn‘t expect 30us jitter to have such a big impact. I have an idea how to solve this using some kind of buffering but it‘d take me quite some time to develop and test - time I don‘t have at the moment.
In the meantime I might try to randomize the periodic stuff a bit. If those things are checked every 800us-1200us instead of precisely every 1000us there shouldn’t be such a severe interference with specific frequencies anymore.
Kind regards,
Max
Post by: Mads Barnkob on February 11, 2021, 08:45:49 PM
https://highvoltageforum.net/index.php?topic=1417.msg10855;topicseen#new
Post by: futurist on February 11, 2021, 10:53:21 PM
@futurist:
Thank you very much for sharing! Couple good songs among those clips. And some really intense arcs as well. Did you push the limits or are these coils capable of even more?
What happened at 1:47 in this video??
Bigger coil runs bellow it's limit, although it's limited by the streamers hitting ground. I'm happy how it performs, it's powered only with one SKM400 half-bridge module
Smaller coil is powered with double TO-247 half-bridge with 300 Apk OCD, which is near it's limit. I still have to tune it properly and I'm sure it'll do ground strikes without triggering 300 A OCD
I hope that forum thread with build details for smaller coil will be finished soon
I'm not sure what happened at 1:47, it happened a few times before that, and I had to restart midi to serial converter to get it working again
What do you mean by „two channel MIDI“? Or in other words, what midi are you looking for?
MIDI files edited so that one coil can play one set of notes and other coil can play other set of notes
Post by: davekni on February 11, 2021, 11:04:23 PM
Post by: futurist on February 11, 2021, 11:36:06 PM
Post by: TMaxElectronics on February 12, 2021, 11:40:25 AM
Quote
MIDI is playing with different pitch until I restart midi to serial converter
That seems very odd to me... I have used that for my first interrupter too, and never had issues like that. Did the song you play when the error happened use pitch bend? I suspect that the message setting the offset to zero might have gotten lost. I'm guessing you could test this by using something like vmpk, slide the pitch bend slider around a little after that error has occurred and listen if the pitch resets.
I don't think the coil will be interfering with the interrupter much, since the data comes in via usb and then has some probably quite short traces on the dev board itself after being converted to serial. USB doesn't really care about the interference from coils as far as I have noticed, and I doubt that the loop area of the serial line is large enough to pick up enough noise to confuse it.
Post by: Max on February 12, 2021, 12:35:51 PM
Somewhere in the v4.1.0-beta.x testing I sent loads of random serial data to Syntherrupter. This caused some weird noises obviously but it did not exceed the limits and worked just fine after that. Now that I'm writing this... It might be that test that I remember. Which would explain why you had to restart the MIDI/Serial converter and not Syntherrupter. That would be good and bad news. Good: no bug in my code, bad: nothing I could fix in my code to help you...
One issue I know from some of my test runs is that I could not have my notebook plugged in. Once i connected it to its charger my Arduino interrupter* would randomly crash during operation.
*yeah that was before Syntherrupter existed, in a time where corona was just that blueish thing making ozone.
Kind regards,
Max
Post by: TMaxElectronics on February 12, 2021, 01:46:48 PM
So I'd look at either the interrupter and all of the midi commands it supports that change tuning, and potentially the midi player, as that might support transposing of the output that gets reset when the midi output device chagnes.
Post by: Max on February 12, 2021, 05:19:43 PM
In theory it is also possible that it is the UART of Syntherrupter whose baud rate (or any other receiver setting) gets messed up but I don‘t know how this could happen... and it‘s still nothing I could fix either.
If you want to investigate the issue, futurist, you could capture some serial data with your scope when it happens then we can analyze if it‘s valid serial data or not. The MIDI serial data can be scoped at the input pin, the USB serial data can be scoped at the 2x7 groups of solder pads between the debug chip and the jumpers.
I realized that apparently I did not fuzz enough when I did the experiment last time. Repeating the experiment now revealed two issues. A minor issue in the serial buffer makes it return 1 garbage byte if the buffer overflows at a specific moment. More interesting is that the fuzzing goofs up the internal list of active MIDI notes. It‘s a doubly linked list and for some reason it always ends up with two notes pointing to each other, such that the iteration over the entire list becomes an infinite loop. It seems to be related to buffer overflows because it only happens at higher data rates. Will be interesting to find the origin of that bug...
Neither of those bugs does btw explain futurists observations. As I said in the beginning, as long as Syntherrupter processes the random data it sounds pretty much exactly like in his video. As long as that note lockup thing doesn‘t happen, no funny business going on here. I can stop the random data stream and play a MIDI file without any issues, resets or reconnects.
Kind regards,
Max
Post by: Mads Barnkob on February 13, 2021, 07:53:40 PM
Post by: Netzpfuscher on February 14, 2021, 08:46:45 PM
https://github.com/lathoub/Arduino-AppleMIDI-Library
Post by: Max on March 11, 2021, 12:35:32 PM
Thanks for the suggestion. I‘ll keep it in mind but at the moment I don‘t have the time for working on the project.
Kind regards,
Max
Post by: Georgios on March 14, 2021, 12:04:42 PM
Post by: Max on March 14, 2021, 05:13:16 PM
Thank you very much! Quite a fast MIDI file you got there; works nicely with the tesla coil sound. I hope we'll see more of this in the future ;)
Mind if I link/embed your video on some of the Syntherrupter pages?
Kind regards,
Max
Post by: Georgios on March 14, 2021, 05:36:32 PM
Post by: futurist on March 17, 2021, 11:30:53 AM
Post by: Mads Barnkob on March 17, 2021, 08:48:54 PM
Post by: Max on March 18, 2021, 03:24:04 PM
Kind regards,
Max
Post by: Max on March 18, 2021, 10:30:25 PM
The good news: the new version can be bombarded with as much serial garbage as you want it doesn't cause any issues. No reset needed to continue with normal MIDI playback afterwards.
Kind regards,
Max
Post by: Max on April 02, 2021, 02:37:34 AM
During my latest work on the code (more on that below), I found out that the support for MIDI running status had been broken since v4.0.0. And furthermore, the NRP editor (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/UI/Channel%20Settings.md#what-you-see) doesn't work. Looking at the git history I honestly don't understand why it ever worked because hasn't really been changed since I implemented it. And I do know that it worked at some point, because I used it quite a lot when testing the stereo stuff.
Anyways, both things are fixed now. Since no one has ever used these features so far (or lets say, no one has complained that they're broken), I'll wait a bit before drafting a new release. Who knows what else I'm going to find...
The new stuff I've been working on is the possibility to fully control Syntherrupter over MIDI commands (so called sysex messages). The main idea is that you can embed those commands into your MIDI files which eventually allows you to play any MIDI file without even touching Syntherrupter. No need to change the channel assignments, the stereo positions, ontimes, duties, ... all of this can be directly embedded into the file and thus loaded automatically when you play them. And since this is compliant with the MIDI standard, you don't lose compatibility with any MIDI player or any other MIDI device.
This is a rather big change, hence I plan to introduce it step by step.
1. Ability to receive and process sysex commands, although nothing will be visible in the UI
2. Document the parameters
3. Automatically refresh on-screen data when receiving sysex commands.
4. Sysex export, allowing to send the current settings to the PC (or another MIDI device), removing the need to manually type all the commands.
5. Figure out the easiest way to add such a bunch of commands to an existing midi file.
Step 1 would already allow me (and others) to share prepared MIDI files with more complex stereo configurations, without having to explain all the settings involved. Step 3 only requires a complete redesign of the interface between display and microcontroller. Step 4 will be interesting because i'll need to somehow group the parameters in a meaningful way, and make those groups selectable. You probably don't want to always save ALL parameters into a MIDI file.
For now my main goal is step 1 and 2. The remaining steps will probably be delayed by quite some time.
Kind regards,
Max
Post by: Mads Barnkob on April 05, 2021, 11:06:04 AM
I am finishing a Academy profession that I have been studying for 4 years, besides full time work, and I am handing in my final assingment in some 9 weeks. So time is really scarce on me, if you have specific things you need tested, I will see if I can find a spot for that.
I just took a quick glance at MIDIEditor and in its manual: http://www.midieditor.org/index.php?category=manual&subcategory=midi-overview it mentions SysEx: "System Exclusive Events: System Exclusive Events are used by manufacturers to provide a way to send device-specific messages." But I can not find a way to edit these events inside the editor... Seeing as these are device specific, I was expecting to find a event that just lets you put in the raw MMC/SysEx lines maybe with a pre-configured F0 in start and F7 at end...
It is a great idea that you will work on putting these settings into the files. Else in a show settings, you need to move fast on changing settings or run a show with "same" settings. Looking forward to see your progress.
Post by: Max on April 05, 2021, 02:04:09 PM
if you have specific things you need tested, I will see if I can find a spot for that.Very kind offer but no, currently not. The bugfixes are already tested and the SysEx stuff isn‘t ready for a release yet. I do have a first implementation of a few commands and already a pretty complete documentation (https://github.com/MMMZZZZ/Syntherrupter/blob/7d1ee4d57b84ae300addaf5d879d3f986e833f3f/Documentation/Wiki/Custom%20MIDI%20Commands.md#syntherrupters-sysex-commands-version-1). However, it is currently not possible to control anything outside of MIDI Live mode - a limitation I want to get rid of before releasing a beta.
Good point about editing those messages. SynthFont, the editor and player I use, seems to have the same limitation. I can see sysex messages but I can‘t create or edit them. Apparently it is common practice to store SysEx data in separate files using the .syx extension. When searching for „sysex editor“ I do find tools for loading and saving sysex data from/to those files. Some are adapted to the format of specific manufacturers others are even simpler and just load/dump the hex data (Send SX (https://www.bome.com/products/sendsx)). That is fine once Syntherrupter is able to export data. For now however, this is not at all user friendly. I‘ll probably cobble some python script together that specifically supports Syntherrupters messages, allowing you to set „ontime“ of „coil 3“ in „midi live mode“ to 100us instead of writing F0 00 26 05 01 7F 20 00 03 00 64 00 00 00 00 F7.
Oh btw. I recently saw in your Syntherrupter video at 16:30 (https://www.youtube.com/watch?v=jQZj8DPNvJg&t=16m30s) that the table grid in the coil limit settings disappeared when you selected a value. That‘s not supposed to happen and I guess it‘s another quirk of the intelligent series. If you want, you could send me your modified HMI file and I‘ll have a quick look at it. I‘m curious about where that comes from.
Kind regards,
Max
Post by: Max on April 06, 2021, 01:40:49 AM
Fixed and released it together with the running status and NRP Editor fixes (https://highvoltageforum.net/index.php?topic=1020.msg11722#msg11722) as v4.1.3 (https://github.com/MMMZZZZ/Syntherrupter/releases/)
Kind regards,
Max
Post by: Max on April 13, 2021, 12:13:15 AM
Taking a break from the work on Syntherrupter itself, I wrote a tool for generating those sysex commands. Having written a couple of them by hand I am sure that without a tool no one will ever use them. The result is Syfoh - Sysex for humans (https://github.com/MMMZZZZ/Syfoh#readme). You provide your wishes as readable text and Syfoh converts it to the corresponding sysex command:
Code: [Select]
Input: Set ontime for coil 1 and mode simple to 100
Output: F0 00 26 05 01 7F 21 00 01 00 64 00 00 00 00 F7 Commands can be given one by one using the command line, or by specifying a text file with a whole bunch of them. Syfoh can send the commands directly to a serial port, store them as text, as binary (compatible with .syx files/editors), or just write the hex data to the console. The binary files can be passed to a serial port using pretty much any tool. No additional processing required.
While it is not a nice, good looking GUI I think it is pretty much "best bang per buck" (in the sense of highest ease-of-use per development time). Writing text files instead of clicking around is probably much faster anyways - especially when using an editor like Notepad++.
This tool doesn't allow you to embed the commands into your MIDI file but it gets very close: load sysex commands from (text/binary) file, play MIDI file. Should be more than useful enough for stage performance. Alternatively you might find a .syx tool that allows you to convert the data to a MIDI file which could then be further processed but this doesn't seem like it's worth the effort.
Kind regards,
Max
Post by: SimonNwardUK on April 22, 2021, 10:36:43 PM
Wow what a piece of kit! good job! and keep up the good work!
Anyway There's a couple of things happening that I cant get right i'm getting allot of stuck notes, when i play with 2 outputs and 2 note polyphony on each this is static test with a piezo speaker on the 2 outputs. using synth font tried direct output then hairless/loop-midi which improved it slightly i tried using the usb to Midi hub then to midicable/opto coupler but was even worse with that, Ive scoped the opto output and confirmed the signal was getting to syntherrupter perhaps its the midi file.
I only have 2 small identical coils i want to use with this plus a one tesla TS i may try to set up but i will need to scope the TS interrupter to input the limits for syntherrupter.
Any help will be much appreciated.
Anyway a couple of pics of my build:
[ Invalid Attachment ] [ Invalid Attachment ]
[ Invalid Attachment ]
Post by: Max on April 23, 2021, 10:48:58 AM
I need a bit more details about how you got those stuck notes. Also, for future problems, note that GitHub Issues are usually more comfortable for issue handling than a long forum thread.
- Firmware version?
- I assume you had not touched any of the MIDI Coil Settings (Channel assignments, stereo mode)?
- Could you provide me the specific MIDI file? Or does it happen with any file?
- What instrument/MIDI Program had you selected and how many channels did you forward to Syntherrupter (Or simply make a screenshot of SynthFonts Plug&Play view tab).
- You could also enable logging in hairless midi serial and provide me a screenshot of that log. Then I can see the exact commands that caused the issue.
- SynthFont used to have a bug where it wouldn't send the correct stop commands when pausing/stopping. I guess that's not what you're experiencing.
Since I'm already here, @Mads I have good news for you! Nextion updated their editor and now the pic1 attribute is available for all devices, meaning that there's no incompatibility anymore with the Intelligent series. As a consequence, I'll from now on release the firmware for all 5 and 7 inch Nextion/TJC screens. No more messing around :)
That update also fixes a bug which caused flickering in dark mode and sometimes slower page loading times.
Kind regards,
Max
Post by: SimonNwardUK on April 24, 2021, 11:52:04 AM
yes no prob you can use the pictures, IL post more in due time ;-)
my bad il post on github for future problems.
I cant play on the coils as i have no space to run them, the place i was using was restricted because of covid but should be able to get back there soon, for now its on piezo speakers, i may remove the secondarys and set up dummy loads and do it that way.
I was running latest firmware id only assigned channel 1 and 2 others were set to none and stereo disabled and forwarded channel 1 and 2 to loop midi in synthfont. Im going to try some other files to see if i can replicate the problem and i will try to get some screenshots of hairless midi output log when (if) it does it again. oh the latest free synthfont i am using doesn't seem to send the stop commands when stopping or pausing Ive had the last notes just stuck playing i noticed that also lol ;-) ,Im going to move to fruityloops for now to rule out synthfont.
Thanks Max keep up the good work!
Sy
Post by: Max on April 24, 2021, 12:12:10 PM
I was pretty sure the missing stop commands had been fixed in SynthFont? Kinda surprises me to hear that it would still happen in the current version. If the hairless midi serial log confirms this, I'll certainly ask the dev of SynthFont again because he's been very helpful so far (it was actually his suggestion to integrate direct serial out for me).
Looking forward to the results of your investigations!
Kind regards,
Max
Post by: Max on April 26, 2021, 11:46:59 PM
Anyways, I THINK it's fixed for good now.
Other news: as promised this update is the first one to support all Nextion devices including the Intelligent series. Actually, at the moment the high end Intelligent screens are the cheapest of all possible models, so by all means, go for them. Of course, all of these changes are already included in the corresponding wiki article (https://github.com/MMMZZZZ/Syntherrupter/blob/v4.1.4/Documentation/Wiki/Minimum%20Viable%20Setup.md#display).
Link to the new release v4.1.4: https://github.com/MMMZZZZ/Syntherrupter/releases
Kind regards,
Max
Post by: SimonNwardUK on April 27, 2021, 05:12:44 PM
Wow good to see an update so soon cool :D, I have a few hours to have a play today so i will update now :D
keep up the good work ;-)
Sy
Post by: SimonNwardUK on May 03, 2021, 10:07:26 PM
I Have Been doing some testing on the new version and it has fixed the stuck notes many thanks ;-), I've also tested with the Opto-coupler MIDI interface and this works also now ;D
I will be doing more testing with this setup as this is my preferred connection and i will be wanting to play a keyboard through the midi DIN port hopefully, I am putting some midi files together now so going to keep it 2 note poly for each channel so i can turn my on-times up i like my ground strikes :D anyway a few more pics of my build feel free to use them.
keep up the good work.
Sy
Post by: Max on May 16, 2021, 02:27:45 AM
Download: https://github.com/MMMZZZZ/Syntherrupter/releases
As announced in previous posts I've been working on this for a while now. Sysex is a part of the MIDI standard that allows manufacturers to embed pretty much whatever they want within the MIDI standard (meaning: without breaking compatibility with any other MIDI device). Most often these are used to configure all the device specific settings and options. Syntherrupter is no exception; with the new beta you can control (almost) everything using these commands.
I recommend using Syfoh (https://github.com/MMMZZZZ/Syfoh#readme) - a Python tool that allows you to write your Sysex commands in human-readable text form. It can also load a bunch of settings from a given text file such that you can easily store complex configurations for different MIDI files and load them with one click.
There are still a few limitations though:
- (Almost) nothing that you change with Sysex will be stored in EEPROM. Meaning, after a power cycle the changes are lost (which isn't too dramatic since you usually have them stored somewhere).
- (Almost all) commands will update the on-screen values only if you have no mode and no settings opened (meaning: if you're viewing the main menu. I added a note there). The commands will always be received and applied by the Tiva microcontroller, but since they could cause conflicts with whatever you're currently doing on the screen itself, the screen will only be updated if you're doing nothing for sure (a.k.a. you're in the main menu).
- There are a lot of commands with lots of options resulting in an awful lot of things that could go wrong. I haven't test every command in every combination. Actually I didn't test a lot of commands. So don't expect it to work flawlessly. I shared it mostly because I think it's exciting and worth trying even though it's not perfect.
- No export options. Currently Syntherrupter can receive Sysex commands, but not send any.
I'll try to make a little demo video in the next days (or weeks...). It really is a great help and for stage perfomance I'd say invaluable (or in other words: stage performance with Syntherrupter without this is not possible to the same extend).
Kind regards,
Max
Post by: Max on May 31, 2021, 12:06:33 AM
Together with the Sysex work I rewrote the EEPROM settings stuff from scratch. It really wasn't well-written* and in consequence hard extend by new features. For the devs among you: Back at v2 when I first wrote this, I had no idea a thing called "union" exists and for some reason I preferred arrays and void pointers to structs. Also, in the aim of minimizing the size, a lot of data was not byte aligned. Since there's enough space available, that pain in the ass is gone now, too.
*well, lets say the data structure was garbage. The code that actually reads/writes the EEPROM is okay and mostly unchanged with the new version.
This new code base not only allows changes made via sysex to be stored just like changes made in the UI, it also allows me to easily add new values in future version. They will - just like this version does - import the settings from any old EEPROM layout and update it to the newer version.
Quite some more related things under the hood got better by these changes, too.
Various wiki pages got updates, too. Please check the release notes for details. Release notes? Yes, of course these news come with a new firmware release. Needless to say that they contain more details about what's been added/fixed with this update. https://github.com/MMMZZZZ/Syntherrupter/releases
Note that you need to pull the latest version of Syfoh; both Syfoh and previous Syntherrupter firmware versions had the same bug in the protocol.
Kind regards,
Max
Post by: Max on June 04, 2021, 09:46:56 PM
Since I'm tired of the piezo sound and blinking LEDs I'm currently working on my own little tesla coil orchestra. For that I need of course a 6-outputs version of Syntherrupter and designed a PCB for this purpose. Any feedback or advice would be appreciated (especially whether it seems useful for others, too). PCB size is 160x100mm.
Kind regards,
Max
Post by: futurist on June 06, 2021, 11:18:46 AM
Is the board designed to fit in particular enclosure?
Post by: Max on June 06, 2021, 03:01:44 PM
No, it's not made for a particular enclosure. I designed the PCB "as compact as possible" and the next biggest size was 100x160mm which is a very common size (eurocard). Thus there should be many different enclosures available.
Kind regards,
Max
Post by: Mads Barnkob on June 06, 2021, 08:41:31 PM
I think some of your resistor values will need tweaking when running on 5V, I had to change some of my initial design as it was too high values for my LEDs, but yeah that differs from build to build what parts are used and how bright you want something to be that sits in a dark room.
You could add a row of pin headers for external interrupters and a DIP switch row to select which is used, might not be for everyone, but I am making that on my build. Since optical outputs are money, might as well make them useful in more ways :)
My final exam was Friday two days ago, im done with studying next work, which I have been doing for 3 years, so I can finally pick up on my DRSSTC show controller again :) https://highvoltageforum.net/index.php?topic=1417.0
Post by: Max on June 07, 2021, 12:12:07 AM
Could you be a bit more specific about the resistors? Here are my calculations behind the values:
560R base resistor: Desired base current: 5mA. (3.3V_pin_high - 0.6V_base) / 5mA = 540R
68R IR transmitter: Desired LED current: 40mA (nominal current: 60mA). (5V - 1.7V_f - 0.6V_ce) / 40mA = 68R
270R LED resistor: Desired LED current: 10mA. (5V - 2V_f - 0.6V_ce) / 10mA = 240R
Actually, I could change the 270R for a 220R; getting rid of one resistor value since 220R resistors are required for the MIDI In/Out circuit anyways.
I added a pin header for a MIDI Out port which might be used in future. I also added the footprint for one of these generic SD card breakout boards.
Congrats for your exams!
Kind regards,
Max
Post by: Max on June 18, 2021, 01:22:10 AM
I took a little break from the PCB design and worked on an issue Syntherrupter basically has since the day it learned playing more than one note at the same time. So far the generation of the output signal happens in real time: if (time > notePeriod): generateOntime(); (overly simplified, but enough to get the idea). The big issue is that any sort of processing elsewhere in the code always has a direct impact on the output. You can test it in the current beta; every sysex command you send to Syntherrupter will cause a short pause in the output. On a smaller timescale, the regular processing which only takes 30-70us is already too much jitter in the output. This is especially noticeable in simple mode. If you play around for a bit you'll for sure find frequencies that sound "not-so-clean" or straight out awful. There's also a limit in how high you can go in the frequency before that blocking limits you.
Oh, and a third issue: if 30us are already too much time, I can't really write "heavy" code (one of the reasons why I haven't touched SD cards and file systems; there may be blocking operations...).
So far for the status quo. I've had a lot of thoughts for how to solve this, including Netzpfuschers suggestion to switch to FreeRTOS. However, FreeRTOS can't solve the blocking and is by far not fast/efficient enough to handle the signal generation via tasks. From all I could find it operates with >=1 millisecond of resolution which is not suitable at all if 30us jitter/delay are already too much. It may make some things easier but it won't solve this issue.
Another idea was to somehow limit the processing to the time after an ontime where it would be the least likely to delay another ontime. However, that doesn't work anymore as soon as you have more than one note.
I also tried to enforce the output generation via fast, periodic interrupts, and that failed greatly. Either the frequency is so low that it sounds like crap, or it is so high that I'm running out of CPU time.
For a while now I've been thinking that buffering is pretty much the only reasonable option. Over the last few weeks I've been working on a buffered solution and now I can say with some confidence that it looks very good. At first I tried to implement ping pong buffers but that didn't quite work. Therefore I switched to one FIFO buffer which works very well so far. When previously the jitter was in the order of tens of microseconds (and well audible), it is now in the tens of nanoseconds range - or in other words: it couldn't be any better. Not only is the jitter gone, sysex processing doesn't cause stuttering anymore either. Currently I'm buffering for 5ms which should be short enough to not be audible. The buffer time will be adjustable through sysex.
Btw: someone mentioned that buffering will take more CPU time than the previous real time solution. And he's absolutely right. The signal generation part is easily twice as complex now. However, I'm nowhere near stressing out the CPU - or in other words, buffering frees up more CPU time than it eats away.
While this is great (and long overdue), there are still issues and glitches I need to track down. I can't tell you when I can release it but the current progress shows that it's feasible so it will be released one day...
Kind regards,
Max
Post by: Georgios on July 13, 2021, 07:38:44 PM
Post by: SimonNwardUK on August 08, 2021, 11:21:53 AM
I see an SD card Image ;D Does this mean we can Eventually read a Midi file from the SD and then play through syntherrupter as a standalone unit? ;) ;)
Just a quick Question as I've looked on the wiki and cant find anything resembling what I'm looking for, I have a Midi enabled keyboard that i can connect directly to sytherrupter in Live mode (using the DIN socket), Everything works brilliantly and the coil sounds really nice but.. the keyboard outputs velocity sensitive keystrokes and i cant disable it on the keyboard and this caught me out which caused my coil to do a heavy ground strike although looked awesum at the time, i want to avoid hitting the ocd often if i can when playing midi so is there something i can change to get a fixed velocity value? its probably there just haven't found it yet.
Thanks
Sy
Post by: Max on August 08, 2021, 12:09:01 PM
The SD card is a planned feature for the future (to be understood as maybe in a year). First I need to get these damn buffered outputs working - and they‘re causing me quite some headaches. They work fine 90% of the time - and the other 10% have been a nightmare to debug.
As for the velocity and the keyboard, the short answer is, no, there‘s currently no option for fixed velocity. However, there are a couple other options. First a quick note how the ontime is calculated:
finalOntime = note.velocity * channel.expression * channel.volume * note.envelope * ontimePreset
Channel expression is used for nuances (crescendo, piano, forte, etc). Channel volume is used to control the volume of the channel - both have the same effect but they’re independent controllers (abd shouldn‘t be mixed). Ontime preset is what you set in MIDI Live Mode on the touch screen.
With this in mind you got a couple options:
- Adjust the ontime and duty settings on your touch screen. Maybe try a different balance between both?
- Some keyboards have the ability to change the channel volume (possibly buried somewhere in the settings)
- Don‘t forget about the coil limits. They‘re exactly for what you describe; make sure the ontime or duty doesn‘t exceed certain limits.
Kind regards,
Max
Post by: futurist on August 14, 2021, 12:23:11 PM
finally some feedback from me, playing midis posted by Georgios. Two coils each playing one channel sounds spectacular!
I had problem with "karusel RUSSIA" midi which wouldn't produce sparks, I didn't have the oscilloscope to check why. Georgios played the midi on his coil and it sounds excellent
I planned to test it further, however secondary of bigger coil fried itself beyond repair
[ Invalid Attachment ]
I suspect the alkyd coil varnish caused the failure, it's not designed for this purpose and it was too thin (two coats if I remember correctly). When I tried to add more coats previous cured varnish started to dissolve. This time I'll use polyurethane varnish and see how it goes
Post by: Max on August 16, 2021, 01:52:09 AM
Today I fixed a few bugs, implemented some ideas for improving the buffering and somehow they seem to work now. Or let's say I haven't yet found a MIDI file that causes glitches or other issues. I guess this doesn't come across but I am really, really happy about this :D
Sooo... I recorded a quick demo. Pirates of the Carribean, the most furious piano edition I know. Links are below. MIDI file is a 1:1 representation of the original piano performance (including pedal!). No modifications have been made to the file. Settings (identical for all outputs):
Envelope Nr. 10 (realistic piano)
100us note ontime
0% note duty
0us min ontime
0us min offtime
1000us max ontime
25% max duty
16 voices per output
all 6 outputs enabled (1 recorded)
10ms buffering
As I said, it's a furious piece of music so the 16 voice limit per output is pretty much all the time maxed out. That makes for about 100 simultaneous voices - and there's still CPU time left!
Demo Recording (https://soundcloud.com/user-754038701/pirates-of-the-carribean-jarrod-radnich-syntherrupter-v420-beta4)
Original Piano Performance (https://www.youtube.com/watch?v=n4JD-3-UAzM)
Still some cleaning to do in the code but a release should follow soon.
Kind regards,
Max
Post by: Max on August 17, 2021, 02:36:01 PM
After some more bugfixes I feel comfortable enough to release the new work. Note that some of these bugs have been around for quite some time. The buffering aside, there are some new, useful sysex commands. Details as always in the release notes and the wiki.
Current release: https://github.com/MMMZZZZ/Syntherrupter/releases
Regards,
Max
Post by: Max on August 18, 2021, 07:56:25 PM
Envelopes - What's the point?
Many people seem to underestimate the benefits of envelopes (ADSR). Take the MIDI file of the following piano performance:
There's a lot of pedal, lots of repetitive notes. With a "classic" Interrupter (let's just assume it could handle that many voices), you'd easily spent hours to remove all pedal commands from the MIDI file and shorten all the notes to make them more distinguishable. Why? Because otherwise it sounds like this:
Pirates of the Carribean - No Envelope (https://soundcloud.com/user-754038701/pirates-of-the-carribean-jarrod-radnich-no-envelope-syntherrupter-v420-beta4)
You can't distinguish one note from another because they're all the same constant volume. Beginning, ending - all one level. Repetitive notes thus merge into one long note. Pedal is completely unusable because the notes don't fade out. Too many notes at the same time and same volume simply becomes a cacophony.
However, with only two clicks in any MIDI player I can change the instrument and select the piano envelope of Syntherrupter. This envelope has been made based on the recordings of a piano and thus has similar characteristics. Even the pedal - which is hard to get right - sounds good.
Pirates of the Carribean - With Envelope (https://soundcloud.com/user-754038701/pirates-of-the-carribean-jarrod-radnich-syntherrupter-v420-beta4)
Edit: The behavior at 1:38 (beginning of the glissando is missing) could be a bug or a combination of the envelope and the voice limit. As you can see, there‘s always room for improvements ;)
Try it out!
Max
Post by: Max on August 20, 2021, 01:46:14 AM
Today I got my mini tesla orchestra working (though "only" with 4 out of 6 coils). While playing with it (and really enjoying the stereo capabilities), I repeatedly had to reset my Syntherrupter because one of the outputs would more or less randomly stop working. During the last recording of the day it also started to skip half of the notes.
Obviously I'll investigate the issue. I just wanted to notify everyone before you update. The release notes already contain a warning.
Here's a little preview of the orchestra. Since the sparks are only 1-2cm long they're almost not visible in the video. And I can't put the coils closer together because they interfere with each other.
Kind regards,
Max
Post by: Mads Barnkob on August 23, 2021, 09:03:15 AM
First thing was I could not find the midi channel settings per coil, since I was looking in the wrong part of the documentation :) Maybe a settings button underneath each coil activate button instead? I would also wish for a "midi signal" status blinker on the live midi mode page, just for trouble shooting between pc, syntherrupter and output modules. It would also give some more life to the very static page, when playing MIDI, you got no idea if its playing or not :)
I guess I can just contribute to the documentation on github? I think the PC MIDI setup chapter that you put out in the "front" readme, needs some more integration into the main documentation.
All channels activated for all coils as default, also had me confused, because that sounds very weird and wrong the first time you just try to play a midi. Maybe add new defaults that is just channel 1 to coil 1, 2 to 2 etc.?
Thanks for the explanation on envelopes and demonstration, it really shows how powerful a feature it is.
Did I miss the "omni-mode" somewhere? I thought it could auto-assign midi channels according to active coils and also just randomly choose them? I might remember completely wrong.
As you can see, most of my comments are cosmetics on the UI and documentation, you are doing a great job!
I will admit that the learning curve seems steep, especially with SysEx, envelopes and such, but I hope it will soon make more sense and the prepared midi files on PC for a certain coil setup can just be played and all settings for the coils, channel assignment and such is in the files.
Post by: Max on August 23, 2021, 10:46:08 AM
Before I get to your feedback a quick update about my work: I found one major bug that caused the missing notes. However, it had nothing to do with the buffering. It was actually a rather old bug in the stereo processing that somehow never caused me any noticesble trouble before. Now that this is fixed it seems to be quite a bit better. Most of my issues now come from the mini teslas which are quite hard to control actually. However, I‘m still not convinced Syntherrupter works as it should… hopefully a couple more hours of debugging help resolving this.
This btw also means that the v4.2.0-beta.4 release isn‘t as flawed as I thought.
And now for the feedback:
Quote
Maybe a settings button underneath each coil activate button instead?The double outlined buttons are used in more places. For that reason it‘s explained on the Help and Info page. I thought about showing that one the first time Syntherrupter‘s started but never got to the implementation.
I could for sure add separate buttons in every case but it would make the UI quite a bit more complicated and probably much less clean (this is especially true for the Coil Settings page which is pretty well filled).
Quote
I would also wish for a "midi signal" status blinker on the live midi mode page, just for trouble shooting between pc, syntherrupter and output modules. It would also give some more life to the very static page, when playing MIDI, you got no idea if its playing or not :)I know the UI is very static. This is because the Nextion commands for controlling the UI from the Tiva sideare quite expensive (string based). With the buffered outputs and an optimized serial library I might get it to work. However, I‘d much prefer tossing out the Nextion protocol entirely and replacing it by something custom. Both cases require quite some work to do so it‘s not for anytime soon. Actually, getting live readouts was a feature I planned for Syntherrupter 2 only. We shall see…
Til then I‘d suggest to just hook an LED (with resistor) between 3.3V and the serial line.
At this point I realize a little troubleshooting guide could be nice. Here‘s the thing with hairless MIDI Serial: there‘s only one case I‘ve ever seen where it doesn‘t work and that‘s when the serial port disappears for some amount of time or becomes unavailable (f.ex. disconnect and reconnect the cable) in that case it still shows it‘d send stuff but if you disable and reenable the serial bridge you‘ll see that it actually doesn‘t send anything to the port. You need to restart it.
Other than that you can be about 99.x% sure that if hairless midi serial shows it sent data to Syntherrupter, it did - and Syntherrupter actually received it.
Btw in hairless midi serial you can activate the logging window and see what midi commands are sent to the port. Can be handy.
Quote
I guess I can just contribute to the documentation on github? I think the PC MIDI setup chapter that you put out in the "front" readme, needs some more integration into the main documentation.Any contribution is more than welcome! :)
Quote
All channels activated for all coils as default, also had me confused, because that sounds very weird and wrong the first time you just try to play a midi. Maybe add new defaults that is just channel 1 to coil 1, 2 to 2 etc.?I had my 4 mini teslas play the same channels now a couple time; didn‘t sound weird and wrong to me…? Or did you just forward all channels to Syntherrupter? In a complex MIDI file this is likely way too much (and would explain your description). However, that‘s not a good idea to begin with. You should only pass the channels to Syntherrupter you want it to play. There‘s no point in loading it with additional channels that are „muted“. Even if they‘re not audible Syntherrupter needs to keep track of all the volume, pitchbend, envelopes, etc in case you activate the channel again.
That aside I wanted to have a configuration that‘s guaranteed to work - for which I really can’t see an alternative. I‘d expect many more people to be confused if one channel works and another one doesn‘t (f.ex. chn 1 and 13).
Quote
Did I miss the "omni-mode" somewhere? I thought it could auto-assign midi channels according to active coils and also just randomly choose them? I might remember completely wrong.The stereo mapping features - which includes omni mode - is really the most hard to use feature of Syntherrupter*. First of all, omni mode only makes sense if you have stereo enabled. Quick recap: in stereo mode, every note has a position on the stereo scale. Every coil has a position, too, and it only plays the notes within its reach. Syntherrupter got a couple festures for making melodies move around across the stereo range (and thus across different coils) but you don’t always want that. Since every note has a precise position, you can’t really play it on multiple coils equally anymore. That’s where omni mode enters the game: if a MIDI channel is put into omni mode it doesn’t have a stereo position anymore but is „everywhere“ - thus can be played by all coils „normally“ again (as if no stereo stuff was enabled).
This probably sounded way more complicated than it is so let me try to do a tldr: omni mode disables stereo mapping for a given channel. That‘s it.
*that‘s because there‘s no easy to use UI or tool for it. You have to embed the raw commands into your MIDI file or send them to the MIDI port. With Synthfont it‘s actually not too hard to embed the commands but I understand that‘s a too steep lesrning curve for most people.
Quote
I will admit that the learning curve seems steep, especially with SysEx, envelopes and such, but I hope it will soon make more sense and the prepared midi files on PC for a certain coil setup can just be played and all settings for the coils, channel assignment and such is in the files.Syex might be a lot to begin with but when you‘re using Syfoh (and it‘s really the only practicable way to use sysex), it‘s basically just a command line interface for Syntherrupter - no more no less.
As for the envelopes I have to admit I really can‘t figure out what‘s so hard about using it. I‘m not talking about making your own envelopes or understanding how the envelopes themself work. I‘m just talking about the „high level“ concept of „you can change the instrument“ from „pizzicato strings“ to „piano“ or „electric guitarre“ or „slow strings“. The only confusing thing here is that syntherrupters instruments don’t match the instrument names in pretty much any MIDI player (syntherrupters piano sound f.ex. is MIDI program 10, called Music Box). Maybe someone can help me understand the issues better; I‘d really like to.
Don‘t mind about embedding the sysex commands into your midi file. I mean, yes, it could be done but the advantage over a simple text file that Syfoh sends to Syntherrupter is close to none - and much easier to use and modify at the same time.
Edit: as an example I attached such a sysex batch file which did the entire setup of Syntherrupter for playing my Final Countdown MIDI file (I just power on Syntherrupter; no interaction with the touchscreen is required). All it takes is one call of Syfoh.py and I'm ready to go. Ontimes, channel assignments, stereo positions - everything.
Windows command line for running Syfoh (sending all the data to MIDI port nr. 1 which happens to be loopmidi)
Code: [Select]
python Syfoh.py -m mid -p 1 -i "D:\Syntherrupter Setup for Final Countdown.txt"Content of the text file:
Code: [Select]
### Syntherrupter Sysex commands for mini orchestra
### Final Countdown.
# Setup stuff
set ui-update to manual
set mode-enable for mode all to 0
set coil-buffer-time to 10000
# Coil settings and limits
set coil-max-duty for coil all to 0.2
set coil-min-offtime for coil all to 0
set coil-min-ontime for coil 1 to 40
set coil-min-ontime for coil 2 to 15
set coil-min-ontime for coil 3 to 35
set coil-min-ontime for coil 4 to 10
set coil-midi-voices for coil all to 16
set duty for mode midi-live and coil all to 0.03
set ontime for mode midi-live and coil 1 to 200
set ontime for mode midi-live and coil 2 to 300
set ontime for mode midi-live and coil 3 to 200
set ontime for mode midi-live and coil 4 to 200
set mode-enable for mode midi-live to 1
# Distribute 4 coils across the stereo range
set midi-pan-cfg for coil all to linear
set midi-pan-reach for coil all to 0.333
set midi-pan-pos for coil 1 to 0.0
set midi-pan-pos for coil 2 to 0.333
set midi-pan-pos for coil 3 to 0.667
set midi-pan-pos for coil 4 to 0.999
# Assign channels to outputs
set coil-channels for coil 1 to 0b00011000000
set coil-channels for coil 2 to 0b00010000001
set coil-channels for coil 3 to 0b00010000010
set coil-channels for coil 4 to 0b10010000000
Kind regards,
Max
Post by: Max on August 23, 2021, 03:18:42 PM
New release, bugs fixed. Actually, only one bug's been introduced with the previous beta, all other bugs were around for much longer. Details as always in the release notes.
Get v4.2.0-beta.5: https://github.com/MMMZZZZ/Syntherrupter/releases/
Kind regards,
Max
Post by: Mathieu on August 29, 2021, 06:32:01 PM
Couldn't help myself, seeing the syntherrupter is wanting to build one. Kuddo's for this great project!
Last week my TJC8048X570_011R screen arrived. Connecting it to 5V supply showed the off-factory test HMI. Hurray :)
I used the v4.1.4 version for the Tiva, since this was the first release with the tft-files for this screen. MicroSD update and screen responded with "Upgrade successed", so that raised the expectations considerably. After connecting it to Tiva however the screen remained dark.
Checking the Tiva without the screen using the debug mode in the Nexion Editor, but only for v4.1.3 (editor 1.61.1). This worked!
Testing with 4.1.4 and editor 1.62.1 was not possible because I was not able to find the local zip file for this editor version. The link in the wiki refers to a 404.
Next available editor version 1.63.3, but I guess that the tft files in the syntherrupter releases are made with 1.62.1 and are not compatible with the newer editor?
The next tests were with the Chinese USART HMI editor (1.63.3). In this one I could open the TJC tft's for the X-series, trying to open the TJC K- and T- series were met with an "invalid file" message. However trying to use the debug mode and see if Tiva would interact with the virtual HMI was similar to the first attempt, the virtual screen also remained dark.
With the USART HMI editor I can update the screen, so the serial comm seems to work.
Could this problem be related to the tft file for tjc x-series screens?
Mathieu
Post by: Max on August 30, 2021, 06:13:21 PM
It‘s been a long week for me and quite a few things happened. The short overview: to my greatest annoyance the latest release (v4.2.0-beta.5) has at least one crucial (and new) bug. I had a demo this weekend and was forced to switch between beta4 and beta5 depending on what midi I played…
I also got some videos done with my big tesla coil. I had a big bang, repaired it (at least I thought), it worked again, but only for a short time, then I noticed sparks (!) around the busbars. My backup plan, the mini tesla coils, decided to not produce any reasonable output for about 10mins and then finally started to work. The kids were quite amazed with what they got to see (which were only the mini tesla coils) so I guess it‘s still kind of a win. Nonetheless I‘m quite annoyed that nothing (!) of what I had prepared worked as intended.
As I said, some loong days.
I have sort of a suspicion where the bug in the latest release comes from. If that suspicion is true, it‘ll be an easy fix. Otherwise it‘s going to be another long day. In any case I won‘t be able to look at it til end of september.
@Mathieu:
Quote
After connecting it to Tiva however the screen remained dark.This sounds like you got the serial connections between the Tiva microcontroller and the Nextion display somehow wrong. The good news is that apparently you flashed everything correctly.
Checking the Tiva without the screen using the debug mode in the Nexion Editor, but only for v4.1.3 (editor 1.61.1). This worked!
I know about the missing nextion editor versions - it‘s annoying but I can‘t fix it anytime soon. Shouldn’t be a problem for you though because - as I said - you likely have an issue with your wiring.
Kind regards,
Max
Post by: futurist on August 30, 2021, 06:44:00 PM
Post by: Mads Barnkob on August 30, 2021, 08:05:20 PM
QuoteMaybe a settings button underneath each coil activate button instead?The double outlined buttons are used in more places. For that reason it‘s explained on the Help and Info page. I thought about showing that one the first time Syntherrupter‘s started but never got to the implementation.
I could for sure add separate buttons in every case but it would make the UI quite a bit more complicated and probably much less clean (this is especially true for the Coil Settings page which is pretty well filled).QuoteI would also wish for a "midi signal" status blinker on the live midi mode page, just for trouble shooting between pc, syntherrupter and output modules. It would also give some more life to the very static page, when playing MIDI, you got no idea if its playing or not :)I know the UI is very static. This is because the Nextion commands for controlling the UI from the Tiva sideare quite expensive (string based). With the buffered outputs and an optimized serial library I might get it to work. However, I‘d much prefer tossing out the Nextion protocol entirely and replacing it by something custom. Both cases require quite some work to do so it‘s not for anytime soon. Actually, getting live readouts was a feature I planned for Syntherrupter 2 only. We shall see…
Til then I‘d suggest to just hook an LED (with resistor) between 3.3V and the serial line.
At this point I realize a little troubleshooting guide could be nice. Here‘s the thing with hairless MIDI Serial: there‘s only one case I‘ve ever seen where it doesn‘t work and that‘s when the serial port disappears for some amount of time or becomes unavailable (f.ex. disconnect and reconnect the cable) in that case it still shows it‘d send stuff but if you disable and reenable the serial bridge you‘ll see that it actually doesn‘t send anything to the port. You need to restart it.
Other than that you can be about 99.x% sure that if hairless midi serial shows it sent data to Syntherrupter, it did - and Syntherrupter actually received it.
Btw in hairless midi serial you can activate the logging window and see what midi commands are sent to the port. Can be handy.
Thanks for the clarifications. It all makes sense and it was just suggestions based on what I see. Its a complex software you have put up and even with the good wiki, we are not inside your head :)
QuoteI guess I can just contribute to the documentation on github? I think the PC MIDI setup chapter that you put out in the "front" readme, needs some more integration into the main documentation.Any contribution is more than welcome! :)
I tried my first github contribution, which also explains why you were after me for not writing a comment. I was not quite aware if it was submitted without pull request? This is my first time using github, so bare with me. I wanted to try something simple before editing large parts of the wiki.
QuoteAll channels activated for all coils as default, also had me confused, because that sounds very weird and wrong the first time you just try to play a midi. Maybe add new defaults that is just channel 1 to coil 1, 2 to 2 etc.?I had my 4 mini teslas play the same channels now a couple time; didn‘t sound weird and wrong to me…? Or did you just forward all channels to Syntherrupter? In a complex MIDI file this is likely way too much (and would explain your description). However, that‘s not a good idea to begin with. You should only pass the channels to Syntherrupter you want it to play. There‘s no point in loading it with additional channels that are „muted“. Even if they‘re not audible Syntherrupter needs to keep track of all the volume, pitchbend, envelopes, etc in case you activate the channel again.
That aside I wanted to have a configuration that‘s guaranteed to work - for which I really can’t see an alternative. I‘d expect many more people to be confused if one channel works and another one doesn‘t (f.ex. chn 1 and 13).
You are right, I just loaded up a MIDI and pressed play. Break-the-build testing style! Maybe there is more to it, I do not have a video of this: deselect all channels for coil 1, select channel 1, press next, deselect all channels for coil 2, select channel 2, press next. Do this for all 6 coils. At the 6th coil, pressing next showed me coil 1, but with channel 16 selected as the only. Pressing next now showed coils 2 with 15, 3 with 14 and so on. Getting to the 6th coil and pressing next showed me channel 1 for coil 1. IS there really 12 pages or 6 pages? I can not see any difference, but the number of configured channels... :-[
QuoteDid I miss the "omni-mode" somewhere? I thought it could auto-assign midi channels according to active coils and also just randomly choose them? I might remember completely wrong.The stereo mapping features - which includes omni mode - is really the most hard to use feature of Syntherrupter*. First of all, omni mode only makes sense if you have stereo enabled. Quick recap: in stereo mode, every note has a position on the stereo scale. Every coil has a position, too, and it only plays the notes within its reach. Syntherrupter got a couple festures for making melodies move around across the stereo range (and thus across different coils) but you don’t always want that. Since every note has a precise position, you can’t really play it on multiple coils equally anymore. That’s where omni mode enters the game: if a MIDI channel is put into omni mode it doesn’t have a stereo position anymore but is „everywhere“ - thus can be played by all coils „normally“ again (as if no stereo stuff was enabled).
This probably sounded way more complicated than it is so let me try to do a tldr: omni mode disables stereo mapping for a given channel. That‘s it.
*that‘s because there‘s no easy to use UI or tool for it. You have to embed the raw commands into your MIDI file or send them to the MIDI port. With Synthfont it‘s actually not too hard to embed the commands but I understand that‘s a too steep lesrning curve for most people.
Thanks for cutting it out in paper, I will leave it be until I master the other parts :)
QuoteI will admit that the learning curve seems steep, especially with SysEx, envelopes and such, but I hope it will soon make more sense and the prepared midi files on PC for a certain coil setup can just be played and all settings for the coils, channel assignment and such is in the files.Syex might be a lot to begin with but when you‘re using Syfoh (and it‘s really the only practicable way to use sysex), it‘s basically just a command line interface for Syntherrupter - no more no less.
As for the envelopes I have to admit I really can‘t figure out what‘s so hard about using it. I‘m not talking about making your own envelopes or understanding how the envelopes themself work. I‘m just talking about the „high level“ concept of „you can change the instrument“ from „pizzicato strings“ to „piano“ or „electric guitarre“ or „slow strings“. The only confusing thing here is that syntherrupters instruments don’t match the instrument names in pretty much any MIDI player (syntherrupters piano sound f.ex. is MIDI program 10, called Music Box). Maybe someone can help me understand the issues better; I‘d really like to.
Don‘t mind about embedding the sysex commands into your midi file. I mean, yes, it could be done but the advantage over a simple text file that Syfoh sends to Syntherrupter is close to none - and much easier to use and modify at the same time.
Edit: as an example I attached such a sysex batch file which did the entire setup of Syntherrupter for playing my Final Countdown MIDI file (I just power on Syntherrupter; no interaction with the touchscreen is required). All it takes is one call of Syfoh.py and I'm ready to go. Ontimes, channel assignments, stereo positions - everything.
Windows command line for running Syfoh (sending all the data to MIDI port nr. 1 which happens to be loopmidi)Code: [Select]python Syfoh.py -m mid -p 1 -i "D:\Syntherrupter Setup for Final Countdown.txt"
Content of the text file:Code: [Select]### Syntherrupter Sysex commands for mini orchestra
### Final Countdown.
# Setup stuff
set ui-update to manual
set mode-enable for mode all to 0
set coil-buffer-time to 10000
# Coil settings and limits
set coil-max-duty for coil all to 0.2
set coil-min-offtime for coil all to 0
set coil-min-ontime for coil 1 to 40
set coil-min-ontime for coil 2 to 15
set coil-min-ontime for coil 3 to 35
set coil-min-ontime for coil 4 to 10
set coil-midi-voices for coil all to 16
set duty for mode midi-live and coil all to 0.03
set ontime for mode midi-live and coil 1 to 200
set ontime for mode midi-live and coil 2 to 300
set ontime for mode midi-live and coil 3 to 200
set ontime for mode midi-live and coil 4 to 200
set mode-enable for mode midi-live to 1
# Distribute 4 coils across the stereo range
set midi-pan-cfg for coil all to linear
set midi-pan-reach for coil all to 0.333
set midi-pan-pos for coil 1 to 0.0
set midi-pan-pos for coil 2 to 0.333
set midi-pan-pos for coil 3 to 0.667
set midi-pan-pos for coil 4 to 0.999
# Assign channels to outputs
set coil-channels for coil 1 to 0b00011000000
set coil-channels for coil 2 to 0b00010000001
set coil-channels for coil 3 to 0b00010000010
set coil-channels for coil 4 to 0b10010000000
Kind regards,
Max
Envelopes itself was only confusing, because I thought I had to configure them on the Syntherrupter. I understood it fine with names not fitting, but that it was instrument 0 to envelope 0. Part of this is also from just playing a MIDI without preparing channels, instruments or anything, as I wrote above. The demonstration in my latest project video should show it better? Did I explain it as it was intended to work?
Your syfoh sysex examples are great! From looking at the sysex documention, you should really add these examples, again it looks rather complex from all the formatting and explanation of the sysex package. Which confused me a bit before finding the tiny link to syfoh, that should be the first link in bold right after sysex headline :)
Bummer about your show and coils exploding, any graphic pictures to show in your DRSSTC thread?
You will properly fix all your bugs before I finish the 19" rack case, "only" projects left after audio inuts, safety and power supply.
Post by: Max on September 01, 2021, 06:41:48 PM
Quote from: futurist
Sorry to hear that. What happened to your coil?
Quote from: Mads Barnkob
Bummer about your show and coils exploding, any graphic pictures to show in your DRSSTC thread?The short answer: I don‘t know. The long answer - well… is long enough for its own thread. I do have video material of the crash but haven‘t had the time to put it into a half decent video. Btw I don‘t have a thead for my tesla coil in this forum yet? I plan to make one because there have been some really confusing things where I‘d like to get some input. But again, no time for such a post in the next weeks.
Quote
Its a complex software you have put up and even with the good wiki, we are not inside your head :)This is so true. I try to find a balance between the length of my posts and the amount of details I share. There are dozens of such thoughts behind pretty much every feature and compromise and while I‘d like to share every single one with y‘all I think this would be simply too much. The wiki f.ex. is already much more text than most users will ever read… I‘m not even sure people are reading the release notes. Therefore I try to stick to the „what“-surface and leave out the „why“-rabbit holes.
I guess I could make a separate thread where I explain the latter ones (as f.ex. the buffered outputs, how my exponential envelopes work, why some bugs were so hard to find, …). However, I‘m not sure the interest is there for such deep dives.
Oh btw. So far I haven‘t found any new bugs related to the buffered outputs. I certainly am happy about this though I‘m for sure not naive enough to call the buffering code bug free. (The nasty bug from the latest release sits in another part of the software.)
Quote from: Mads Barnkob
I tried my first github contribution, which also explains why you were after me for not writing a comment. I was not quite aware if it was submitted without pull request? This is my first time using github, so bare with me. I wanted to try something simple before editing large parts of the wiki.You did most things right. The fork, the pull request - both fine afaik. My only issue was that your commit was titled with the default description „Update Readme.md“ which doesn’t give any hint about what actually happened.
There are some good tutorials for Git(Hub) out there. To give a little tl;dr, git is like email. A protocol. GitHub, GitLab and others are like Outlook, Gmail, … Companies offering servers (and in most cases webinterfaces) for using the mail protocol in a much more convenient way. GitHub Desktop and other desktop applications are the equivalent of Thunderbird and others; desktop programs to write emails respectively commit source code to a git repository.
I personally use GitHub Desktop as it‘s very easy to use and covers most of my needs. Not sure what you used but if it‘s the webinterface I strongly suggest to use GitHub Desktop (or any other desktop client you like).
Quote from: Mads Barnkob
I do not have a video of this: deselect all channels for coil 1, select channel 1, press next, deselect all channels for coil 2, select channel 2, press next. Do this for all 6 coils. At the 6th coil, pressing next showed me coil 1, but with channel 16 selected as the only. Pressing next now showed coils 2 with 15, 3 with 14 and so on. Getting to the 6th coil and pressing next showed me channel 1 for coil 1. IS there really 12 pages or 6 pages? I can not see any difference, but the number of configured channels... :-[Hah - I had the same issue recently. Then, before the latest release I tried to reproduce it and failed to do so (not sure why). So I did not follow it any further. What I can tell you is that there are only 6 coils, not 12. It is a bug that‘s only in the Nextion firmware, in the save/loading code of the button states (every time the page (re)loads or exits the button states are loaded from/saved to a variable. And apparently I‘m not loading/storing the bits in the same order). This means that the first time you configure the channels everything works as expected. However, when you come back to the same page (and leave it again) the now wrongly displayed channels will be sent to the tiva microcontroller. Of course you can fix this by hand every time you open the page if you like to.
I‘ll keep it in mind for the next release.
Quote from: Mads Barnkob
Your syfoh sysex examples are great! From looking at the sysex documention, you should really add these examples, again it looks rather complex from all the formatting and explanation of the sysex package. Which confused me a bit before finding the tiny link to syfoh, that should be the first link in bold right after sysex headline :)Noted. Will change that for the next release. (Unless you‘re faster ;) )
Kind regards,
Max
Post by: Max on September 13, 2021, 10:51:27 PM
to my greatest annoyance the latest release (v4.2.0-beta.5) has at least one crucial (and new) bug. [...] I have sort of a suspicion where the bug in the latest release comes from. If that suspicion is true, it‘ll be an easy fix. Otherwise it‘s going to be another long day.As so often the truth was somewhere inbetween. It's been a rather long day finding the bug and verifying everything but in the end it was almost what I thought and nothing really complicated.
I fixed other things, too, which have been mentioned here. They're all listed in the release notes.
I currently don't have access to a "full" Syntherrupter with display and outputs and everything so I could only do very limited testing. But since this release just fixes a few specific bugs without touching other stuff I don't expect issues. Nonetheless, you should know.
As always, the new release (v4.2.0-beta.6) can be downloaded here: https://github.com/MMMZZZZ/Syntherrupter/releases
Kind regards,
Max
Post by: Mathieu on September 17, 2021, 03:42:10 PM
I'm not strong in programming, but is there a difference between 4.1.3 and later that could cause this for this specific screen (tjc8048X570)? For instance, I cannot find a "rest" message being send to the screen in later releases, but for now can not really understand how this would explain it. All in all quite some steps forward :D
(https://highvoltageforum.net/proxy.php?request=http%3A%2F%2F%5Battachment%3D1%5D%5B%2Fattachment%5D&hash=0c82d6fed55acc164f4acdd9cd8f1251675d9e42)
Best regards,
Mathieu
Post by: Max on September 17, 2021, 06:44:43 PM
What makes your issue so weird is that between v4.1.3 and v4.1.4 nothing changed in the Tiva firmware that could affect the startup behavior. The only change in the firmware was a fix in the MIDI code. With v4.1.4 I changed the Nextion Editor version but that had no effect on the Tiva firmware.
Actually, there is one difference: the version number. But I cannot imagine why that would break the handshake (especially since the version number is sent after the actual handshake, together with all the other data and right before the startup screen is displayed).
It's only with v4.2.0-beta.2 that I reworked the startup code on the Tiva side. Wanting to reproduce your setup, I had to realize that the Nextion/TJC editor is actually not compatible with the reworked code. Nextion screens send special messages when they start, signalling that they're ready. The beta.2 rework uses those messages (previous versions didn't), but unfortunately the Nextion/TJC Editor does not send them (unlike the devices). Maybe this will change in a future version but for now it means that the editor isn't very helpful.
I don't have a TJC screen so I can't reproduce your exact situation. All I know is that the firmware versions in question work on my Tiva + Nextion Basic screen, and Mads has v4.2.0-beta.3 successfully tested on his Tiva + Nextion Intelligent screen - the latter being the Nextion version of your screen.
From all this I assume the following things:
- Your wiring is correct and communication can work. Otherwise a different firmware couldn't fix the issue
- Other people with similar setups are not affected. This points to an issue that's particular to your setup - especially towards the TJC X5 screen.
- Have you tried doing a Nextion update over serial? It'd be a good check that the serial connections are solid.
- Do you have any possibility for capturing the communication between the screen and the Tiva? That'd provide me something to analyze and hopefully give us a clue what's going on. I'd be good to see both the working and the non working communication. Logic analyzer would be the easiest thing but you can also hook up two Serial-USB converters (each one with its RX pin to one of the serial lines) and log the connection - you only need to somehow capture the timing, too, since that's important.
- Out of curiosity for how much weirder it can get... have you tried v4.1.2 or v4.1.1 on the Tiva?
- To be clear, the Nextion firmware apparently doesn't have any effect, right? And no v4.2.0-beta.x Tiva firmware works?
Max
Post by: Max on September 29, 2021, 03:49:45 AM
So far none of these things have been implemented in Syfoh so it will take another bit before a release will appear.
Speaking of the next release, it will feature headless operation. Since Syntherrupter can now be fully controlled using sysex, it's not mandatory anymore to have the Nextion UI running. At the same time I'll fix an issue introduced with the recent beta firmwares: the Tiva board does not enter passthrough mode automatically anymore. You either have to instruct it to do so using the UI or disconnect the screen for a few seconds during startup.
Regards,
Max
Post by: Max on October 05, 2021, 11:44:44 PM
Other possible use cases: check settings, export them, create backups. How? Glad you asked. To answer your questions, Syfoh (https://github.com/MMMZZZZ/Syfoh#readme) got some shiny new examples.
The new v4.2.0-beta.7 release got - of course - a couple other fixes and improvements. Listed as always in the release notes. https://github.com/MMMZZZZ/Syntherrupter/releases
Kind regards,
Max
Post by: Max on October 19, 2021, 11:31:51 PM
Most features developed during the beta phase have been more or less extensively tested. For that reason I consider them "stable". Additionally there have been a number of important bugfixes. Compared to the last beta there haven't been many changes. Mainly a fix for a bug introduced with v4.2.0-beta.3 that made it impossible to get a new Syntherrupter working.
Release notes and download: https://github.com/MMMZZZZ/Syntherrupter/releases
Kind regards,
Max
Post by: SimonNwardUK on October 26, 2021, 10:37:39 PM
a few pics taken from my phone video i was monitoring the file playback, current draw and the coils performance at the same time!
a few Pics of my setup:
[ Invalid Attachment ] [ Invalid Attachment ]
[ Invalid Attachment ] [ Invalid Attachment ] [ Invalid Attachment ]
Simon,UK
Post by: Max on November 21, 2021, 01:49:14 AM
@SimonNwardUK: Glad to hear. Thanks for the pics! Edit: which MIDIs did you play?
Kind regards,
Max
Post by: Max on December 02, 2021, 12:47:10 AM
On one hand this had to be expected, otherwise the non-buffered version could not have worked. On the other hand this is very reassuring; I wouldn't have thought that the load was that low. So it should be no issue to add tons of new stuff. Except that I don't have the time to implement it :(
Regards,
Max
Post by: Mads Barnkob on May 21, 2022, 12:49:51 PM
Tesla Player topic: https://highvoltageforum.net/index.php?topic=2034.0
Original post
Quote
Hi everyone,
We have been using the Synterrupter for the past months in our student club with our 3 Tesla Coils and I first want to thank you deeply for your amazing work !
I wanted to share a tool that I have been working on last month in order to help us during our Tesla Coil shows: a web Midi Player specificaly designed for operating the Synterrupter.
Indeed, we wanted to have a centralized platform to host our MIDI/configs and were not confident in embedding binary SYSEX commands directly in the files. Futhermore, most of the available MIDI players/editors were overly complicated for our usages (we just want to play MIDI/playlist smoothly and to perform automatic configuration of the Synterrupter for each song.) Finally, in order to have this setup work on any person device, we wanted to have as less setup required as possible.
So I came up with the idea of developping a web app tailor made for our specific MIDI/syntherrupter needs (we host an instance for our club behind an auth provider).
I detailed the features and embedded some screenshots in this public github repository: https://github.com/antoinercbs/tesla-synth-web-player
A release is obviously available on this github if you want to test it ;)
If some of you are interested in this tool, my goal is to make it as available as possible for the community ;) (I think it's the bare minimum given all the open-source ressources developped by the community we used...)
Tanks again for your amazing work !
Post by: AntoineRcbs on June 05, 2022, 08:27:07 PM
As promised, here are some videos of our tests with the syntherrupter. Due to the weather conditions, we unfortunatly could not push our coils to their maximum ratings.
We also do not use envelopes yet.
Best,
Antoine
Post by: Max on June 05, 2022, 10:08:43 PM
Nice show! I assume it was quite a success? I think my favorite is the James Bond theme because it‘s not just constant full power but a nice combination of small/low volume and bigger/louder arcs.
We also do not use envelopes yet.It would make quite a difference IMO. Especially in the Cantina Band video I think it would have helped.
Looking forward to seeing more! :D
Max
Post by: Max on September 18, 2022, 07:25:30 PM
Thanks @AstRii for making me aware of the issues and helping to resolve them as quickly as possible.
Kind regards,
Max
Post by: Max on April 04, 2023, 01:19:23 AM
Syntherrupters features have been growing over the years. However, the UI kinda got stuck at some point. New features like the stereo modes may be very powerful and interesting but have been hard to use to say the least. The possibility to configure pretty much anything from a computer by text commands (Syfoh (https://github.com/MMMZZZZ/Syfoh#readme)) has made my life much simpler, but it's not a replacement for a built-in, intuitive UI - after all this is an interrupter with touch screen. So I finally started on a partial redesign.
New MIDI Live Mode. Links to related settings are no longer hidden behind the coil buttons. Instead there are clearly labeled buttons.
Current Design (https://github.com/MMMZZZZ/Syntherrupter/blob/v4.2.2/Documentation/Wiki/UI/MIDI%20Live.md#what-you-see) for comparison.
[ Invalid Attachment ]
New page for assigning MIDI channels to coils. Instead of a separate page per coil, all channels and coils can be managed from a single page. Besides being faster, this hopefully makes it more intuitive in some scenarios (f.ex. "I want channel 3 to play on coils 3, 4 and 6).
Current Design (https://github.com/MMMZZZZ/Syntherrupter/blob/v4.2.2/Documentation/Wiki/UI/Coil%20Settings.md#what-you-see) for comparison.
[ Invalid Attachment ]
New page for managing channel stereo settings. There was simply no graphical UI for this before. You had to enter the MIDI commands either on screen or on your PC. I hope that the simplistic graphics at the bottom help to understand how the individual modes work. Unlike the new Channel Assignment page this one doesn't have the space for written explanations, so I hope this is intuitive enough.
Current Design (https://github.com/MMMZZZZ/Syntherrupter/blob/v4.2.2/Documentation/Wiki/UI/Channel%20Settings.md#what-you-see) for comparison.
[ Invalid Attachment ]
Next up is the stereo configuration of the coils. I'd have loved to see both coil and channel stereo configuration on the same page but I can't see how. That means that the user still doesn't see the "big picture". It will for sure be more intuitive than it is right now, but I'm not sure whether it's intuitive enough for people to actually use the feature(s).
As for the envelope editor, which is pretty bad as well, I don't think it's going to change anytime soon. The reason being that I can't think of a good way of doing it with the Nextion displays. The straight line and dot graphics used in the screenshot above are already a PITA. Curves would be another order of magnitude worse...
Let me know what you think!
Max
Post by: Georgios on January 10, 2024, 10:36:42 AM
I made 6 small Tesla coils to test how many midi notes the syntherrupter could play at the same time.
Unfortunately, I could not play more than 8 notes at the same time on version 4.1.0 (newer versions do not work on my computer). The program freezes and when I press the reset button the coil settings go away. I have to re-adjust the correspondence of the MIDI channel numbers to the Tesla coils. I manually edited the music so that the program would not be reset. How can I make the settings remain after pressing reset?
Post by: Max on January 10, 2024, 03:10:14 PM
There have been many bugfixes since v4.1.0. Although I couldn‘t find any hint in the release notes that adresses your particular problem, there are quite a few related issues that have been fixed in the meantime. Chances are high that the current version does not have the problem you‘re facing.
The MIDI settings, like which channels play on which coils, are indeed not stored in a way that survives a powercycle. However, current versions allow importing/exporting such settings from/to your PC (see here (https://highvoltageforum.net/index.php?topic=2034.0) and here (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Custom%20MIDI%20Commands.md#quick-start)).
With all of that in mind, I‘d focus on getting the current version working for your setup. You‘re sounding like you were running the UI on your PC? In that case make sure you‘re using the correct version of the Nextion Editor (it‘s not the same anymore as the one you‘re using for v4.1.0), see this guide (https://github.com/MMMZZZZ/Syntherrupter/blob/dev/Documentation/Wiki/Minimum%20Viable%20Setup.md#without-a-display).
Kind regards,
Max
Post by: Georgios on January 11, 2024, 04:50:59 PM
I downloaded version 2.2 of the program with the correct version of NEXTION and everything works as it should. No more program freezes. Thank you very much, you are a genius!
The Tesla coils that I use are actually very simple without microcircuits with a minimum number of parts. The height of the coil is 10 centimeters. Based on the Royer generator. If you need it, I can send you a diagram.
Respectfully
Georgios!
Post by: Max on January 13, 2024, 07:44:20 PM
Glad to hear that the issue was that easy to solve. I do have my own set of mini tesla coils with a very minimalistic circuit (capacitor, potentiometer, MOSFET for the tesla coil part, then another MOSFET and an optocoupler for the interrupter part IIRC). I posted a video with them some time ago in this topic. Included it below.
Nonetheless, I'd encourage you to make a separate forum topic about your setup! Having more ideas and cool projects out there is always a benefit in my eyes.
Kind regards,
Max
Post by: Max on January 19, 2024, 05:40:37 AM
A big part of the UI rework (https://highvoltageforum.net/index.php?topic=1020.msg17681#msg17681) is done. Nothing has been tested so far* and there're still some additional things I'd like to do before I start testing the new code. However, I figured some of you may want to try it anyway, so here's a new beta release: untested v4.3.0.-beta.1 (https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.3.0-beta.1)
My next step would be to get rid of the current Help system in the UI, which is very hard to adjust, relies on deprecated features, and still requires you to have a smartphone to open the wiki pages. I plan on replacing it with a complete on-screen help. No internet or smartphone required.
*UI and Tiva code both compile. UI seems to send the correct commands, but neither have I systematically checked all of them, nor have I tested them with the Tiva connected to it.
Kind regards,
Max
Post by: Max on January 20, 2024, 12:30:08 AM
Some of the issues have been fixed in the new beta release; simple mode seems to work f.ex., while other stuff is known broken (changing coil limits). The main point is still to be able to play with the UI.
Also, here's how the new on-screen help looks. The new release v4.3.0-beta.2 (https://github.com/MMMZZZZ/Syntherrupter/releases/) already includes it for the MIDI Live page.
Kind regards,
Max
Post by: Max on February 23, 2024, 06:20:27 PM
I also added an overview table to help you see which channels are associated with which coils. Using 'Show' the appropriate column or row is highlighted (see screenshots).
The new v4.3.0-beta.3 can be downloaded from the release page: https://github.com/MMMZZZZ/Syntherrupter/releases
Kind regards,
Max
Post by: Mads Barnkob on February 24, 2024, 07:25:48 PM
Post by: Max on February 29, 2024, 03:49:35 PM
It'll likely take me another 1-2 months til I get to fully test it and release a stable version. I did some rough checks though, basic stuff seems (!) to work by now.
Kind regards,
Max