Hardware Frequency detector (for audio)

[RJSV]

  An experimental circuit module uses synchronous detection,  on a discrete set of samples.  For a basic lowest rate of 220 hz,  a buffer of 20 samples provides a delay line having exactly one half cycle time (about 2.2 msec).  Each detector channel takes a discrete sample, delayed by the one half cycle time, subtracting it from the current analog sample.  Circuitry has a rich mix, of analog and digital,  using the CD4017 decimal  counter, for example.
   That is a synchronous action , working to both favor one frequency (220 hz,  at 4.5 msec. cycle period), and also working to reject, on average,  other frequencies presented to the module input.  A higher level circuit controls the process, checking each of 20 phases, during the 1/2 cycle time 'Contest' period.  Contest 'winner' is expressed  by sending RESET to the modulo-20 counter;  Thus counter zero represents plus 90 degrees of phase,  the maximum of a hoped-for detection.
   Now looking at another detection channel,  using the delay line tap 'T19',  that shorter half-cycle is approx. 12 cycles per second higher,  the formula is to use the 8800 hz discrete interval clock, divided by number of samples back the delay is.  The highest detection uses 10 intervals back,  thus also having 10 possible phase choices (to try).  The resulting range, of the full 10 channel detection module, is from 220 hz up to approaching 440 hz (actually less)  for an approximate range of one octive (baritone).
MORE TO FOLLW< Thanks

[RJSV]

  The Frequency detector has a very 'wide' output format:  One option keeps each detection channel separate.  In the 3 lines for each channel there is a pulsed line, signifying a 2X clock for a sine wave (generator).  A second analog line signifies the amplitude info,  while a third line conveys 'Signal Present'.
   Note the convienience , that clock divider(s) can be used,  to bring an ultimate pitch down an octave, or two octaves.  Thoughts of mixing all ten channel pulse trains don't pen out:  likely producing copious spurious output frequencies (but perhaps interesting).  A (good) recreational designer benefits from lessons learned from mistakes, sometimes;  always keen to learn!

   A key aspect here, is the lack of some explicit encoded  phase output,  leaving each channel as-is.  The justification is the so-called 'Trombonist' theory; if the musician skoots his chair back, the phase (of his sound) is different.  But no one cares, or notices.  Early design had (only) 6 output channels (for musical notes),  where a complex competition / ranking scheme (hopelessly) burdened the works.

  Sorry to present this in sections,  but cheerfully answer any ques, thanks

[mark03]

This would be much easier to follow, if you could post the schematic.

I take it this is implemented with discrete logic and some kind of switched-capacitor circuit, since you are talking about samples and delay lines.  Wouldn't it be easier to perform this work in software instead?

[boB]

Detecting a single fundamental  frequency, right ?

[RJSV]

boB and mark,  I have some answers, following.  Unfortunately,  had laptop meltdown yesterday, on LIBRARY computer now,  ah shucks...

   The frequency detector project has a 'front end' section, designed for a whole set of separate frequencies,  not just the single, base (chosen to be 220 hz,  that is the A note right below middle C).  Current choice has 10 separate channels, each with a modulo counter (exclusively using CD4017 counters).  That brings some efficiency, as every detection channel is served by the 'Ring Buffer'.  A simple pulse, 'READ NEXT VALUE' serves to enable a switched capacitor.  It involves a complicated / bulky digital 'Barrel Shifter' method.

    The actual frequencies where detection is attempted are as follows:  Discrete clock rate divided by number of delay samples back the channel is using, and divided by 2.  Each delay line tap is labled T20, T19, T18, T17, T16, T15, T14, T13, T12, and lastly T11.  So lets pick T15, for example.  The T15 delay line tap is for detecting 293 hz,  meaning that a new analog front-end system input is being saved, to a capacitor (sample and hold) every (approx.) 114 micro-seconds, and that tap T15 produces a delay equal to 15 of those discrete action times.

   That's a mouthful.  Readers may be starting to suspect:  This thing is gonna need a PC board the size of a small pizza!  Perhaps a good candidate for a FPGA project (that's a user programmed gate array).  Also,  obviously revealing just how valuable a 'one dollar cost' PIC chip setup can be,  doing all this with ease !!  So a main motivation (for this design project) turns out to be a curiousity question:  Just HOW does a Fast Fourier Transform (or FFT) do its magic ?

   I'd like to post, first, a schematic of the analog front-end,  where each output of a CD4017 digitally enables a particular capacitor.  Not real strong on FET use, the system brings one capacitor leg to 3.5 volts.  Each of the 20 capacitors is bussed together,  with one leg attatched to the 'enable' logic, allowing for both current directions charge or discharge.  Not sure how to import some hand drawn stuff,  VIA my flip-phone camera.

   Readers can visualize the system as resembling FFT structure,  or actually;  'half' of an FFT buffer, where real-time operation is providing or filling in the second half, of the sample stream.  In other words, instead of all the samples provided off-line to a software routine,  this (hardware) method will store a string of samples, during the 'NEGATIVE' half-cycle, and proceed to process each available pair (current sample minus delayed sample),  as time goes thru the 'POSITIVE' half-cycle.

    Now for a crucial bit of 'learning':  The realization that there usually is going to be NO clue where or what phase any content has, often regardless of visable waveform(s).  The hardware system simply guesses and checks, trying each (phase of synchronous detection), and keeping track of 'best detection, so far'.  A simple RESET is issued in that case, to the particular Modulo counter for the channel (the T15 tap example sends RESET to the modulo-15 channel counter.)

   Thanks for your time.  This is a big project, and I could use some training on FET's and on sample-hold circuits.  - - Rick-Jack

[boB]

Good luck on this, Jack.  This is pretty hard to do.  I would think it is hard enough to do in software like has been done with Celemonys' Melodyne plus a bunch of other new software for picking apart music that has already been mixed.  Amazing stuff !

I tried to start doing something like this 25+ years ago but didn't have the time to do a lot. My project was going to be a monophonic music to MIDI converter.  It sort of worked but life got in the way.

Keep us posted.

[RJSV]

Ceremony's Melodyne... hmmm gonna look it up, thanks.  I once tried to double-gang a piano works, for hitting octave pairs, aka harpsichord settings...

   A 'Drug Store' arcade toy often puts out a kind-of perfect-like music... meaning that no wavering of pitch or breathing effects to interfere with a finicky detection method.  An earlier musical pitch-shifter design used various toy arcade game systems as a cheap music source for testing.  Having 160 classic games stored, one hand-held provides everything from (soft) flute sounds, to hard-rock big-band, (and seems to have lots of SALSA beat 'cha-cha' ,  thats ok).
   An octave dropping circuit works to trigger a CD-4013 flip-flop, with the gamer audio output;  best results used two biasing resistor 'legs' (10k), each set for 4.5 volts in the middle (half of VCC).  The hand-held gamer output 'ground' connects to one 4.5 vdc bias leg, while the audio output hot lead connects (VIA a series capacitor) to the other 4.5 vdc bias leg, which then drives the IC (clock) input.
   (Worthwhile results can be erratic / elusive, there...)

   (NOW back to the current 10 channel design)
   With a multiplicity of instruments,  no effort was made, to interpret or distinguish over-tones VS. actual fundamentals  (as is usually found in the classic Fourier series,  concerned with one sound source,  like an OBOE...)
   In terms of the RAW detection system outputs, results are potentially highly erratic, (best phase found), when lacking any smoothing filter.

   Each new result, for 220 hz, arrives 220 times per second, assuming the detection is continuous.   Alternatively, a 'single burst' detection method simply streams samples once (into the twenty capacitors),  as a list where each (capacitor) is hard-wired to a dedicated OP-AMP (LM-324)  COME ON... its simpler that way!
Thus all the same delays mentioned earlier,  T20 down to T11 are available just like before,  for the synchronous detection process.  But for one pass only!
   There is not the burden, of keeping the sample list maintained in real-time,  along with attendant horrendous barrel switching ...  ...

   Now, a digital-oriented 'smoothing filter' for best phase indication coming rapidly out of the detection;  thats a whole new (nested set of signal-processing prob.s !
   --  --  AW Shucks !

[amlu]

teensy can do a lot....
https://www.pjrc.com/teensy/td_libs_Audio.html

[boB]

teensy can do a lot....
https://www.pjrc.com/teensy/td_libs_Audio.html

Very interesting !  Thanks !

[nick_d]

I think the hardware frequency detector is an interesting and worthwhile project.

I've done similar types of stuff, back in the day -- such as a compressor which used a number of RC filters to separate a sound into semitones (RC time constants were chosen one semitone apart, to bracket the notes like A, A#, B etc) and then individually track and boost the volume of each channel. It didn't have good channel separation, since the rolloff from a single RC was not very steep, but sort of adequate to the task, I mean it pretty much worked.

BUT! And here is the but! I was doing this using a PC, so I had the soundtrack to be compressed already sampled on the computer's hard drive, and my "RC" filter was a discrete simulation basically like: x += (sample - x) / 16 where the 16 sets the time constant to 16 samples, well you get the idea.

Why I mention this is that having written the program and tinkered with it endlessly (graphical bar displays for which semitone it detects etc), I actually wouldn't want to physically build it, because not only would it be enormously tedious to build (so many copies of the same thing) it only worked kinda so-so and the "virtual" build gave many many ideas for different directions in which it could be improved.

I think that's what's going to happen here if the project is built as described. From what I can gather it consists of a delay line constructed by a chain of analog sample-and-hold amplifiers, plus some kind of correlator that, for example, maintains a running sum of x[0] times x[15] say, so that the signal delayed by 15 is correlated with the undelayed signal to detect if a sine (or other) wave of that period is present.

(Well I may have added the multiply bit, look up correlation and autocorrelation in any good DSP textbook about that).

While this would work, it seems like it would not be super robust as has been mentioned by OP, if multiple tones were present the detector would need to check their strengths to find the dominant one (perhaps with hysteresis to ensure a stable lock onto a particular tone), it would treat harmonics as baseband and so on.

There are also some issues with the tap spacing, I am unclear why there have to be 10 different frequencies to be detected, I guess the idea is to have evenly spaced periods or spacings of an integer number of samples, but this is not how music works, music uses a log scale and it would make much more sense to detect the 12 semitones... but their periods are not evenly spaced, so a simple delay line with a chain of sample-and-hold, clocked together, won't work.

The FFT with its evenly spaced frequencies is also not the right tool for this kind of work, and for the same reason. A wavelet transform is more sensible in principle because it divides the signal into octaves, e.g. 110-220Hz, 220-440Hz, 440-880Hz and so on. This gives you about the right amount of information per octave, whereas the FFT gives you say 100 different frequencies in the 110-220Hz range, 50 different frequencies in 220-440Hz, 25 different frequencies in 440-880Hz and so on. It's very bottom heavy, say there were 8 octaves you'd have an enormous amount of data for the bass drum (more than you could ever use) and practically nothing for the cymbals. I realize that this project does not call for detection of harmonics, but even so, when you use evenly spaced frequencies over one octave you still have the same issue and it needs more processing to fix (such as merging the first 16 frequencies to bracket A, the next 13 to bracket A#, the next 11 for B and so forth).

Another issue that I see with the proposed design is the mixing of analog and discrete techniques. To do this in a fully analog way would be totally cool. What you would do is take something like the reverb pan from an old guitar amp, configured as a delay line (sound travels along a spring) and put pickups along the length, at gradually increasing spacings corresponding to the period if each semitone, then use an ANALOG multiplier (a complicated diode or FET circuit that would be super fun to build) and integrator... however, ths would be complex and hard to get working.

On the other hand, if you are going to do things discretely, there is simply no reason to have sample-and-hold amps for each stage of a delay line, when you could simply have an ADC and store samples in RAM in a circular buffer. It is so much easier to do, and any advantage of the analog approach is already lost once you decided to use a sample clock. As mentioned the Teensy has the ADC and the RAM.

If you want to do a hardware approach and you only want to detect ONE sound (let us say a sine wave) then a MUCH more satisfying and easy to build approach would be to use a Phase Locked Loop (PLL). Basically this is a voltage controlled oscillator, with a circuit to automatically and continuously adjust the control voltage, and hence the frequency of the oscillator, such that the waveform generated by the oscillator closely matches the signal whose frequency you are trying to detect. Then you inspect the control voltage, to get an estimate what the frequency is.

A simple circuit to detect singing pure tones might be done with the following stages:
1. Mic
2. Mic preamp
3. Possible automatic gain control and silence indicator
4. Biasing to get a signal of 2.5V +/- about 1V of your audio
5. 74HC14 Schmitt trigger to clean and threshold the signal
6. 74HC4046 phase locked loop and locking indicator
7. Extract control voltage of the PLL to next stage...
8. LED bar graph and comparator chain to show semitones
This would be a cool project that is concrete and really doable. To make it better you could add filtering or maybe an analog multiplier so the PLL phase detector computes a correlation rather than the Schmitt and square wave idea?

I also suggest that whatever you do, SIMULATE it first. This stuff is really difficult to get working and you always end up building the whole thing differently from scratch several times. Especially as a novice, try to avoid that waste of time!

cheers, Nick

[RJSV]

Yes you're right,  about 5 IC's is a good enough build size for me.  Since Radio Shack demise,  I can still cruise to Fry's, picking up those longer proto strips,  that can handle maybe that much logic.

   By way of answer, I stopped adding channels at the 'T11' point, because step size gets out of hand, dividing by an integer below about 10,  whereas when dividing by 17 then by 16 is not such a huge jump.  But I get the point about a 'bottom heavy' system, reporting way too much on only slightly different places.   I suppose I could claim the 20 sample capacitor store is 'too crude' to suffer regular analysis, (partially true!).
   It can help to view the capacitor audio buffer, in a time-line, left to right.   Starting on left, is the oldest sample, at 2.2 milli-seconds, is T20.
For a run of ten capacitors,  each has an assigned channel,  ending on (channel tap) T11 at the lowest.  The remaining capacitors (channel tap) T10 downward continue the time-line (and indeed the audio sample storage continues un-interrupted) but are functionally different,  essentially T10 down to delay T1 are used as the progression goes thru each possible phase ( of detection).  When the hardware is finished in the discrete interval of T1, that is the point in time of the audio frequency 220hz reaching one half cycle time (2.2 msec).
   At that point in time (after T1), there are now 20 samples complete and stored,  ready for the process half (simple subtraction).
The set of ten frequency detection points, is over a piano half-tone range of ten notes,  and so obviously is going to fall short...

   My logic-design skills obviously exceed writing skills,  I find clear writing a task!    As a micro-code writer, it is 'relaxing' to put various designs togther.   Maybe someday....    hmm

[RJSV]

OK, here is a really cool discovery:  The ratio of 'step size' between integers, when dividing by numbers around 20,  happens to closely match the 'perfect'  calculated piano type notes,  where that ratio is, I believe, the 12th root of two.  Turns out to be 1.059 463
  The 'detection' frequencies are:  220 hz (A),  232 hz (A#), etc.  (244, 259, 275, 293),  each detection only off by one or two hz

[DaJMasta]

So you're trying to detect a fundamental frequency of a live sound signal for the purposes of pitch shifting?  I'm still trying to make sense of what you're really trying to do - is there a reference tone that you are comparing the input to, or are you trying to discern the fundamental from the incoming signal and compare that to the rest of the data?


Your capacitor bank explanation sounds like an analog version of an ADC with very little storage memory, is that right?  Even if you want to end up doing this in analog hardware, I would start with a PC, a sound card, and a spectrogram program (like the freeware Spectrum Lab), to actually visualize the frequency content of the kinds of signals you want to see.  I'd also take a look at programs like the freeware Audacity which let you zoom in on the waveform itself, so you can visualize how these extraneous noises from playing an instrument or singing or whatnot actually look like as a waveform.

Because it's a tricky problem to figure out the signal vs. the noise in an electronics sense, I would try to come up with methods of processing the incoming signal on the computer where it has plenty of grunt to try things out, then when you have a detection algorithm in mind and want to build it up, you have a better understanding of what's happening and a working comparison point.

I've done some work on a tuner frontend for a frequency counter, and just manipulating a real signal to arrive at the played pitch quickly is tricky.  You have to auto-gain control it so that articulation noises or volume fluctuations aren't a big issue, and you have to tweak the settings of it so that it doesn't respond too fast to big changes but responds fast enough to catch moving notes - much easier in digital, but needs a fair bit of processing.  If you think of looking at the problem with FFTs, you'll eventually see that while bins are typically linear in size, that means you have to pick your bin size to be ideal for the range you're looking at, because you will lose detail quickly on the low end.  One technique to get around this and get very small bin size (high frequency resolution) is to run several FFTs on the same input signal, but with different bin sizes and different bands of interest, so that you have something closer to the logarithmic sweep and similar detail over all the ranges without having hundreds of thousands of bins.  1Hz difference at the bottom range of a bass could easily be an entire semitone on a musical scale, but several octaves up, could just be a small tuning glitch from the primary tone.

Also worth emphasizing that instruments and voices get their unique timbre because of their frequency content when playing a tone and their unique articulation sounds, mostly, and the frequency content will change a LOT with different ranges.  For example, woodwind instruments in their lowest ranges may have the fundamental may be fairly small, with a lot of higher frequency content, while in the central range of the instrument it tends to be more spectrally pure (pure being relative and this not being the case for every kind of instrument), and then high in the range often becomes dominated by overtones again, but in a different proportion than the other ranges.  Actually identifying an instrument from a signal would depend on characterizing its various ranges, then normalizing the incoming signal to compare it with those spectral finger prints - picking an instrument out of a group of them playing could be done in a similar way, but the combinatorial nature of all the overtones could get very processing heavy, very fast.  Not something I'd want to try in analog unless I could isolate a very specific sort of difference to look for that would give me what I was looking for.

As a side note, the standard 12 note equal temperament tuning system does use the 12th root (440*2^(n/12) where 440 is the reference tone and n is the number of semitones away (positive, zero, or negative) from the reference), but that's not the only system used - there are "pythagorean" and "just" tuning systems among others (and this is just in western music) where fundamentals are determined slightly differently, but which in some cases the tones line up to sound much more "in tune" than using an equal temperament system.  The classic example is a major cord, like the notes C E and G on a piano, when struck together will sound out of tune, but if you adjust the pitch of the E 12 cents down (cents are hundredths of a semitone, still logarithmic scale so you can calculate with the original formula but n/1200), the chord's harmonics line up much better and it sounds much more in tune.


There's a lot to look into in the field, but if you can narrow down what you're trying to detect or manipulate, it should simplify the problem quite a bit.

[RJSV]

Thanks for recent reply.  I am not a PRO in signal processing and appreciate those careful comments.  First, this project is for understanding FFT and to get a practical view of what convolution is, in common language(!).

   For a complete module, an accurate set of 9 adjacent musical notes can be generated/sensed (synchronously) using integer clock dividers of 17 or nearby.  Those being:  divide by (22, 21, 20, 19, 18, 17, 16, 15 and 14).  In this first module, it is 8800 hz divided by 22 (and then divided by 2) for detecting 200 hz (I believe near 'G' note) as the lowest in the run of detection points.  Engineering often calls for knowing what kind of sensitivity 'band'  is in operation (using a rectangular sample window of 114 microseconds duration).
The notes corresponding are:  G, G#, A, A#, B, C, C#, D, and D#  at (200hz, 210hz, 220hz, 232hz, 244hz, 259hz, 275 hz, 293hz, and 314hz).

   Now,for the CD4017 sequential outputs, channel T-20 for example, has a Modulo-20 counter:  lets assume the channel T20 counter is in 'LOCK' mode (lock with the audio input).  This simply means the counter Q0 output clocking state has the best phase for detection, (and thus the sample/hold circuit uses Q0 as a gate trigger.)  The 20 counts represent a full circle of analog phase (360 degrees), so a superimposed 'SINE WAVE' actually stretches along with 5 counts for every 90 degrees of waveform.
Thus the expected sine function is 90 degrees phase-shifted, starting at minus 5 counts, (that is count 15 for the 220 hz channel T20), going to the SINE peak at count=0 (phase = 90 degrees) and then going thru 180 degrees of phase, at count=5.  The shifted SINE function ends (360 degrees) at count=15.

    Readers should start to see:  the counter plays a simple dual role,  both in synchronous input actions and in synchronous output actions.  Pulses at Q15 and at Q5 are brought out, representing 'zero-crossing' times (zero and 180 degrees).

   It is a textbook matter from there, to generate an appropriate analog SINE wave:  first, the Q5 and Q15 outputs connect to clock a flip-flop (CD4013).  Now you have a square wave, 50/50 duty cycle.  Referring to the work of Forrest M. Mimms III , page 80 shows a function generator circuit.  (see Mini-Notebook Series Volume I).  A square wave is converted to triangular,  then filtered to make an approximate SINE wave output. 
   It is perhaps helpful to push the 'pulse stream' for earlier output,  using Q4 and Q14, as there are analog delays in converting towards analog SINE output.  (Maybe does not matter, tho).

   Now, for the T16 channel (a multiple of 4) each 90 degrees of analog phase travel is represented by 4 counts, and so the pulse outputs will be Q4 and Q12, neatly.  However, what about T19, or T17 ?  WELL...  never stopped me before:  Channel 19 simply 'pretends' to be approximately an even divisor:  Thus the pulse outputs, for channel 19, are placed at Q5 and Q15,  and resulting waveform is not entirely symmetrical, at about 55/45 duty cyle.

   Astute readers might note: it is not trivial to 'chain' together two CD-4017 decade counter, as both IC's will have 'live' outputs.  One method uses a 'RANGE' high / low flip-flop to switch out Q0 from the 'high' counter IC (and suppress counting).  That way a RESET can clear both counter IC's and clear the 'RANGE' flip-flop.
   The modulo-20 counters can simply roll-over, to zero.  The others (MOD19, 18, 17, 16, 15, and 14) use the classic method, by connecting 'last count+1' to the IC RESET.

ERRATIA:  I will discuss in another post,  thanks for your time!

[RJSV]

OOPS!  I'm off by a factor of two,  sorry.    What is needed is a 'POLARITY' flip-flop,  where my previous explanation has 90 degrees of analog waveform represented by 10 counts,  (not 5).   So a 'zero-crossing' pulse needs also to use the polarity (plus or negative half of waveform), for identifying which zero-cross.

Another source of error, misplaced mention of a divide by two:  proper formula is 8800hz divided by integer delay count, then divided by two...

Biggest error is ignorance of the 'opposite polarity' type detection, that being use of the negative going waveform,  along with a reversal of the subtraction process.  So actual detection, or first fully scanned wave is going to take 5 milliseconds or more, at 220 hz (cycle period of 5.4 milliseconds).  If thats OK then a latency of 7 milliseconds if possible...

T10 or channel with divide by 10, is not looked for.  (That would be 440 hz).  And a 'burst' mode will not work,  there is needed an analog front end that continuously chuggs in samples, at 114 micro-seconds per sample, which is 8800 hz.

   Note that an output pulse at Q10 can be issued early, relative to the whole phase tracked by the channel 20 counter.  For example, issuing the pulse from Q9 connection will be early by 9 degrees.  This is because there are 20 steps or phases in 180 degrees of analog waveform.
This easy availability of outputs, from a CD-4017 shows a flexible aspect of that un-coded counter IC.

[RJSV]

   Hello again;  I've hit the barrier,  too high IC count.    This project is not directly intended for stage-ready performance, (or even always in tune!).

   It is possible to build a couple channels for tests,  the audio device will 'correct' an incoming frequency,  say 289 hz corrected to 293 hz.  There is no explicit phase 'tracking' on a fine basis, as seen in PLL circuits.  However, there is a quick response,  not needing dozens of cycles to produce a result.  At 220hz,  even one cycle will take 5 milliseconds to get first result.   And the device could make a heck of a 'drop out' corrector, basically running a pulse stream ouput 'forever'.  The channel status signal 'Signal Present' flags the on-off sounding times.
   Channel outputs can have more than one frequency,  producing one or two octaves higher, (limited cases),  and easily producing one or two octaves lower (than middle C)  Thats similtaneous frequencys in one channel,  each with an audio sine gen.

   For ease of audio handling,  advantage is taken, of a mass of OP-amps.  Each capacitor connects to a differential  subtractor OP-amp stage, 
which then connects to compare with the 'current' best detected value.  That result is where the input analog section ends,  and the 'front-end' digital result is.   There is consequently no shifting or excess commutation of the analog sample.  There is, however, the piper to pay, for the digital access to that 'result' flag is horrendous,  involving a sequential barrel bit shifting scheme.
Doing this layout for more than a couple channels is just too much, tho,  something like 120 OP-amp stages for 6 channels!!!

   The Modulo counter RESET is an awesome and simple method, for synchronizing, when called for.  Also, along the lines of sync input, it is possible to 'deaden' any phase test contest for the last clock state, before T0.  That way a slight wavering of the phase will not cause the results to cycle rapidly ( a sort of hysterisis).

   I'd like to point the machine at itself,  running same freq. outputs,  as in theory it should detect (its own output).  And of course there are many issues of detection width, errors, etc.   Thanks.