strange cord behaviour

Nov 5, 2007 at 2:14am

strange cord behaviour

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

#34460
Nov 5, 2007 at 2:17am

FunnyZen,

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

Zachary

#116326
Nov 5, 2007 at 2:45am

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

#116327
Nov 5, 2007 at 8:10am

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

#116328
Nov 5, 2007 at 5:33pm

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?

#116329
Nov 5, 2007 at 6:59pm

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

#116330
Nov 5, 2007 at 10:42pm

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

#116331
Nov 6, 2007 at 12:57pm

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

#116332
Nov 6, 2007 at 2:28pm

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

#116333
Nov 6, 2007 at 2:41pm

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

#116334
Nov 6, 2007 at 5:18pm

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

#116335
Nov 6, 2007 at 5:59pm

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

#116336
Nov 7, 2007 at 6:06pm

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

#116337

You must be logged in to reply to this topic.