ICST ambidecode/ambiencode issue
Hi all,
I feel like i'm missing something really dumb here, but i wrestled with this for a little while and couldn't figure it out.
I've started messing arond with the ICST ambisonics. current version i have is the latest, 2.3.
I opened up the example patch of "02.absorption" and started to get familiar with it. I decided i wanted to muck with it, so i copy/pasted the patch from the tutorial and put it into my own sub-patcher.
In the original patch, hitting "startwindow" does what it's supposed to. i hear the sounds, i can manipulate it in the octophonic space the way i need to.
In the patch i copy/pasted, i get signal out of sfplay~, but once it hits the meters after the ambiencode/ambidecode, there's nada, and no sound comes out.
After poking around and not finding any differences between the original and the copy/pasted version, i decided to see if "resetting" the objects would work, so i clicked in the ambiencode object, deleted the 4 and retyped it. I did the same thing with the ambidecode, except i deleted the 8 and then retyped it.
That did the trick, as hitting startwindow then produced sound - albeit at a higher gain and with a slightly distorted level for no reason i could determine.
Then i discovered that this happened every time i closed the patch and reopened it - as in, if i ever close the patch and have to reopen it, i have to "reset" those objects every time. This doesn't happen when i open up the original example patch. no error appears in the max window.
The ICST folder currently exists in my packages folder.
What am i missing here?
Thanks for your help!
Do you see the four sound sources in the ambimonitor when you load the copied patch? What you are experiencing - from your description - is reasonably consistent with the likelihood that when copying the patch you didn't copy the message (and/or or load bang) to the Ambimonitor which initialises the 4 sources and sets their initial values. (this message +loadbang is in the upper left corner, only visible when the patch is unlocked). Although, it doesn't really explain why reinstating the ambience/decode objects re-estabishes the sound...
The four sound sources are indeed in the ambimonitor. I took the loadbang stuff and made those visible when i was first mucking about to figure out how it worked, so it's definitely copied over.
That ended up being half of the issue which i realized very late last night - when i "reset" the objects, the ambimonitor values aren't "loadbanged" into the new reset objects, so i assume that all of the sounds loaded were playing from the center. rehitting the [aed] message box or moving around the four sound sources resolved that.
That doesn't resolve the issue of ambiencode/ambidecode not working when i first load the patch without a reset. I just tried to see if manually banging the [aed] message triggered something, or moving around the four points will trigger something. Zilch. Only thing that i've done that works so far is resetting those two objects.
Just to be sure that it wasn't a fluke, i deleted the subpatch, found the original patch, copy/pasted it into that same subpatch window. Same problem. I copy/pasted the original patch into a new patcher window to see if maybe there was something else in my project file that could be causing the issue. Same problem.
I tested this with another one of the example patches, 04.Swarm. Copy/pasted the original into a new patcher window, saved it, closed it, reopened it. Same problem, same resolution - have to reset the objects every time the file is opened.
hey all,
for those that might still be interested, i think i figured out the cause of this issue (although i still haven't figured out how to fix it). The inspector values for ambiencode are different in the example patches versus my own.
There are a handful that are, but the ones that stick out that i believe are the cause of the issue are:
ICST example:
db Rolloff per Unit: 0.007813
Distance Attenuation Rolloff: 524288.125
Center Attenuation Rolloff: 0.000031
Center Curve Factor: 8192.001953
Center Zone Size: 0.007813
my patch:
db Rolloff per unit: inf
Distance Attenuation Rolloff: inf
Center Attenuation Rolloff: 0.007812
Center Curve Factor: 0
Center Zone Size: 562661720850432
When i "reset" the object like i articulated above, the values in my patch change to the values that are present in the example patches exactly.
I think the short-term solution is for me to send attribute messages into those objects that match the values from the defaults. Long-term solution i don't have a clue about - not sure how to freeze-store those values if those values weren't supposed to change in the first place.
Interesting. (in a not so good way). FWIW After reading your initial post I tried the same but it worked as expected - copying and pasting is fine etc., (Max 6.1.5 (32 bit) OSX 10.9.2 ICST 2.3 ) And also in neither of the examples you mentioned earlier are the ambiencode attributes the values you describe in either the original example or your copy. Here is what i see:
db Rolloff per Unit: 1.5
Distance Attenuation Rolloff: 1
Center Attenuation Rolloff: 6.
Center Curve Factor: 0.2
Center Zone Size: 1.
As an aside, those attributes (all being in non-itialics) should be stored with the object - which suggest they are most likely getting messed up when duplicating the objects from the original - but you can try freezing them (via the inspector) or expressing them directly in the object as explicit arguments when creating a copy.
There is obviously some reason for what you are experiencing but it is a guess what it may be. Are you perhaps running Max in 64 bit?
not running Max in 64-bit, that's not the issue. i suppose i could update Max (currently 6.1.1 as opposed to 6.1.5) - maybe since the new version of ICST was developed recently, something under the hood could have been adjusted with whatever changes Max had. I'll try that first.
I did try freezing the attributes when i posted the above, but that didn't end up actually freezing the attributes; when i closed the patch and reopened it, the same "wrong" values were stored instead of what i tried to freeze.
And it must run deeper than that, because when i try to change those attributes at all - opening up the inspector, finding that attribute, double-clicking, trying to change the value, as soon as i hit enter, then it reverts back to the original, so those don't seem to be changeable.
Expressing them directly in the object might be the way to go, although the syntax for that isn't something i'm familiar with since i'm only now coming back to Max from a time before Jitter existed. If the update to Max doesn't resolve the issue, i'll poke around and try to figure it out.
follow up:
sending a "gain" attribute through ambiencode solved half of the problem. Ambiencode no longer needs to be reset. In fact, if i change the gain value in the inspector window, even though the value visibly reverts to whatever the previous value was, the actual typed in value sticks.
Ambidecode is a different issue and it's not one that i can interpret to fix it. I felt like the easiest way to document what was happening to me was to record a quick video, so here it is. this is after i had already "reset" the object so i could note the values that had shown up in the attributes and mess with the ones that seemed to matter.
I'm having the exact same problem with the ambiencode/decode resets. Max 6.1.7 (@32), for reference.
In my case, it doesn't seem that the ambi objects even want to reset. I've tried copying & pasting the Control_Parameters patcher from the help files, and editing within them a loadbang to send automatic reset messages to both ambi objects, but that doesn't seem to accomplish anything -- the audio signals still get stuck somewhere in the ambi objects once the "startwindow" message is banged.
Did you ever end up finding a long-term/permanent solution to this problem?
yeah i did, although i still see it as a workaround.
but it sounds like what i did is similar to what you tried already but failed. Basically what i did was patch two receive objects to ambiencode and ambidecode and then i sent certain parameters to them in a message box using loadbang.
in other words:
[r AEAttribs] --> [ambienconde~ 3 8]
[r ADAttribs] --> [ambdecode~ 3 8]
[loadbang] --> (message box) [; AEAttribs gain 0.75; ADAttribs gain 0.75; ADAttribs defaultweights]
Those attribs were ones that i discovered seemed to cause the issue after doing a bunch of trial and error with all of the parameters for those objects.
also, even though these loaded properly and thus allowed sound to come out in the right way, if you look at the attributes of ambiencode/decode, those specific parameters do *not* reflect the change that i made with the message box. The gain on both will still say 0 even though it's clear that they're at 0.75.
Great, thanks! Just implemented it using just those specific parameters and it works just fine (for a work-around).
Just curious -- how did you narrow it down to those parameters as the problematic attributes? This had me stumped for a chunk of time...
Thanks again!
i 'reset' the object so that sound would come out and then wrote down all of the parameters. then i closed my patch and reopened it (so the parameters would be "broken") and tried changing the parameters one at a time to isolate which parameters would make it work.
"defaultweights" is something i didn't know existed at first - i tried to change the weight numbers individually and didn't have much luck, then when i was randomly looking at the help file for that object for something else i saw that defaultweights was an option, and that was the last piece of the puzzle.
it took me a few days of several hours to figure out. i didn't spend all of that time exclusively on the issue, but i did spend a majority of time on it because it was bothering the crap out of me.
and my pleasure. :)