FunnyZen

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?

strange-cord-behaviour

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 

https://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.

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 https://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!

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.

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?

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?


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.

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.

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, 

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 

> 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.

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

https://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!

Dear list, I also followed Dudas recent phase vocoder tutorial. 
https://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!  

> 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,

At the same time available was tapin~/tapout~ with a delay set to zero. 

What's your problem with send~/receive~ ?

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

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.

Quote: Stefan Tiedje wrote on Tue, 06 November 2007 15:28

> > 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,

> At the same time available was tapin~/tapout~ with a delay set to zero. 

> What's your problem with send~/receive~ ?

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.

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?

@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.

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?

> 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 - 

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

t=msg&goto=107051&rid=0&S=fb7ca98dd5732ae37cae8053572a48ff&srch=send% 

> 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.

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

> 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?

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...

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...

strange cord behaviour