Subpatcher in Max5 refuses to send out audio signal

May 17, 2008 at 7:42am

Subpatcher in Max5 refuses to send out audio signal

I’m having some trouble which may be a Max5 bug. I’m working on a patch and one of my subpatches refuses to send out an audio signal. When I attach a dac to the last object in the subpatch, I get a signal but for some reason, when I attach one to the subpatch outlet attached to that last object, I get nothing. It’ll probably work if I take the time to rebuild the subpatch but I’d be interested to know if anyone else has had this problem.

#37842
May 17, 2008 at 4:41pm

I have just started experiencing the same problem.
when I connect the last patcher with a signal it kills the audio. attaching a meter~ to a groove~ object in the patch reports a signal but nothing is coming out of the dac.

#130961
May 17, 2008 at 4:56pm

I just cut the contents of my subpatch into a new subpatch and I’m still having the same problem. One of the weird things is that, if I close the subpatch and re-open it, some of the audio connections have inexplicably turned into message connections. Could I possibly be doing something to cause this or is it a bug in Max 5?

I’ll try rebuilding the whole subpatch next.

#130962
May 17, 2008 at 5:10pm

On 17 mai 08, at 18:56, Sam Macklin wrote:

> I just cut the contents of my subpatch into a new subpatch and I’m
> still having the same problem. One of the weird things is that, if I
> close the subpatch and re-open it, some of the audio connections
> have inexplicably turned into message connections. Could I possibly
> be doing something to cause this or is it a bug in Max 5?
>
> I’ll try rebuilding the whole subpatch next.

Could you just paste (use the Copy compressed function of the Edit
menu) a patch? I can’t reproduce something like that at all. Adding
some extra information like platform, OS version, computer type…
would also be appreciated.

Thanks,
ej

#130963
May 17, 2008 at 5:10pm

Perhaps one of you should post a patch that isn’t working.

-C

#130964
May 18, 2008 at 1:15am

Well I’m less than thrilled about the idea of posting my hack work on the forum but if there’s something super obvious in here that is preventing the outputs from sending audio, I guess I should be told to my stupid hacky face. So I’m posting the problem subpatch.

Not sure what this simple distortion unit would work sound like if I could get it to output any audio but here it is, for what it’s worth.

Not sure this will do any good. While this is the main subpatch I’ve been having problems with, the behavior has not been consistent (making it extra hard for anyone else to replicate). Signals are disappearing and audio cables are turning into message cables all over the place.

Oh and I’m using Max 5.0.2 on a 12″ PowerBook G4 with a 1.5GHz CPU and 1.25 GB of RAM, running OS 10.4.11.

#130965
May 18, 2008 at 1:45am

#130966
May 18, 2008 at 1:58am

Hmm… I think my problem might be caused by trying to have a overdrive object feed back into itself. When I remove the (bypassed) *` objects from the patch, the (clean) signal kicks back in. I guess you can’t do that with overdrive in Max. Right?

#130967
May 18, 2008 at 3:12am

yes, it’s the overdrive feedback loop. insert a send/receive~ pair. they will introduce a one vector delay and break the loop.

#130968
May 18, 2008 at 3:17am

You can’t do it with any MSP object without a vector worth of delay.

Use send~ and receive~ or a tap.

bt

On May 17, 2008, at 6:58 PM, Sam Macklin wrote:

>
> Hmm… I think my problem might be caused by trying to have a
> overdrive object feed back into itself. When I remove the (bypassed)
> *` objects from the patch, the (clean) signal kicks back in. I guess
> you can’t do that with overdrive in Max. Right?

#130969
May 18, 2008 at 3:23am

Yes, and it’s not because of the [overdrive~] object. As soon as you have a
feedback loop in a MSP network, it cannot be computed.
In a subpatch, use something like:

send~ #0-foo
receive~ #0-foo

That way, the #0 will be different for each instance.
J-F.

>
> yes, it’s the overdrive feedback loop. insert a send/receive~ pair. they will
> introduce a one vector delay and break the loop.

#130970
May 19, 2008 at 4:42am

Yes that works. Thanks for your help, everyone. And thanks for not laughing at my cluelessness.

#130971
May 19, 2008 at 10:25am

Sam Macklin schrieb:
> Yes that works. Thanks for your help, everyone. And thanks for not
> laughing at my cluelessness.

This sort of patching error is hard to grab yourself. I would like to
see an error message if there is a feedback detected. That would give
you actually a clue. There is nothing to blame you, that’s why we all
need the community to slowly build experience, and in the future we
probably will have an error message, don’t know when though…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#130972
May 19, 2008 at 10:27am

Sam Macklin schrieb:
> Yes that works. Thanks for your help, everyone. And thanks for not
> laughing at my cluelessness.

This sort of patching error is hard to grab yourself. I would like to
see an error message if there is a feedback detected. That would give
you actually a clue. There is nothing to blame you, that’s why we all
need the community to slowly build experience, and in the future we
probably will have an error message, don’t know when though…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#130973

You must be logged in to reply to this topic.