SynthMakeraliasant ·
Anyone made this?
I have started comverting one of my compressors into a MidSide version and I need a goniometer to calibrate it but realized I didnt have one and couldnt find it here.
pleeease. heeeelp..
Goniometer
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
grisnfitz ·
hi here, i wanted to ask the same... im trying to build a phase correlation meter, but dont know where to start. is that possible with SM? thanks in advance, cheers, michael
infuzion ·
I would assume to use the Level Meter, that reads the difference of the L&R channels, & add 0.5 to the sum to have 0=middle.
aliasant ·
infuzion wrote: I would assume to use the Level Meter, that reads the difference of the L&R channels, & add 0.5 to the sum to have 0=middle.
That would make a phase correlation meter but the goniometer is something else. The image I found might be somewhat misguiding.
The goniometer is to display the stereo field. =)
But thanx for the good explanation on how to make a phase corr meter =)
infuzion ·
aliasant wrote: infuzion wrote: I would assume to use the Level Meter, that reads the difference of the L&R channels, & add 0.5 to the sum to have 0=middle.
That would make a phase correlation meter but the goniometer is something else. The image I found might be somewhat misguiding. The goniometer is to display the stereo field. =)But thanx for the good explanation on how to make a phase corr meter
Welcome, but I did explain to to make the bottom 15% of your picture 😉
grisnfitz ·
oh, i see. i never heard about a goniometer 😊 and the pic looks like a correlation meter i had once 😉 thank you all, i will try to build one.
cheers, michael
Acrobat ·
grisnfitz wrote: oh, i see. i never heard about a goniometer 😊 and the pic looks like a correlation meter i had once 😉 thank you all, i will try to build one.
cheers, michael
yeah that's phase correlation, I think Aliasant wants something like Waves PAZ Position, instead, the bottom part of Waves PAZ Analyzer that tells WHERE a sound is placed the stereo field INCLUDING offphase positions. Right? 😉
aliasant ·
Right ! 😉
oddson ·
From what I can read about what it displays under different circumstances it sounds like it's just plotting the LR signals in cartisian coordinates but rotated 45 degrees CCW.
I think it literally is just the signal plotted in two dimensions (offset 45 degrees).
That still leaves the hard bit of how to display a signal that's changing hundreds of times faster than the display can show.
oddson ·
The Point Array components seem to be the only option here and I don't think they are up to the task.
Here's a draft of an attempt.
Goniometer.osm
If it was more usable I'd have kept going (fixing the area definitions so they don't rely on the display settings for one).
The point array lines component normalizes in the x dimension so your forced to normalize the y. But I think latency in this calculation is causing the jumpiness and other problems.
If the PALines component had a normalize option (or non-normalized option so it didn't break existing schematics) then it might be up to the job.
Any experts here who can confirm or refute this?
aliasant ·
That was a nice try oddson. !!!
Im surprised you guys never heard of this thing before. Its very useful to measure the width of a signal. And to see how even the signal is spread in the stereo field.
A mono/Mid signal should display a straight line from north to south. And any Sides activity should then be plotted to that.
So Im not sure about this normalizing thing. wouldnt that always make the plot round even if it were a mono signal? And even if the signal is weak? Or am I just being stupid now ?
Anyways. If we cant make this with the tools we have maybe we should talk to Jorge and Malc. Maybe we need a new primitive or two?
This tool is quite essential.
oddson ·
So I'm not sure about this normalizing thing. wouldn't that always make the plot round even if it were a mono signal?
No... it just won't show volume differences and (I think) it's causing the display to be unstable (or at least I can't come up with any other reason why I can't get it to be a stable display).
If you put a mono signal to both channels or an inverted phase signal to the other channel it will show (almost) vertical or (almost) horizontal.
aliasant ·
I made some modifications and heres version 2 =)
http://www.martin.rodensjo.se/assets/goniometer%202.zip
It is much better now. It suddenly hit me that we cant make this using Left and Right signals.. We need it to be Mid and Side. Pretty obvious but ... well. I just got up from bed.
It looks more like I would want it to but there are still issues.
1. When using MidSide the angle is a bit wrong. I think there is an easy solution to this but I cant quite figure that out. Might be something with the phase.
2. It jumps back and forth . Maybe I shouldnt have removed the norm from the sides channel? Or its again something with phase. Maybe a rectify with sign thing some how ?
Try it. This seems to be doable. =)
oddson ·
I'm not sure about this... 😕 I take another look tomorrow but whatever your changes do they don't solve the jumpiness problem.
aliasant ·
The jumpiness has to be the phase of the Side signal. Im almost convinced.
Should be possible to solve with a rect/sign thing some how.
aliasant ·
Worked on it a bit trying to improve it and to find a solution to the jumpiness.
http://www.martin.rodensjo.se/assets/Goniometer%203.osm.zip
Didnt have any success =(
But Im still pretty convinced it has something to do with the phase.
As I saved the latest build you can hit V on your keyboard and you should see a round circle representing that sinus wave coming thru a chorus and at this freq it doesnt jump. More like a fade.
i also added another mode. Sorted. I simply put a sort float-array on the mid channel. It made the jumpiness go away but its not a goniometer anymore. I have no clue what it is. But its pretty cool =)
Someone else needs to use their magic hands on this. Im out of ideas.
TomC ·
aliasant wrote: The jumpiness has to be the phase of the Side signal. Im almost convinced.
Should be possible to solve with a rect/sign thing some how.
It's the amplitude of the mid signal. You could easily compensate this by adjusting the starting coordinates of the area you're drawing into with a multiplier of the amplitude, so the area would move against the direction of your graph and the final graph wouldn't move relatively to the eye.
The problem with this you must do this for each float sample in your float array, and I don't know how to extract these in time.
If(!) you're able to make this thingy work with pairs of single floats (instead of float arrays) it'll be easy.
Tom
infuzion ·
TomC wrote: aliasant wrote: The jumpiness has to be the phase of the Side signal. Im almost convinced. Should be possible to solve with a rect/sign thing some how.
It's the amplitude of the mid signal. You could easily compensate this by adjusting the starting coordinates of the area you're drawing into with a multiplier of the amplitude, so the area would move against the direction of your graph and the final graph wouldn't move relatively to the eye. The problem with this you must do this for each float sample in your float array, and I don't know how to extract these in time.
There is a Float Array Mult, is that what you need?
aliasant ·
I have no idea what we need. All I know is that we are close but o so faar away from a solution. Do you think you have time to have a look at it Infuzion?
pleeeeasey pleeeaasy? =)
TomC ·
infuzion wrote: TomC wrote: aliasant wrote: The jumpiness has to be the phase of the Side signal. Im almost convinced. Should be possible to solve with a rect/sign thing some how.
It's the amplitude of the mid signal. You could easily compensate this by adjusting the starting coordinates of the area you're drawing into with a multiplier of the amplitude, so the area would move against the direction of your graph and the final graph wouldn't move relatively to the eye. The problem with this you must do this for each float sample in your float array, and I don't know how to extract these in time.
There is a Float Array Mult, is that what you need?
Unfortunately no. It's possible to minimize (but not remove completely) the the movement for one single frequency at a time by manipulating the incoming float array, not more.
I still think the solution to move the displaying area in the opposite direction so the graph seems to not move is the simplest one, but I didn't found a way to extract the value for this for each single float.
I experimented with the phase array of the FFT primitive, but besides some really interesting visual output it didn't solve the problem.
Tom
aliasant ·
I experimented with the phase array of the FFT primitive, but besides some really interesting visual output it didn't solve the problem.
Tom
I too experimented with that and got some truly hypnotic visual outputs. Quite addictive. If it wernt for the jumpiness.
oddson ·
Using the mid/side math is exactly equivalent to rotating the xy coords
2D rotation..
x' = x * cos(theta) + y * sin(theta) y' = -x * sin(theta) + y * cos(theta)
given the equality cos(45º)=sin(45º)
x' = (x + y) * sin(45º) y' = (y - x) * sin(45º)
The missing scalar multiplication only effects the numeric scale of the output and is irrelevant for an non-scale graph (if both or neither channel signal is normalized).
I'm not sure which is more efficient - rotating the graphs or the signal (I would guess the graphs because of the lower rate but that could be more than offset with colour and additional info to deal with). But as long as the jitter is there your method is better as it is less misleading to have the movement in the vertical plane (which your 90 degree rotation does for you).
As for the jitter itself.. it's the component and not the signal or anything to do with the signal.
If you reverse the signals to the xy feeds of the Graph2PA you'll find the jitter retains its orientation which is in the X axis before you rotated 90 degrees. I'm virtually certain it's the X normalization that's causing it and I don't think there will be a satisfactory work around.
TomC ·
oddson wrote: As for the jitter itself.. it's the component and not the signal or anything to do with the signal.
If you reverse the signals to the xy feeds of the Graph2PA you'll find the jitter retains its orientation which is in the X axis before you rotated 90 degrees. I'm virtually certain it's the X normalization that's causing it and I don't think there will be a satisfactory work around.
That was my first thought, too. But connect the output of the OSC to whatever meter you like best and you'll notice that the amplitude changes correlate quite well with the jitter.
Looks like the goniometer IS actually correct, but not pleasing to the eye.
Tom
oddson ·
It is correlated to the amplitude... so is the normalization process.
If it's not the display primitive itself, how do you explain why swapping the signal inputs does not swap the orientation of the jitter?
aliasant ·
oddson wrote: It is correlated to the amplitude... so is the normalization process.
If it's not the display primitive itself, how do you explain why swapping the signal inputs does not swap the orientation of the jitter?
So oddson.
Are you saying the the primitive has a bug or that we need a new kind of primitive? In any case I think maybe we should get Malc or Jorge in on this?
A goniometer is pretty much a standard tool and if we cant make that in SM that is kind of ...well. Or?
oddson ·
Are you saying the the primitive has a bug or that we need a new kind of primitive?
It think it's both. I'm thinking 'bug' as I can't see why if you normalize the y dimension it doesn't jitter while the x does.
But even if it's a bug and is promptly fixed, I think it would be much better to have a scale input to override x normalization or a separate primitive that doesn't normalize... which may also be very usefull for other data displays.
I certainly would like to hear from OutSim on this issue but they don't spend as much time on the forum these days. I'll email Malc and ask a few questions.
TomC ·
oddson wrote: Are you saying the the primitive has a bug or that we need a new kind of primitive?
It think it's both. I'm thinking 'bug' as I can't see why if you normalize the y dimension it doesn't jitter while the x does.
But even if it's a bug and is promptly fixed, I think it would be much better to have a scale input to override x normalization or a separate primitive that doesn't normalize... which may also be very usefull for other data displays.
I certainly would like to hear from OutSim on this issue but they don't spend as much time on the forum these days. I'll email Malc and ask a few questions.
I think it's not a good idea to normalize at all inside a primitive. Let the people normalize outside and let the primitive do what it's supposed to do, drawing lines from an array of points/floats.
Tom
Wrote something here? To have a post removed or your name hidden, write to [email protected].