Easiest way to display frequency as a number value via a signal from adc~
I am getting a very beautiful square wave signal from my audio interface (Presonus Firebox) in from adc~. I can connect it directly to scope~ and view the signal (calccount in scope~ at 50). So without doing anything to the signal, it is directly viewable in scope~… no biquad~, no cycle~, no change~ etc.
All I actually want and need is the actual frequency of the signal, displayed as a number value in a number box, etc. that will update rapidly and accurately as the frequency changes.
The number~ object perfectly displays frequency (as a number) when it receives the signal from the sig~ object… but I have a hard time figuring out why the number~ object displays values other than frequency when receiving signals from anything else… like an actual signal from adc~. I believe it tends to be displaying amplitudes, as it does in some of the tutorials.
I know there must be an easy simple solution… I have been through the MSP tutorials enough times… it seems to be a small annoying details not quite explained.
Any help much appreciated!
is there not a much simpler way to do it in Max, without need of externals? I mean, it seems like the answer is so close, right there, with just a simple connection or conversion… There must be an answer within the abilities of the Max objects…
What is the difference between the signal coming from the sig~ object, which number~ inherently displays as a hertz value, and a sound input signal coming from adc~? There MUST be a simple way to derive frequency for/from the number~ object if it already wants to display frequency from sig~…!
I would be astounded if Max MSP, for all of its signal analysis capabilities, could not easily display frequency of a received signal. It would seem to me to be the most fundamental of attributes to be able to display.
you could try [zerox]; but this will only work with simple harmonic waveforms (sine,square etc).
as far as sig~ goes, it just converts a number (float or int) into a constant signal– it doesn’t analyse the frequency content of an audio signal per se
Yes, I realize sig~is just ending out a constant signal… it’s what number~ does with that signal that interests me… number~ gives us the frequency in hertz when it gets the signal from sig~.
It’s partly my understanding of number~ that I’m trying to expand. It displays the "value" of the signal. Now, it seems to display hertz "value" for a sig~ signal, but a +- floating amplitude "value" for real signals from adc~.
All I need is a good clean accurate freq value of the square wave I am sending through my firebox, so will look at xerox right now.
(Thanks very much for the suggetions, goingdeaf and Terry McDermott)
Any other ideas welcome.
You are misreading what is going on with sig~ and number~. sig~ doesn’t generate a frequency. It converts whatever is going into it to a signal and sends that repeatedly at signal rate. For example if you send 440 into sig~ it doesn’t generate the frequency of 440. It sends the static number 440 over and over again at the sample rate.
Pitch analysis is a very complex process, and will take a significant chunk of work. There are a variety of objects that will help, but it’s not that easy.
Tried out fiddle~… it has a few blips at certain frequencies (values flickering to random freq’s)… the midi values coming from fiddle~ and going through the [mtof} are more consistent… but also disappear below 110 hertz or so…
Altogether, fiddle~ seems to work better than pitch~.
Regardless, I need something rock solid.
Ahh ok Chris Muir, understood regarding what is being sent from sig~, thanks for that clarification.
I am not afraid of significant amounts of work… :) The amount of work I have done prior to arriving at audio rate monitoring in Max MSP, especially with trying to get Max MSP to count zero-crossings and determine frequency in other manners… well… its been 6 months at least of trying the micro-controller route. So I’m very pleased with the array of options and the precision available to me once I treated my signal as audio and ran it into my firebox.
I am still a bit baffled as to how I can have a beautifully functional scope~ object displaying my clean consistent square wave signal, but no way to display the frequency with available Max objects.
@Terry McDermott: I tried zerox~, it doesn’t quite give me what I need, or the consistency. Thank you though for the suggestion.
i am sorry if this comes across patronizing, but it seems to me, that you don´t have a clear understanding of digital audio, which leads to misconceptions about what a digital signal actually is.
did you read the chapter on "how digital audio works" which is the introduction to the msp tutorials?
on the practical side, i had the best results in max with (free=no money) pitch detection with sigmund~ by miller puckette. but you have to adjust all values carefully to the signal you want to analyze.
and you never told about what kind of signal you are trying to get the frequency from, besides that its a squarewave. e.g. low frequencies are much harder to detect than higher.
tell us more about your goal and we can help better.
lol I have read all the tutorials several times over the years, several times just this week trying to answer my questions, and the answers didn’t come. For example, Chris Muir’s explanation of what sig~ is actually putting out and how number~ perceives it, is clearer than anything in the tutorials.
To which misconception are you referring? :) Some things seem to take a bit longer to sink in, I confess.
I am running various functions in my car using Max MSP:
The goal is to have RPM accurately represented in Max MSP as a number/frequency. The signal itself comes from the car’s ecu, I can choose between a few actually… I have chosen the IGT signal to start, it sends logic 5v square wave pulses, two per crank revolution. I am currently simply using a chassis ground for the audio ground going into the Firebox interface. It works perfectly… giving me a clean square wave visible in scope~, directly proportional to the car’s RPM.
As far as frequencies go, at idle, 750 RPM, we should be getting 25 pulses per second, or 25 hertz. At redline, 7400 RPM, we should get just under 250 pulses/s or 250 hertz. The idle range seems too low for fiddle~ to pick up… unless there are other ways.
Now for a second option, which is not as simple; the NE signal from the ecu is sent out 12 times per crank revolution, but it is not as clean, low voltage, and not a square wave, so I wired in an LM1815 (a sense amplifier that outputs a pulse, the leading edge coincides with the negative-going zero crossing of a ground referenced input signal) which puts out a nice square wave also around 5 volts, and this should give me square wave pulses in the range of 150 hertz at idle to 1480 hertz at redline. This signal might be the more useable range for the fiddle~ object.
sigmund~ looks very promising.
I’m going to fire up the car again and see what I see…
as i said, i don´t want to lecture you, but the idea, that a numberbox should by itself display the frequency of a connected signal, suggested a misconception…
anyhow: 25 hz is pretty low for pitch detection and there will be fllcker in the values, which you will have to smooth out. i have never worked with zeorx~ but it might actually be the best option still, as your original signal is a pulse wave.
think of it this way: even if your signal is perfectly constant at 25 hz it will never be alligned perfectly with your sampling rate of eg. 44100 hz which means, that there will be cases, where the signal will be misread on a 0->1 or 1->0 transition, which takes some time, introducing spuirous values and distorting the calculation of the frequency detection, which also has its own timing. thats were you need to average and smooth to some extent.
after some fiddling, you should be able to get good results though, as the case scenario doesn´t sound overly complicated…
here’s a way to do it by using cputimer to count the number of zero crossings of the square wave; it’s surprisingly jittery– not sure why… zerox might be better
----------begin_max5_patcher---------- 1553.3oc4Zs0aihCF8YxuBFdZWoLc7ELD1GFo8s8kUZ093VMpxAbRcWBf.Ra 2NZ5u80XCTHgKNzDT5tZFkzZisO97c9tXS+9BCq0wOyxrL+EyaMML99BCCYS EMXT96FV6nO6GRyjOlUD6o30OXsT0UN64bYyewDcSUiIzb+64QauKk4mqlaW zMfkl3U.4WnaHKMgd2.L+V4Ph1uKdedHKWtHvxV4Ax4Vrde1FWM6ahixin6X xt90TNMrpG0Lj+OIL0hZsILlJ.v2ZLxL9KxdgPARpWadT0RiJZ6GKVT7wRMo D+3c6XQ4GwIIrTdbf4OsK6mGfZfdXIoX6U7kqawmCvMfN3Fv3biN6c3D168J GbI.vPJBnZ+ZaSTeMx1tCIA16imj3O+iee.NAiUbgjLvjSWIfWMYkPRJKSfX ZNONpAjHHofj3sp3KP4GMQz6S+zGQ8a+0PZGD3MQi8T3I2qNOlz38QAiFA0l nBj5MA2EmI3tb48TdHaOWivDpsOzwt9qSH2AoZAVGmFvRaJJ1vCY0bQAVtK6 o33j.AobyCYZvK832.pcW5DyOjQS2tuP4Wl7874Q0aDYxfwicKSMuZpYnwWw YnEKiXNFRlgcZjDlLVHEzwaej8j29KMsVSi1NJMzWHZk.i.f8EhNf4y2QCSB o9rV3+RI1dIzLaP9tTsATI+QSftmhZqfou7hsA3j7TFcmvRMJyfbk1T0ubhL C3iFyjExCXlPf3+ieFBafrfDG2SOCHb07DgBeIhPUt6U5BGoeCBeJ5Bny4M. 0FQvjlDcKlwdrfV1kAsPjKSck8H09zWLc..fF5LLQU3KdB5Lx0alvd3ku9p4 fbhirr.nJdMVxLHvovIHzD3jL91HQ28QJDOBbk6rUifi2aG5fLg.yPMRYI1C 7cBTTLCfZq96rtg1NSKq260qTwtYBLF6k.p+qCvXnUxppPNf2NnVwm5ePs5i 3eoD9aF.9qT5bzjuzJ2ObwA97HgAjt.HxjYDmObLRt4Fw+VOJo.UZcamQBLf OlTHumDyumPAmOVxOYueXr+eONMQ7lZZU64Q6bFYkDSQgszPyBRPXcBYilgU UdGD5LgLrv4LCKr4NQckJF0ji5ZUdjklIJ5qwSaXQSRZzrQigTvnODKmHxx5 l3Qplf0MkxdjWMdOUiB6zhpNqquzSwjp5KgkgxwMpXVXS2VHYYAMx8XXEv1b ZyRbBKpq684vZZUOIOpYAwGtxz8g420xFTWDP69qJ9tyN6z1aXsMkGDGU.hV irn4pk6Vg+oxKsItkOQDMoiAmGGGtllVXRVGxZYpEdLTQwLzbVNWgGDndb7c Io7n7VyEKhJli6y7SiCCaMUpddridBDpAe1S7f76ky0arUqWrUScVSe4VsOj O8AYIKpVlzrqNbnsgJoyJ0oVOzgtem5ipar4B0u8UG+6w7w6ISpQUDwRusyO i90SfQU2yU4QfmDih9e.ilbOMKN8UsnT00LoxIOMFE+eEFUgN8DhDUVZR0mC PaftoMaq91SM44p2QVwnrNi6U4pMxVEhbqtpIM2p8nPHCpAZWm1wzA3Dni2R bExi5KGfbqVze27TV79T+JvUFD1r8tNfkkyipSieasE8fm6ddPP6rlpJaBRh 4Md8OZYWOUTizD0vqJTi0D0nqJTSzD03yHpKarp.XqL5irf6Dqhv+8NZddJe 89bkKPqpy6uHwwJBUTx7ZZXYU+0yQ8v6r1zycAsKdiENwyok4Kpf80A+KKPc JU0KY.B.UW1m9WYEp937B5e6VVyyundK+sNwg058apHGb0sF5SC88EOpDUN1 cdEGUCeqebn5PREm9ff7rgnkc9Svhsw46zsrfsCxkk2Yb4eTKvIbgoS3.sxa A4ceaHxA1N8ghnNLnPIccbHLuld48kqnUHiiCCzcHfiLd5hohW+0nX5.feow jMVCLc.vu37DQGaGdVwDVKdZd0SHcvD9JjmP1yKOAzASyKO4nCj.WggmblW4 jN7DbdwDBpisCMuXBoCOMuxIshDLuXRmDKNyNhfifH2VOybfHjFHZFqQQCq1 7l40UScz7Y0zIlj8UXXx2icS7K+Xw+1fN04C -----------end_max5_patcher-----------
Having a numberbox display a frequency is the end goal only. I certainly wouldn’t indicate that by itself it will display a digital signal connected directly to it… having a numberbox for an end result clarifies that I need a frequency number value that I can connect directly to other objects to perform math/timing calculations etc… as opposed to a signal representation such as in scope~ etc.
I aimed specific questions at the [number~] object, because I wasn’t up on what it really was displaying.
Nevertheless, I tested [sigmund~] in simulations yesterday, and it appeared to be rock solid all the way down to 12 or 11 hertz, and useable certainly still at 10 hertz with minute flutter. At 9 hertz it becomes unstable and at 8 hertz it is unuseable. This was great news. 10 hertz is all the way down at 300 RPM… well below what the car idles at. I can have any signals below 10 hertz simply register as zero for RPM. At 7500 RPM, the hertz value will be 250.
So I went and fired up the MR2 and plugged in my firewire.
It worked flawlessly. Exactly as in the simulation. No blips, no flutters, no need for any averaging or smoothing. Straight from [sigmund~] frequency output (numberbox) to the dial, in which I updated the dial inspector range setting to 246.669998 (for 7400 RPM). (Ignore the old dial to the right, it has a range of 11,100 and math applied to it to get it into range, which creates artificial flutter…)
It worked so well in fact, that when I compared it side-by-side to my oem Toyota tachometer, it left the oem tacho in the dust for responsiveness and accuracy (minute changes in throttle makes this obvious).
Here is a You Tube video of yesterday’s startup trial:
And a pic :)
Thank you VERY much, all of you, that contributed, answered… It has involved contributions from no fewer than 6 forums to get this all to work out, and various disciplines… You guys simply rock.
gandalf, i am glad, sigmund worked for you (it has worked for me several times already) and congratulations for your success!
i think its a really fascinating idea.
(if your project wouldn´t have been so interesting, i wouldn´t have taken the time to lecture you about possible misconceptions :-)
Haha! thanks :)
honestly there is so much ground to cover in Max, and also hard to keep my "schooling" refreshed in the fields, that I am sure I have several misconceptions brewing as we speak, lol … Its good whenever something can get pointed out.
There’s also fzero~, which comes with Max.
gandalf: read the first like, half chapter of this book, (read especially page 2 in chapter 1: sinusoids, amplitude and frequency)
and youll understand how the computer is generating sound.
it just spits out voltage numbers to control a speaker (inbetween 1 and -1) and thats all sound is. it spits those numbers out at a sampling rate, so like 44.1 khz, means 44100 samples of a sound wave per second, so if you have a squarewave being generated by the program with the pulse-width at exactly 0.50, it will be outputting +1 for 22050 samples, then -1 for 22050 samples (if the freqency is 1 hz)
in order for something to detect frequency, it has to be able to detect the pattern of what is being sent in.
for it to do this with a squarewave, it has to understand that its supposed to be outputting a 1 to -1 transition over 44100 samples, then it would have to detect when that pattern repeats and detect how many times it repeats over 1 second in order to get the frequency of the input, now if you put something like reverb on to that input, its starting to add complex distortion to the signal which would be very complex to detect where the sound input repeats its algorithm used to create the tone.
Forums > MaxMSP