Forums > MaxMSP

strange cord behaviour

November 5, 2007 | 2:14 am

Hi all,

trying to find why a patch of mine was not working, I realized that it was because I used cords! Without changing anything else in the patch, when I used cords between 2 specific objects it didn’t work while when I used send/receive it worked. Is there any reason for this?

FunnyZen


November 5, 2007 | 2:17 am

FunnyZen,

Post a patch here and we’ll try it out.

Zachary


November 5, 2007 | 2:45 am

Actually it’s a phase vocoder I made based in the patches from ‘The Phase Vocoder – Part II’ tutorial by Richard Dudas and Cort Lippe, you can get the patches here http://www.cycling74.com/story/2007/7/2/112051/0719

The patch where the problem happens is the pvoc_trans_cart_sub.pat
Just replace the send/receive objects with cords, save it and use the parent patch (4-pvoc_trans-cartesian.pat) and it does not work, you get no sound!

In case it is relevant, I used v4.5.5 with updated the fftin/fftout objects, as indicated in the tutorial. Tomorrow I’ll check it on v4.6.3, maybe it’s a fixed bag.

FunnyZen


November 5, 2007 | 8:10 am

These are not send and receive but send~ and receive~. They do something more then simply replacing patch cords. The signal is sent one signal vector later, which can be used to break feed back loops. It is this what happens in mentioned patch.

_
johan


November 5, 2007 | 5:33 pm

It would probably be a Good Idea if the MSP engine would report feedback loops with an "• error:" to the Max (console) window.

Given the number of times people try to build feedback loops and come running to the list with "why don’t my patch work?" some sort of error message might alleviate the apparent confusion.

Or maybe not. If people are capable of building patches with feedback loops, they may also be capable of ignoring error messages in the Max window.

Just an idea. Is anyone from the development team reading?


November 5, 2007 | 6:59 pm

Quote: jvkr wrote on Mon, 05 November 2007 01:10
—————————————————-
> These are not send and receive but send~ and receive~. They do something more then simply replacing patch cords. The signal is sent one signal vector later, which can be used to break feed back loops. It is this what happens in mentioned patch.
>
> _
> johan
—————————————————-

That makes sense now. I know that they are send~/receive~ and not simply send/receive, just yesterday my keyboard went mad and couldn’t write a tilder!! But I thought this behaviour is strange because I read about send~/receive~ in the MSP Reference and nothing is mentioned about this one signal vector delay and I cannot understand why, it is important to know it! Anyway, thanks, everything is clear now.

FunnyZen


November 5, 2007 | 10:42 pm

On 5 nov. 07, at 19:59, FunnyZen wrote:

> That makes sense now. I know that they are send~/receive~ and not
> simply send/receive, just yesterday my keyboard went mad and
> couldn’t write a tilder!! But I thought this behaviour is strange
> because I read about send~/receive~ in the MSP Reference and
> nothing is mentioned about this one signal vector delay and I
> cannot understand why, it is important to know it! Anyway, thanks,
> everything is clear now.

Have a look to the archive. You’ll find a few patches examples which
demonstrate that the signal vector delay is only added when it’s
necessary.

ej


November 6, 2007 | 12:57 pm

Dear list, I also followed Dudas recent phase vocoder tutorial.

http://www.cycling74.com/story/2006/11/2/113327/823

Is there a way to delay the signal by one signal vector other than by using send~ and receive~? I assumed at the time that if there was, then Dudas would have used it!

thanks
Peter


November 6, 2007 | 2:28 pm

Peter Reid schrieb:
> Is there a way to delay the signal by one signal vector other than by
> using send~ and receive~? I assumed at the time that if there was,
> then Dudas would have used it!

At the same time available was tapin~/tapout~ with a delay set to zero.
I doubt that that’s any better…
What’s your problem with send~/receive~ ?

Stefan


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


November 6, 2007 | 2:41 pm

I’ve heard from some users that they think that send/receive or send~/receive~ are a little bit slower than cords, is this true? Seems reasonable to me.

FunnyZen


November 6, 2007 | 5:18 pm

Quote: Stefan Tiedje wrote on Tue, 06 November 2007 15:28
—————————————————-
> Peter Reid schrieb:
> > Is there a way to delay the signal by one signal vector other than by
> > using send~ and receive~? I assumed at the time that if there was,
> > then Dudas would have used it!
>
> At the same time available was tapin~/tapout~ with a delay set to zero.
> I doubt that that’s any better…
> What’s your problem with send~/receive~ ?
>
> Stefan

Using send~ and receive~ is generally a bad idea because they interfere with each other if you want to use multiple instances. This seems so obvious to me that I’m wondering if I missed something. When used within pfft~ is the scope of send~ and receive~ perhaps limited to that pfft~ instance?

thanks in advance if you know the answer.

@FunnyZen: As has been mentioned already in this thread, using send~ and receive~ delays the signal by one signal vector. This is probably what you mean by them being slower than patch cords – which add no delay.

Peter


November 6, 2007 | 5:59 pm

On 6 nov. 07, at 18:18, Peter Reid wrote:

> Using send~ and receive~ is generally a bad idea because they
> interfere with each other if you want to use multiple instances.
> This seems so obvious to me that I’m wondering if I missed
> something. When used within pfft~ is the scope of send~ and
> receive~ perhaps limited to that pfft~ instance?

you could also use the #0 trick.

> thanks in advance if you know the answer.
>
> @FunnyZen: As has been mentioned already in this thread, using
> send~ and receive~ delays the signal by one signal vector. This is
> probably what you mean by them being slower than patch cords –
> which add no delay.

As mentioned, it delays *only* if it’s required.

http://www.cycling74.com/forums/index.php?
t=msg&goto=107051&rid=0&S=fb7ca98dd5732ae37cae8053572a48ff&srch=send%
7E+jourdan#msg_107051

Cheers,
ej


November 7, 2007 | 6:06 pm

FunnyZen schrieb:
> I’ve heard from some users that they think that send/receive or
> send~/receive~ are a little bit slower than cords, is this true?
> Seems reasonable to me.

send/receive is exactly the same as a patch cord. It will lead to the
same underlying code. Whereas send~/receive~ will buffer/copy one signal
vector of audio, which is a bit more, but not much…

Stefan


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


Viewing 13 posts - 1 through 13 (of 13 total)