issues with "smoothness" of signal when using buffer?
Nov 7, 2006 at 11:51am
issues with "smoothness" of signal when using buffer?
I am attempting to use a buffer (via peek objects) to “map” the ampitude of an incoming signal, and use its charactertics to drive another audio chain down the line…
basically (i hope this makes sense) i am using a snapshot~ object to take 50ms samples of the amplitude of a “live” signal, store it at 50ms intervals with a peek object, and have an output chain which uses another peek to pick up the samples, and lay them out via a line~ to recreate the original amplitude, but as control data of a sort…
im having this inescapable issue whereby the resultant amplitude continues to “waver” – ie im getting the basic mapped amplitude curve, but it flutters like crazy and isn’t smooth… its almost like in between every stored/accessed point of data it is inserting a zero value, which chops up the signal…
I dont know if im falling into a common issue in terms of storing to or accessing the buffer, or if perhaps i have not configured my line~ object correctly, but for the life of me i can’t work it out
i am a max novice, and have tried my darndest to resolve this by myself for the past many months… so im hoping the greater community may be inclined to chip in with some pointers…
the patch is below, it wont work in isolation as its driven by a sort of gate that triggers the buffer process based on the level of incoming signal, but hopefully if im doing something stuipd it will show up visually
many thanks to those who take the time to look at this and help out
Nov 7, 2006 at 12:12pm
Haven’t had the chance to check out your example, but it soundt like it would be a better idea to record the envelope with
then use index~ to playback the control information…
This method will keep the date entirely in signal domain ;)
…not sure if this is what you meant though… i can post en example later..
Nov 7, 2006 at 1:23pm
i couldnt really follow what you were trying to do, but i have attached a patch which is part of some audio analysis patches i use… which work fine for me!
from what i can see part of your problem might be coming from the analysis not being based on absolute values. but i dont know if that might be part of what you actually want!
anyway, hopefully the patch below will illustrate another way of approaching the idea… you need an audio input source (i was using a drum machine), or replace relevant part of patch with sfplay~.
Nov 8, 2006 at 10:00am
The problem is simple. You take a reading of the instantaneous amplitude at regular intervals, which means that you reading is arbitary with respect to the input signal. If you imagine that the waveform coming in is oscillating back and forth across zero (as audio waveforms tned to do) then imagine picking a random point on it, it is clear that you might get a zero, or near zero value, even at a point where the perceived volume is very loud.
The solution is to use envelope following (track the overall volume of the input, rather than individual sample values). There are a bunch of ways you could do this, and some of the suggestions above would be worth a look, but in terms of modifying your patch, try replacing the [snapshot~] with a [peakamp~] which will give you the largest instanteous sample value between two write times, rather than an arbitrary one. That should follow the input more effectively in terms of envelope.
On a more general note, it’s worth including full patches when posting to the list, as your post (at least the text one) doesn’t give any indicating of what happens to the signal before it reaches this subpatch, which could be quite important…..
Nov 9, 2006 at 12:49pm
Thank you for your help everybody
Ive been tinkering for the last while trying to make this work well
Alex, I knew there must be someting simple like that- once i saw your explanation I realised one of the big mistakes Ive been making.
I replaced snapshot with peakamp, which has helped somewhat, but not completely resolved the issue.
Ive tried putting a average in absoute mode in front of that, and have been mucking around with settings for that. Is there any point in doing this? I guess I was hoping on using the average~ to even out any major flutters in the signal, making it easier for the peakamp~ to find a sample set that is more consistent with the spirit of the overall amplitude…
i really dont understand what im saying here too well, my understanding is somewhat peripheral…
perhaps in terms of getting a more “averaged” result I should increase my sample interval and metro settings to someting more like 100-500ms? if the resultant data is fed to a line~ in the end this shouldnt be an issue in terms of getting a general indication of the amplitude character, should it?
I am probably not making a lot of sense here! late night with new baby in the house, frantically trying to make time for my patch…
thanks again all
Nov 9, 2006 at 2:32pm
dunno if you had time to look at the patch i posted… in my amp analysis patch, there is a slide~ object which i use to smooth out the resulting analysis.
only thing is it’s signal based, so u have to convert your float from peakamp back to sig~ then into slide~.
you could keep things in the max domain by using line, but the advantage of slide~ is that you can control the up / down smooth factor. this is better illustrated by the patch, particularly the multislider which is used to display the analysis result…
Nov 10, 2006 at 10:42am
i did have a look and now im heving a better look! trying to suss what it is you are doing there, i will have to look into the slide object futher…
i hope to understand it better some time soon… i think i can see whats going on there though
Feb 16, 2007 at 5:46am
thought id just say thanks again to all who helped with this one – justin your patch really helped once i got to the heart of it
resolved this one – (after throwing out 6 months of work and starting again on better founded ideas)
very much appreciate the input of the max community – nice one guys and gals!
You must be logged in to reply to this topic.