Audio modulation questions, chords

[dru]

Hello. I've been working on audio modulation in my DRSSTC and I've run into an interesting challenge. My control circuit is only capable of outputting 1 bit music, so the best I've been able to do is play songs note by note. I don't know if I explained that right, what I'm trying to say is the control signal is either on or off, there is no in between state and I can only play one frequency at a time. I am curious if anyone has had any success in producing chords with this type of controller. I've tried playing notes in succession with little delay to achieve that smooth sound, but I still have the problem of the notes either being on or off so the chord sounds choppy. There are two things I'm aware of that may solve this problem, but I'm not sure about them. I could either 1. modify my driver and the secondary coil so that instead of producing notes by interruption, I inject the audio as a digital signal that rides the carrier waves of my main circuit or 2. I could try fiddling with the frequency and waveform of the driver input to produce varying amplitude waves, and check my work with a fast Fourier transform. I'm sure there are documented waveforms for chords already somewhere out there, I will have to figure out how to play those through the Arduino though. I know I could also send it through optical cables directly from my computer, I worry about proper isolation though.

[dru]

with a fast Fourier transform.

It also could be easier to do an inverse fft and use that waveform

[Max]

Hi dru,


Polyphony for interrupters / DRSSTC controllers used to be a hard problem but many more recent interrupter projects have shown that it's basically solved.
To take the example of my own Syntherrupter, here's one recording of what it can do. It's a direct capture interrupter signal that it generated in real time and which could be fed straight into a DRSSTC driver: https://soundcloud.com/user-754038701/pirates-of-the-carribean-jarrod-radnich-syntherrupter-v420-beta4

The problem is not too hard to solve in theory but in reality - especially for tesla coils - there are quite a few pitfalls. Here's a hopefully logical sequence from simple to advanced on how to do polyphony.

• The most straightforward form of polyphony is to have one tesla coil (incl. interrupter) for each note you want to play. Feed each interrupter with a different note and you ears will hear both of them together. Or, to be more precise, you'd hear the sum of all the pulses from each coil.
• Next logical step: add those pulses together before sending them to the tesla coil(s). Or'ing together the digital interrupter signals leads to the exact same result, with the advantage that it can be fed into a single tesla coil. This works very well for low numbers of simultaneous notes and is the technique used by many "established" interrupters (loneoceans and one teslas 2-voice interrupter, uzzor2k's 2-4 voice interrupter, probably others). ***
• The issue is that these still require one hardware timer for each note, which is why they're often limited to 2 (since the Arduino microcontroller they use only offers 2 timers). Also, or'ing isn't actually perfect. Ontimes can overlap, resulting in longer-than-desired ontimes. Maybe even worse: there can be a very small gap between two ontimes that would cause the common UD1.x and UD2.x drivers to hard switch once.
• These issues can be solved by moving from hardware-or'ing to doing it in software. Here you have full control. Apply limits, remove undesired conditions, ... Of course, software "vs" hardware is not black and white and all the interrupters linked above use a different mix of various soft- and hardware features. Software based polyphony comes with its own pitfalls; it took me well over a year till I had "solved" the issue (I consider >100 notes on a 120MHz microcontroller as "solved").

*** Or'ing them together only works because the ontimes are so short, like microseconds ontime with milliseconds offtimes inbetween. If you had a 50/50 square wave, or'ing 2 or more signals together would just lead to an almost steady state on signal with a few short off pulses here and there. This is also the reason why more than ~16 notes don't make sense for this sort of application. Let's say you can go up to 32% total duty cycle (which is rather high for a DRSSTC; most can go up to ~20%). With 16 notes each note has on average a duty cycle of only 2% - not much!

----

All of this obviously concerns synthesizing music, a.k.a. playing MIDI files. If you want to play "normal" analog music on your DRSSTC, stuff gets much more difficult; this problem has certainly not been "solved" yet. Existing approaches basically use a zero cross detector (comparator) on the audio signal to trigger interrupter pulses. This works for rather basic audio signals but don't expect it to generate something useful out of a normal song from youtube or whatever.
FFT could in theory work but it's pretty hard to do. First of all, there's usually much more in a song than just <16 clean notes. There are drums and other effects and instruments (as well as voices) are miles away from being clean sine waves (otherwise you wouldn't be able to distinguish instruments playing the same note). There are a lot of harmonics that not only vary from instrument to instrument but also per instrument over time. Our ears can make sense of this mess, but to an FFT it's just that: a mess. How do you distinguish strong harmonics of one instrument from actual notes with the same frequency of another, less loud instrument?
What you're basically asking is to convert an analog audio file to a MIDI-like digital format, with specific notes and - best case - sorted by instrument. Such analog-to-midi tools do exist, though they usually cost quite a bit and/or are far from being perfect. I've searched a bit (really not too much) for research papers - or basically any open knowledge - on the topic, too, but so far without success.


Kind regards,
Max

[davekni]

Max:  Great explanation!  Thank you for posting it.

Let's say you can go up to 32% total duty cycle (which is rather high for a DRSSTC; most can go up to ~20%). With 16 notes each note has on average a duty cycle of only 2% - not much!

Yes, MIDI music playing depends on DRSSTC coil properties as well as the algorithm.  My DRSSTC is rather low impedance (both primary and secondary).  Reaches my available line power limit of 10kW at 5-6% duty cycle.  Arc length (and sound volume) aren't linear with pulse width.  I'm fairly certain that higher impedance coils are much better for MIDI sound, handling longer on-times and higher duty cycle .  My coil sounds too distorted if playing more than 3 or 4 notes at a time.  (This is with my own algorithm to handle pulse overlap and short gaps, tailored for my coil behavior.  Of course, there may be better algorithms than my creation.)

I've searched a bit (really not too much) for research papers - or basically any open knowledge - on the topic, too, but so far without success.

Wouldn't expect to find much today, as I can't think of any practical use beyond DRSSTC interrupting.  However, I recall Bell Labs doing some experiments in the 1960s or early 1970s on digitizing audio with 1 bit.  Not sure if that work could be found on the internet today.  I haven't tried searching.

[Max]

This is with my own algorithm to handle pulse overlap and short gaps, tailored for my coil behavior.

I'd be very interested in hearing more about your approach and the tweaks you've made! Though a separate thread might be more suitable(?)

Wouldn't expect to find much today, as I can't think of any practical use beyond DRSSTC interrupting.  However, I recall Bell Labs doing some experiments in the 1960s or early 1970s on digitizing audio with 1 bit.  Not sure if that work could be found on the internet today.  I haven't tried searching.

Actually not that irrelevant. Especially the (most important) intermediate step of isolating individual instruments / voices from one recording is still a desirable feature for modifying live recordings afterwards. Certain DAWs do offer such features but that's not useful for the vast majority of our community. I also found one paper who apparently attacked the problem successfully with AI; but they only shared a compiled library with little documentation if I remember correctly.


Kind regards,
Max

[dru]

Hi dru,


Polyphony for interrupters / DRSSTC controllers used to be a hard problem but many more recent interrupter projects have shown that it's basically solved.
To take the example of my own Syntherrupter, here's one recording of what it can do. It's a direct capture interrupter signal that it generated in real time and which could be fed straight into a DRSSTC driver: https://soundcloud.com/user-754038701/pirates-of-the-carribean-jarrod-radnich-syntherrupter-v420-beta4

The problem is not too hard to solve in theory but in reality - especially for tesla coils - there are quite a few pitfalls. Here's a hopefully logical sequence from simple to advanced on how to do polyphony.

• The most straightforward form of polyphony is to have one tesla coil (incl. interrupter) for each note you want to play. Feed each interrupter with a different note and you ears will hear both of them together. Or, to be more precise, you'd hear the sum of all the pulses from each coil.
• Next logical step: add those pulses together before sending them to the tesla coil(s). Or'ing together the digital interrupter signals leads to the exact same result, with the advantage that it can be fed into a single tesla coil. This works very well for low numbers of simultaneous notes and is the technique used by many "established" interrupters (loneoceans and one teslas 2-voice interrupter, uzzor2k's 2-4 voice interrupter, probably others). ***
• The issue is that these still require one hardware timer for each note, which is why they're often limited to 2 (since the Arduino microcontroller they use only offers 2 timers). Also, or'ing isn't actually perfect. Ontimes can overlap, resulting in longer-than-desired ontimes. Maybe even worse: there can be a very small gap between two ontimes that would cause the common UD1.x and UD2.x drivers to hard switch once.
• These issues can be solved by moving from hardware-or'ing to doing it in software. Here you have full control. Apply limits, remove undesired conditions, ... Of course, software "vs" hardware is not black and white and all the interrupters linked above use a different mix of various soft- and hardware features. Software based polyphony comes with its own pitfalls; it took me well over a year till I had "solved" the issue (I consider >100 notes on a 120MHz microcontroller as "solved").

*** Or'ing them together only works because the ontimes are so short, like microseconds ontime with milliseconds offtimes inbetween. If you had a 50/50 square wave, or'ing 2 or more signals together would just lead to an almost steady state on signal with a few short off pulses here and there. This is also the reason why more than ~16 notes don't make sense for this sort of application. Let's say you can go up to 32% total duty cycle (which is rather high for a DRSSTC; most can go up to ~20%). With 16 notes each note has on average a duty cycle of only 2% - not much!

----

All of this obviously concerns synthesizing music, a.k.a. playing MIDI files. If you want to play "normal" analog music on your DRSSTC, stuff gets much more difficult; this problem has certainly not been "solved" yet. Existing approaches basically use a zero cross detector (comparator) on the audio signal to trigger interrupter pulses. This works for rather basic audio signals but don't expect it to generate something useful out of a normal song from youtube or whatever.
FFT could in theory work but it's pretty hard to do. First of all, there's usually much more in a song than just <16 clean notes. There are drums and other effects and instruments (as well as voices) are miles away from being clean sine waves (otherwise you wouldn't be able to distinguish instruments playing the same note). There are a lot of harmonics that not only vary from instrument to instrument but also per instrument over time. Our ears can make sense of this mess, but to an FFT it's just that: a mess. How do you distinguish strong harmonics of one instrument from actual notes with the same frequency of another, less loud instrument?
What you're basically asking is to convert an analog audio file to a MIDI-like digital format, with specific notes and - best case - sorted by instrument. Such analog-to-midi tools do exist, though they usually cost quite a bit and/or are far from being perfect. I've searched a bit (really not too much) for research papers - or basically any open knowledge - on the topic, too, but so far without success.


Kind regards,
Max

Hi Max, thanks for the reply! I had thought of combining the signals but wasn't sure it would work, it is nice to see a working example though, very cool. I made some progress on this issue yesterday with the fft approach, but the midi files I was generating had a lot of unnecessary harmonics like you mentioned. I used an MIT python package called audio_to_midi and it was capable of making the conversion, not as cleanly as I was hoping though. I think distinguishing between harmonics may require some sort of low pass filter built into the program, or a function that differentiates the fft and picks out only the first peak and writes that to a midi file. I may reach out to the creator of the package, I can't remember their name right now, to see what they have used it for and if they have any tips. My idea was to physically play a song on my keyboard and have it hardwired to my computer, but I don't have a midi cable so I had to use GarageBand which meant I had to deal with the .band files. I converted them to .wav and used the ATM, and I thought since its just the pure notes it would be a perfect inversion, but I still had some problems which may have been due to some fancy sound processing software in GarageBand that makes the notes sound better audibly but makes them much worse looking digitally. So to add the signals together, what's the best method of doing that? Is it as simple as putting them on top of each other, or is there a better way? The signals I feed my interruptor are kind of messy waveforms, they're square wave but also ramped. And it wouldn't be good for the amplitudes to sum because I don't want to overload the enable pin on my driver. If the waves were equal amplitude, could I sum them then just divide by 2 to get an intermediate signal? It's too bad my computer doesn't run on qubits haha this issue would be exponentially easier.

[Max]

Hi dru,


That MIT Python package you found is likely the one I found, too. Though I didn't try it.
Low pass filter doesn't work because harmonics start at twice the fundamental frequency, in musical terms at +1 octave. So you'd have at most ~half of an octave of range (6 consecutive notes) if you wanted to filter out all harmonics. That's simply not feasible. I'd say at least 2 octaves are required for meaningful music, rather 3, 4 (a full size piano has 7, but a tesla coil can't cover such a large range very well - especially with polyphony).
Filtering for the strongest may not work either because it's not guaranteed that the fundamental frequency is the strongest one. And, again, this changes over time. Especially during the attack (when you hit a note) there are a lot of harmonics. You can see this in the spectrum; hitting a new note tends to leave a vertical line, meaning it goes more or less across the entire spectrum. At least for a piano the harmonic content diminishes relative to the fundamental, meaning that the tone becomes more and more pure over time. if you would strictly go by the strongest it would likely jump around before landing at the fundamental.

That aside, if you intend to play music from a keyboard, then for the love of God, feed its MIDI data directly into your interrupter. There is zero benefit in converting it to analog to then try to convert it back to what it was already before. I assume you're connecting your keyboard via USB. If so then it still identifies itself as MIDI device and you can directly take that MIDI data for your interrupter.
On Windows you'd use "hairless MIDI serial bridge" to send the MIDI data to the serial port of your microcontroller. Additionally, you might need/want "loopMIDI", which allows the creation of virtual MIDI devices that "connect" f.ex. hairless MIDI serial bridge to GarageBand (or similar software).

Don't get me wrong, I fully support your adventures in trying to get an FFT based approach working. I'd love to see progress on that side even though chances are slim. My main point is that you already got the absolutely perfect digital representation of what you want (MIDI data coming from the keyboard). No conversion can improve this, especially not such a complex and - atm - flawed one as the FFT. Take that MIDI data and generate your interrupter signal based on that or use one of the existing interrupters with good MIDI support.


Kind regards,
Max

[davekni]

Quote from: davekni on October 04, 2022, 04:49:55 AM

    This is with my own algorithm to handle pulse overlap and short gaps, tailored for my coil behavior.

I'd be very interested in hearing more about your approach and the tweaks you've made! Though a separate thread might be more suitable(?)

This thread seems reasonable, and already has your clear explanation.  However, I'd be happy to start another thread if that is more appropriate.

I have two different implementations.  One is off-line processing of MIDI files by a C program.  Interrupter pulse sequence/timing is recorded as pulses to an MP3 player.  During coil operation, a simple schmitt-trigger circuit converts MP3 output to fiber light pulses.  Being off-line, the program can be (and is) multi-pass.

The other implementation is for live keyboard music.  It is simpler, implemented in an FPGA (verilog code), no microprocessor involved.  Plays up to 4 simultaneous notes.  Within the 64-note implemented range, plays the highest 4 notes if more than 4 are active.  Instant attack and exponential decay to half volume while key is pressed, instant end on key release.

First question to answer is how sound pressure relates to pulse width.  Requires some minimum pulse width to make any arc.  For pulses a little longer than minimum, I think sound is roughly proportional to square of pulse width, at least for my coil.  Primary current is ramping close to linearly with time, so energy is ramping as time^2.  For higher-impedance coils, this square function should taper to linear as primary current plateaus.  For my relatively-short pulses, I just presume the square relationship continues.  So, pulse width is proportional to sqrt(volume + offset), where offset determines minimum pulse width.  Ignoring the plateau means that high-volume (long pulses) aren't as long as they "should be".  Since overly-long pulses need to be avoided anyway, this seems like a reasonable error to have, perhaps even desirable.  (Not just an IGBT thermal limit of my coil.  Especially for my low-impedance coil, long pulses get out-of-tune, energy transfer decreases, so primary current ramps to OCD limit without adding much useful arc energy.)

Of course, the above square approximation is very simplistic.  Arc behavior changes drastically with ground strikes, and with history (previously ionized air paths).  I usually run my coil with top-center breakout and 4+ ground poles ~2m away in each direction.  Makes for many ground strikes, brighter arcs in random directions, but less predictable sound output.  I've thought about possible experiments to measure sound vs. pulse width, frequency, etc.  Even if ground strikes are avoided, measurements aren't simple.  Since I don't have an open field available, echos from nearby structures would make measuring anything beyond isolated single pulses nearly impossible to measure correctly.

My multi-pass algorithm goes roughly like this:
     Interpret MIDI commands.
     Rearrange any very-close note on and off commands to put off before on.  Minimizes simultaneous note events.
     "Play" notes.  Converts notes to a single array of time and amplitude pairs (impulses), one pair for every cycle of every note.
     Combine impulses that are close together.  Amplitudes add.  New time is weighted sum of original times.
     Spread out impulses to meet minimum spacing.  This is an iterative algorithm, adjusting timing of each too-close pair of impulses.
     Convert impulses to pulse widths (above sqrt/offset function).
     Pulses are positive.  Add equal-length negative pulse after each positive pulse to make average DC level zero.
     Low-pass filter with sinc function.  Sample at 44.1kHz to wave file.  Convert wave to MP3.  Record on player.
     Report average duty cycle and other statistics.
For this off-line code, I manually change input parameters and rerun if duty cycle is too high (or low).

FPGA algorithm is simpler.  Keeps 64 running accumulators (frequency generators) and 64 volume values, one pair for each allowed note.  Four highest active notes are processed.  For each accumulator wrap, a pulse is started proportional to volume.  If a pulse is already active, then it's time is extended by half of the new notes volume value.  (Crude way to get sqrt approximation.)  Gap timer starts at end of each pulse.  Any new pulse start is delayed until gap expires.  Running average duty cycle is calculated.  Pulse timer decrements by larger steps at higher duty cycles, which in turn reduces duty cycle (reduces pulse widths).

Not sure if the above is of any use, or too cryptic, or ...  If it is of any interest, feel free to ask questions.  If by any outside chance source code would be useful, I could post that.  (At least the C code that has somewhat-reasonable comments.  Verilog code is rather cryptic - just a few pages of compact code with minimal comments.)

[Max]

Hi davekni,


Thanks for the details! Your off-line processing is similar to what my Syntherrupter code does in real-time (with 5ms buffering). So it is for sure possible to do more or less the same in (almost) real-time, in case that's interesting to you.

You mentioned exponential decay with your FPGA based approach, are you using envelopes with your C code, too?

     Rearrange any very-close note on and off commands to put off before on.  Minimizes simultaneous note events.

Not sure I understand it correctly, is this to minimize spikes in the number of active notes if new notes start playing before existing ones end? If so, is it actually providing a real benefit...? Even if, as soon as you add envelopes that have a finite release time, this doesn't work/help anymore (?)

     Combine impulses that are close together.  Amplitudes add.  New time is weighted sum of original times.
     Spread out impulses to meet minimum spacing.  This is an iterative algorithm, adjusting timing of each too-close pair of impulses.

These are the most critical steps when it comes to audio quality in my experience. Introducing a minimum offtime between ontimes has a huge impact on audio quality and should be minimized as far as possible.
I am a bit confused about how you decide what pulses should be added together and/or spaced out if you haven't converted them to on-/offtimes yet. More specifically, I think that the latter would allow more precise control, reducing modifications to the minimum possible and thus give the better audio quality. Long before I used buffering I had "smarter" control for merging/moving/... ontimes, too, but found that simple approaches actually work better. With buffering it got a bit smarter but still not too fancy. An ontime too close to the previous one gets added to that one. (Resulting) Ontimes that are too long get chopped off at the end. While I agree that in theory keeping the ontimes centered (instead of left aligned) when changing their length should improve audio quality, I'm not sure it actually does.

I've thought about possible experiments to measure sound vs. pulse width, frequency, etc.  Even if ground strikes are avoided, measurements aren't simple.  Since I don't have an open field available, echos from nearby structures would make measuring anything beyond isolated single pulses nearly impossible to measure correctly.

That would be highly valuable data IMO and worth collecting even with echoes. If you're interested in the full spectrum response then yes, echo probably ruins it. But if it's only about the overall volume, I would think that the echoes don't hurt too much. Underlying relations like the assumed square relation should still be visible enough to know in what direction compensation needs to go.


Kind regards,
Max

[davekni]

You mentioned exponential decay with your FPGA based approach, are you using envelopes with your C code, too?

Yes, though still a simple hard-coded envelope.  Lots of possible improvements and extensions.  Not necessarily worthwhile unless I make a new coil with more conventional impedances that is better for MIDI playback.

Not sure I understand it correctly, is this to minimize spikes in the number of active notes if new notes start playing before existing ones end? If so, is it actually providing a real benefit...? Even if, as soon as you add envelopes that have a finite release time, this doesn't work/help anymore (?)

This is more specific to my coil and limitations and algorithm.  Forgot to mention that my C code also limits number of simultaneous notes, playing the highest frequency ones.  This rearrangement is to avoid unnecessarily blocking notes due to exceeding simultaneous limit parameter.  Rearrangement is not likely useful in a more general case.

Introducing a minimum offtime between ontimes has a huge impact on audio quality and should be minimized as far as possible.

Yes, completely agree!  I can probably push my coil more, but hesitate to risk IGBTs.  (In my case, controller can handle any length gap.  Startup is always synchronous to any remaining primary current.  My issue is very-limited thermal capability of IGBT internal diodes.  Frequent enable turn-off events may trigger diode thermal runaway.  10 parallel IGBTs/diodes for each switch.  Diodes have large negative Tc, so won't share current well for very long.)

I am a bit confused about how you decide what pulses should be added together and/or spaced out if you haven't converted them to on-/offtimes yet. More specifically, I think that the latter would allow more precise control, reducing modifications to the minimum possible and thus give the better audio quality.

Again probably specific to my coil, with its low average duty cycle limit.  Reduces the advantage of converting to time first.  The advantage of later conversion to times is that it makes implementing non-linear transfer functions easier.  No need to convert a pulse width back to amplitude, add a second amplitude, then convert back to pulse width.  (No need to implement a reverse of the non-linear transfer function.)  Had planned to do more testing and refinement of the non-linear conversion function at some future date.

While I agree that in theory keeping the ontimes centered (instead of left aligned) when changing their length should improve audio quality, I'm not sure it actually does.

Interesting and helpful to know.  This is how my FPGA version works.  Nice to know I'm not losing much.

That would be highly valuable data IMO and worth collecting even with echoes. If you're interested in the full spectrum response then yes, echo probably ruins it. But if it's only about the overall volume, I would think that the echoes don't hurt too much. Underlying relations like the assumed square relation should still be visible enough to know in what direction compensation needs to go.

Good point.  If I measure one note at a time over varying pulse widths, echos wouldn't be too problematic.  Perhaps could even measure notes made of pairs of pulses with varying gap time and still get useful data.  (Now I have one more project back on my over-sized list of ideas to build and experiment with some day.)

Thank you for all your contributions!

[dru]

Hi dru,


That MIT Python package you found is likely the one I found, too. Though I didn't try it.
Low pass filter doesn't work because harmonics start at twice the fundamental frequency, in musical terms at +1 octave. So you'd have at most ~half of an octave of range (6 consecutive notes) if you wanted to filter out all harmonics. That's simply not feasible. I'd say at least 2 octaves are required for meaningful music, rather 3, 4 (a full size piano has 7, but a tesla coil can't cover such a large range very well - especially with polyphony).
Filtering for the strongest may not work either because it's not guaranteed that the fundamental frequency is the strongest one. And, again, this changes over time. Especially during the attack (when you hit a note) there are a lot of harmonics. You can see this in the spectrum; hitting a new note tends to leave a vertical line, meaning it goes more or less across the entire spectrum. At least for a piano the harmonic content diminishes relative to the fundamental, meaning that the tone becomes more and more pure over time. if you would strictly go by the strongest it would likely jump around before landing at the fundamental.

That aside, if you intend to play music from a keyboard, then for the love of God, feed its MIDI data directly into your interrupter. There is zero benefit in converting it to analog to then try to convert it back to what it was already before. I assume you're connecting your keyboard via USB. If so then it still identifies itself as MIDI device and you can directly take that MIDI data for your interrupter.
On Windows you'd use "hairless MIDI serial bridge" to send the MIDI data to the serial port of your microcontroller. Additionally, you might need/want "loopMIDI", which allows the creation of virtual MIDI devices that "connect" f.ex. hairless MIDI serial bridge to GarageBand (or similar software).

Don't get me wrong, I fully support your adventures in trying to get an FFT based approach working. I'd love to see progress on that side even though chances are slim. My main point is that you already got the absolutely perfect digital representation of what you want (MIDI data coming from the keyboard). No conversion can improve this, especially not such a complex and - atm - flawed one as the FFT. Take that MIDI data and generate your interrupter signal based on that or use one of the existing interrupters with good MIDI support.


Kind regards,
Max

Hi Max,
I notice I tend to think of more complicated solutions before the simpler ones, and I think that was the case here. I was kind of set on finding a way to convert any music into a very specific string-type of the form (NOTE_##,NOTE_##...) because that is what the program I was running accepted. It turns out I did not need an Arduino at all for this, I think my solution may be similar to what you mentioned but I'm not sure. I have some errands to run right now, so I will come back and read through and post a more detailed reply later. In a short summary, I took the midi files on my computer and ran them through a different program that converted them into .wav files with square waveforms. I then sent this out from my computer through a regular headphone jack, into an RCA splitter and attached those to an audio transformer I had for isolation (I think with turns ratio of about 1:1.5), and attached the transformers outputs to the enable pin of my gate driver and the control circuit common ground. I wasn't sure it would work because the waveforms looked kind of wild on my oscilloscope, but when I fired up the coil it worked perfectly and I was able to play 16 bit audio with a pretty wide range (guessing c2-c7). I may be wrong about some of the details, I will give a better description later. The driver is connected to my 'test circuit', which I've actually decided to use instead of my main coil right now because it is tuned very well. Here is the schematic, I tried to make it clear and readable but to me that means lots of color coding and I know that can be confusing for some. I can give more data about coil too later.
edit: The schematic should say capable of 16bit audio, and the decibel level is >100db not 7100db (impossible ofc)

[davekni]

I wasn't sure it would work because the waveforms looked kind of wild on my oscilloscope, but when I fired up the coil it worked perfectly and I was able to play 16 bit audio with a pretty wide range (guessing c2-c7).

Can't argue with success!  Congratulations!  Looks like a simple conversion too.

In a short summary, I took the midi files on my computer and ran them through a different program that converted them into .wav files with square waveforms.

What program did you use for MIDI to WAV conversion?  Would love to figure out more about what that program does.  (Adding lower-volume square waves perhaps, or somehow mixing the notes into a single constant-amplitude "square" wave binary stream?)

Here is the schematic, I tried to make it clear and readable but to me that means lots of color coding and I know that can be confusing for some. I can give more data about coil too later.

Looks understandable.  I'm presuming AGND and PGND are the same node as the FET source.

[dru]

What program did you use for MIDI to WAV conversion?  Would love to figure out more about what that program does.  (Adding lower-volume square waves perhaps, or somehow mixing the notes into a single constant-amplitude "square" wave binary stream?)

Looks understandable.  I'm presuming AGND and PGND are the same node as the FET source.
[/quote]
Hi Dave,
To convert the .mid files into usable square wave .wav files I used the synthrs-master library. The program is written in rust. I working through the source code right now so I don't fully understand yet its mechanism, and I also am not familiar with rust (it looks similar to c++). A vague summary of what I've taken in is that it takes (1 second?) samples of the midi file and writes the notes as normalized vectors with max min amplitude 1,-1. 
//for _ in 0..song.max_time {
        let notes_on_for_tick: Vec<TickNote> = Vec::new();
        notes_on_for_ticks.push(notes_on_for_tick);
}
This is a snippet of the code, I think this is the function that allows for multiple notes per sample. I'm pretty sure it uses a low pass filter. I'm not confident enough to say any more about it except that it produced a semi decent square wave file. I recently made some progress within the last couple hours and my coil can accept complex waveforms, so I'm not using this converter anymore. I have actually managed to get my coil to speak and play vocals now, and although they are a little distorted the words are clear and audible. I haven't looked around yet so I'm not sure if this is a common achievement or something new. I remember watching a Steve Ward video a while ago where he was trying to send speech through his coil, I can't recall if it worked. I highly doubt I'm the first person to do this though.

[davekni]

To convert the .mid files into usable square wave .wav files I used the synthrs-master library. The program is written in rust. I working through the source code right now so I don't fully understand yet its mechanism, and I also am not familiar with rust (it looks similar to c++).

Thank you for the program reference.  I'm not familiar with rust and only a little with C++.  Had been thinking of processing a couple simple MIDI files and examining the resulting waveforms.  However, I don't see any way to execute its "midi-to-wave" function easily from my Windows PC.

I have actually managed to get my coil to speak and play vocals now, and although they are a little distorted the words are clear and audible. I haven't looked around yet so I'm not sure if this is a common achievement or something new. I remember watching a Steve Ward video a while ago where he was trying to send speech through his coil, I can't recall if it worked. I highly doubt I'm the first person to do this though.

Probably not completely unique, but I haven't ran into anything quite like yours.  Other coils are either digitally interrupted and play MIDI music or are analog modulated and play any audio source (ie. plasma speaker).  Yours is the first case I've seen of playing general audio through a single binary bit (enable pin of UCC37321 gate driver chip).

I'd guess that a key factor in your success is having a coil that can be enabled and disabled frequently.  If a coil can be enabled and disabled sufficiently rapidly, one could play sigma-delta modulated audio.  Sigma-delta modulation is used inside almost every commercial audio DAC and ADC chip.  Would be close to the conventional analog modulation.  (One future project on my too-long list is to make a sigma-delta modulated full-bridge SSTC to demonstrate as a plasma speaker. )

Interesting project!

[Max]

Hi dru,


There are quite a few terms and ideas flying around here that make me wonder if you're not confusing some things - at least I can't quite follow what is meant. Like that you wrote next to your 1 bit enable pin it was 16 bit capable?
Another such point from your schematic: You're writing you're pretty sure it's a dual resonant coil because you thoroughly calculated and constructed your coil. While that's respectable and very beneficial for good results, I'm afraid, but that's not what differentiates an SSTC from a DRSSTC. Dual resonant means that you have a capacitor in series with your primary coil, and that these two form another resonant circuit in addition to your secondary side resonant circuit. All tesla coils have one resonant secondary side circuit that requires careful tuning to work well. DRSSTCs have an additional primary resonant circuit, and SSTCs don't. That doesn't make one better than the other one, just different. And in your case it's good that it's not dual resonant because I'm rather sure it wouldn't have survived if it was. There's a whole lot more to say on DRSSTCs, pros, cons, ... but that's already been explained in many other forum posts and websites; it wouldn't fit here.

The idea of feeding audio directly into the enable pin isn't an entirely new concept, though I haven't heard of it working as well as you describe. However, there are quite a few issues with the specific way you're doing it.
First of all, you're feeding an AC analog signal (from the audio transformer) into a digital pin (enable pin of the UCC). How does that chip like negative voltages of unknown amplitude in its digital circuit? You really should add some sort of rectification; either half or full wave. Even if they weren't damaging the chip, negative voltages shouldn't do anything anyways (they're all a logic zero).
Secondly, add some sort of overvoltage protection. You don't know exactly what amplitude your unloaded transformer is producing.
Next, and this leads us towards more conventional approaches, you may want to adjust when and how your analog signal is considered as logic one or zero. Therefore you could use a comparator. A concept (!) circuit for this is attached.
Finally, none of this gives you any control whatsoever about the signal you're generating. You have no idea about the duty cycle (probably around 50% but who knows?), the ontime, the offtimes between ontimes, etc. If you have an "arbitrary capable" coil, that's no issue, but usually, coils that are driven by an interrupter are not arbitrary capable (at the very least not capable of 100% duty / CW operation, hence the need for an interrupter). In particular, a DRSSTC (excluding very few special builds) is not capable of handling this sort of signal (more than 10-30% duty cycle likely results in catastrophic failure, to name one of multiple restraints).

Another point where I am confused is what you're actually targetting here. At some point you wrote you wanted to play music from a (MIDI) keyboard or some other MIDI source. But then you're talking about speech being recognizable, which clearly means non-MIDI, analog audio source.
It would - at least for me - be quite helpful if you could clarify a bit on the exact use case. What audio source(s) do you use (MP3 files, MIDI files, keyboard, microphone, ...)? What does your coil need (arbitrary or not, limits, ...)? What else is important to you?

I already linked you the list of other musical interrupter projects, but I wanted to point out one in particular:
https://highvoltageforum.net/index.php?topic=1251.0
Look at the code in the first post. Only 80 lines, no complex FFT, and it does polyphony. It certainly lacks a couple features but man, it's <100 lines. That's to show you how easy it is to not use analog audio but go straight from MIDI to the interrupter signal.


Kind regards,
Max

[davekni]

And in your case it's good that it's not dual resonant because I'm rather sure it wouldn't have survived if it was.

I wonder if class-E driven coils could be called 1.5 resonant   There is a primary resonant circuit consisting of primary coil and drain-source capacitance (both internal and external added capacitor).  It is resonant only for the part of each cycle when FET is in off state.  Primary resonant frequency does matter, though it can track frequency changes better than normal DRSSTC because FET on-state time can vary.

Secondly, add some sort of overvoltage protection. You don't know exactly what amplitude your unloaded transformer is producing.

Yes, over-voltage protection would be good on both enable pin and feedback input pin.  I've been surprised the UCC37321 has survived so far, especially from the negative feedback current.  On the other hand, it is a simple circuit and working.  UCC37321 must have reasonably robust input protecting internally.

[dru]

Hi dru,


There are quite a few terms and ideas flying around here that make me wonder if you're not confusing some things - at least I can't quite follow what is meant. Like that you wrote next to your 1 bit enable pin it was 16 bit capable?

Hi Max,
I am just starting out with audio, so there is a good chance I misused some terms. What I meant by the 16 bit capable part was that the enable pin on the UCC37322 'accepts' a 16 bit .wav file, and that the coil then produces a pseudo 16-bit full range audio. The enable pin is being driven very quickly (with square waves mostly, I only tried the voice audio files a few times) and the result is a blending of notes that is indistinguishable to my ear from 16-bit audio.

Another such point from your schematic: You're writing you're pretty sure it's a dual resonant coil because you thoroughly calculated and constructed your coil. While that's respectable and very beneficial for good results, I'm afraid, but that's not what differentiates an SSTC from a DRSSTC. Dual resonant means that you have a capacitor in series with your primary coil, and that these two form another resonant circuit in addition to your secondary side resonant circuit. All tesla coils have one resonant secondary side circuit that requires careful tuning to work well. DRSSTCs have an additional primary resonant circuit, and SSTCs don't. That doesn't make one better than the other one, just different. And in your case it's good that it's not dual resonant because I'm rather sure it wouldn't have survived if it was. There's a whole lot more to say on DRSSTCs, pros, cons, ... but that's already been explained in many other forum posts and websites; it wouldn't fit here.

This is true, I think I was confused about the location of the resonant capacitor. I have made a QCWDRSSTC before and the capacitor was in series like you said, this capacitor is in parallel with the primary though so it is not dual resonant. When I was putting the circuit together I was planning on using it just for testing my interruptor, so I didn't make it dual resonant. The correct classification here would be a class-E SSTC interrupted. I will have to restructure the circuit and add some protection circuitry if I want it to operate at dual resonance.

The idea of feeding audio directly into the enable pin isn't an entirely new concept, though I haven't heard of it working as well as you describe. However, there are quite a few issues with the specific way you're doing it.
First of all, you're feeding an AC analog signal (from the audio transformer) into a digital pin (enable pin of the UCC). How does that chip like negative voltages of unknown amplitude in its digital circuit? You really should add some sort of rectification; either half or full wave. Even if they weren't damaging the chip, negative voltages shouldn't do anything anyways (they're all a logic zero).
Secondly, add some sort of overvoltage protection. You don't know exactly what amplitude your unloaded transformer is producing.
Next, and this leads us towards more conventional approaches, you may want to adjust when and how your analog signal is considered as logic one or zero. Therefore you could use a comparator. A concept (!) circuit for this is attached.
Finally, none of this gives you any control whatsoever about the signal you're generating. You have no idea about the duty cycle (probably around 50% but who knows?), the ontime, the offtimes between ontimes, etc. If you have an "arbitrary capable" coil, that's no issue, but usually, coils that are driven by an interrupter are not arbitrary capable (at the very least not capable of 100% duty / CW operation, hence the need for an interrupter). In particular, a DRSSTC (excluding very few special builds) is not capable of handling this sort of signal (more than 10-30% duty cycle likely results in catastrophic failure, to name one of multiple restraints).

Another point where I am confused is what you're actually targetting here. At some point you wrote you wanted to play music from a (MIDI) keyboard or some other MIDI source. But then you're talking about speech being recognizable, which clearly means non-MIDI, analog audio source.
It would - at least for me - be quite helpful if you could clarify a bit on the exact use case. What audio source(s) do you use (MP3 files, MIDI files, keyboard, microphone, ...)? What does your coil need (arbitrary or not, limits, ...)? What else is important to you?

The enable pin on the UCC can be driven from -.3V to 5v. I measured the amplitude of the transformers output on my oscilloscope and the amplitude was +/-5v. I think it is surviving because it is only staying below -.3V for a short time, though I'm sure I'm endangering it with the negative peaks. It's possible that I got lucky with grounding, the primary circuit is grounded to ac neutral, not earth so this may have created an offset in favor of a lower enable voltage but this is a stretch.
The duty cycle should be 50% as the enable pin is only pulled high during the positive sine wave.
I'm targeting audio modulation, which has evolved from basic single bit audio interruption to methods of producing polyphonic music through interruption. I am going to work on the coil today, so I will post some scope views and videos of operation. If you think this topic should be moved to the sstc forum we could do that, I do plan on making this coil dual resonant though.
-Sean

[dru]

Here is a short video of the coil running a 40vac, with the enable pin being driven solely by a song on apple music, I have no clue what waveform it is. Obviously the audio is very poor quality, my ears are still ringing from all the static. You can make out words and multiple chords being played simultaneously. The duty cycle is somewhere below 100% haha I’m not sure. The mosfet did not heat up at all. I also attached a picture of the physical circuit, which is much uglier than my drawing. Still using all the same components, so this circuit is at least durable. After typing this I see the max file size is 5mb, I am not sure how to make a video that small I will work on it, even just a 5 second clip is 100mb.

[davekni]

After typing this I see the max file size is 5mb, I am not sure how to make a video that small I will work on it, even just a 5 second clip is 100mb.

What I see mostly is links to video posted on youtube or other such video platforms.  (I already had a youtube account before this HV forum, which made video easy for me.)

[dru]

After typing this I see the max file size is 5mb, I am not sure how to make a video that small I will work on it, even just a 5 second clip is 100mb.

What I see mostly is links to video posted on youtube or other such video platforms.  (I already had a youtube account before this HV forum, which made video easy for me.)

I ended up compressing a video. I am now sending my .wav files through a virtual delta pwm encoder, then a full wave rectifier.