Strange (or maybe not) audio out "bug" (?) in Max6 (08 & 1) - output "blows up"
What does it mean when -
a patch is running, audio (as indicated by meter~s) is coming into the patch, being processed by modules (meter~s in the modules), arriving at the receive~ objects just before the output faders (meter~s attached to the receive~ objects), and yet when I attach them to the output faders, nothing comes out.
A bit more...
The patch (actually this occurs with several different patches - but all with similar patcher modules in them) will run along fine for a while, then there'll suddenly be a huge splat, and the audio output disappears. Turning audio off and on again just produces another huge splat (though audio is still running in the patch, according to all the meter~s). The only solution is to quit and restart max.
I've tried removing several of the modules, thinking that perhaps it's a problem with a vst~ plugin, or biquad blowing up, but I still get the random blowup after 5-10 minutes. I haven't taken out the main processing modules (otherwise nothing to test!) which contain elasticx~, but then they still seem to be working when the audio blows up, so...
[edit - I just ran everything again, with number~s in parallel with the output faders, and when things blow up I can see [nan] there (which is what i expected). I'll add more number~s working backwards to see if I can narrow down where it's coming from, but any input as to what could cause this would still be appreciated!]
I'm now at a loss as to what to try next. Any ideas?
(This has only started occurring since I moved to Max6. And this is on a retina macbook pro, with latest OS and latest maxmsp etc etc)
thanks
Hi
bear in mind that [meter~] will expose any signal, not necessarily the one you want; that could just be noise. This has happened to me once or twice in the distant pass and usually involved an "illegal" operation on a signal causing either infinite feedback or other source of noise; I would suspect, as you, either [biquad~] or the plugin.
Sorry not to be more help
Brendan
Hmm. I've eliminated the vst~ and biquad~ objects on the output, and it's still blowing up - only now the audio seems to "reset" itself after a short while and start working again. I thought that once the audio had blown up it stayed that way (or is that how it used to be several versions ago, but not now?)
And I'm still only getting "nan" showing up right at the output faders and not before. I'm really curious to know what the heck that means.
is there something like [dcblocker~] that I could put in the various audio chain that would block "nan"s? (Or does that show a complete lack of understanding (true) of what nan means in an audio chain?
Enlightenment sought!
Not a number, the source of which could be "anything". Division by zero is a common culprit. I'm assuming of course that nan means the same in both control and signal domains.
I knew the meaning :-) but I guess the question is, is, is it local or global - ie my assumption would be that, as the rest of the patch appears to be functioning, that the nan is right around the output faders, as all 4 stereo audios feeding into it are _not displaying nan on the meter~s attached to them. That's one thing I don't understand. And if the problem is elsewhere in the overall patch, and it's not propagating through the audio connections, how the heck do I track it down!
Or, as you say the source of a nan could be anything, does that mean that a nan in one part of the patch could provoke the output to blow without affecting anything in between? (action at a distance!!)
Well, it turns out to be something (apparently) to do with elasticindex~ when it ends play (and which usually clears the next time it starts play again). Strangely, not all of the 4 instances do this - it was originally #4 stopping that coincided with the blow up, and since I did a bit of tweaking, it's now instance #1. I tried substituting index~, and the patch worked without blowing up.
As far as I'm aware , elastic~ is the smoothest time stretcher/repitcher there is, so I guess I'll see if there's anything i can do around the end of play to squash this.
Later...
the problem was caused by running the line driving e;astocindex~ all the wy to the end of the buffer (is that an obvious thing not to do?). Stopping a few ms short seems to have solved the problem.
I gave up on elasticindex a long time ago (lack of support), switched to IRCAM SuperVP....works very well.
Same here dhj, timo's grainstretch is also much smoother and cleaner. Sounding.
Brendan
@DHJ Presumably you have to subscribe to get ahold of the IRCAM object?
@noob_meister are you referring to the same object, or is that a different one? (link?)
ok - found them both. SuperVP is a premium member thing or %50 euros, which I can't really afford right now (though having look at the SVP page I have to say I'm sorely tempted to spring for that), so I guess I'll try out timo's object.
Thanks for the headsups.
Hi
glad you found it
I realise this is drifting slightly off topic, but IIRC, this external allows sample-accurate, real-time modulation of the common grain-stretching, freezing and re-pitching parameters, and could easily be modified to allow for a live audio buffer. It's (qualitatively, at least) the best sounding freezer/re-pitcher I've encountered, but it's sadly not possible to open it up for learning, hacking, re-purposing. If you want to do that, try any one of the multitude of grain engines out there. Or DIY :)
f.e.
main:
sub: (save as: subGen)
requires gen~
Brendan
Nice! That's actually pretty smooth. grainstretch is good too, though it's a drag that it loops constantly. Now I'm spoilt for choice (actually, having differently granulators, with different sounds and artefacts, is quite a useful thing in itself.)
I'm still thinking about SuperVP though - it looks like I could do quite a few other interesting sound transformations with that set.
Thanks Brendan