Stefan Tiedje

signal-outlet-connected-to-nonsignal-inlet-out

> it was a big patch, but I remember that message coming up after I

> changed send~ and receive~ to send and receive. Hope that helps

Thanks for the hint, I don't know if its the case, but something to 

keith manlove wrote:
> it was a big patch, but I remember that message coming up after I
> changed send~ and receive~ to send and receive.  Hope that helps

Thanks for the hint, I don't know if its the case, but something to 
watch out for...

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


> I would never use [send] and [receive] for audio ever again. It's

> not hard to reproduce the errors - use sends and receives in a

> patch, send some audio, change the receive names (via the "set XXX"

> message), and blammo: signals will not be received at all, or the

> wrong ones will be received, or you will get these errors.

Yes, as its a non signal object, the signal chain can't know that

something has changed. The nontilde s/r connections are like normal 

patchchords. Such a rewiring would need a recompilation of the signal 

chain which means it would always need a restart of audio...

evan.raskob [lists] wrote:
> I would never use [send]  and [receive] for audio ever again.  It's
> not hard to reproduce the  errors - use sends and receives in a
> patch, send some audio, change  the receive names (via the "set XXX"
> message), and blammo: signals  will not be received at all, or the
> wrong ones will be received, or  you will get these errors.

Yes, as its a non signal object, the signal chain can't know that
something has changed. The nontilde s/r connections are like normal 
patchchords. Such a rewiring would need a recompilation of the signal 
chain which means it would always need a restart of audio...
(aka expected behaviour...)

your explanation makes sense, but i'd hardly call it expected 

behavior. if something is receiving a signal, it should know when 

that signal input has changed and act accordingly. if it can't, then 

you can never be sure that you are receiving correct signal data when 

you add/remove patch cords and signal cords and change send/receives 

(all common tasks). which is what i have seen so far. i'm guessing 

that this is why this feature is not documented, AFAIK. it appears 

On Jan 15, 2007, at 4:28 PM, Stefan Tiedje wrote:

>> I would never use [send] and [receive] for audio ever again. It's

>> not hard to reproduce the errors - use sends and receives in a

>> patch, send some audio, change the receive names (via the "set XXX"

>> message), and blammo: signals will not be received at all, or the

>> wrong ones will be received, or you will get these errors.

> Yes, as its a non signal object, the signal chain can't know that

> something has changed. The nontilde s/r connections are like normal 

> patchchords. Such a rewiring would need a recompilation of the 

> signal chain which means it would always need a restart of audio...

your explanation makes sense, but i'd hardly call it expected  
behavior.  if something is receiving a signal, it should know when  
that signal input has changed and act accordingly.  if it can't, then  
you can never be sure that you are receiving correct signal data when  
you add/remove patch cords and signal cords and change send/receives  
(all common tasks).  which is what i have seen so far.  i'm guessing  
that this is why this feature is not documented, AFAIK.  it appears  
to be use-at-your-own-risk.

> evan.raskob [lists] wrote:
>> I would never use [send]  and [receive] for audio ever again.  It's
>> not hard to reproduce the  errors - use sends and receives in a
>> patch, send some audio, change  the receive names (via the "set XXX"
>> message), and blammo: signals  will not be received at all, or the
>> wrong ones will be received, or  you will get these errors.
>
> Yes, as its a non signal object, the signal chain can't know that
> something has changed. The nontilde s/r connections are like normal  
> patchchords. Such a rewiring would need a recompilation of the  
> signal chain which means it would always need a restart of audio...
> (aka expected behaviour...)
>
> Stefan
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>


A long time ago DDZ indicated that the fact that plain-vanilla s/r 

pass signals was something of an unintended accident. A rather 

Apparently what didn't happen with the accidental success of plain- 

vanilla s/r is notification to rebuild the DSP chain when patch cords 

are edited. That can obviously cause confusion for the user. So use 

with due caution. But s/r for signals is eminently usable.

On 15-Jan-2007, at 19:17, evan.raskob [lists] wrote:

> your explanation makes sense, but i'd hardly call it expected 

> behavior. if something is receiving a signal, it should know when 

> that signal input has changed and act accordingly. if it can't, 

> then you can never be sure that you are receiving correct signal 

> data when you add/remove patch cords and signal cords and change 

> send/receives (all common tasks). which is what i have seen so 

> far. i'm guessing that this is why this feature is not documented, 

> AFAIK. it appears to be use-at-your-own-risk.

Oh, it's documented well enough. "The send and receive objects allow 

you to send any kind of message between Patcher windows or within a 

window without using patch cords." The .help file doesn't say "any 

kind of message except for audio or video." It says "any kind of 

To paraphrase someone more charming than myself, what word in "any" 

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

A long time ago DDZ indicated that the fact that plain-vanilla s/r  
pass signals was something of an unintended accident. A rather  
fortuitous accident, if I may say so.

Apparently what didn't happen with the accidental success of plain- 
vanilla s/r is notification to rebuild the DSP chain when patch cords  
are edited. That can obviously cause confusion for the user. So use  
with due caution. But s/r for  signals is eminently usable.

> your explanation makes sense, but i'd hardly call it expected  
> behavior.  if something is receiving a signal, it should know when  
> that signal input has changed and act accordingly.  if it can't,  
> then you can never be sure that you are receiving correct signal  
> data when you add/remove patch cords and signal cords and change  
> send/receives (all common tasks).  which is what i have seen so  
> far.  i'm guessing that this is why this feature is not documented,  
> AFAIK.  it appears to be use-at-your-own-risk.

Oh, it's documented well enough. "The send and receive objects allow  
you to send any kind of message between Patcher windows or within a  
window without using patch cords." The .help file doesn't say "any  
kind of message except for audio or video." It says "any kind of  
message."

To paraphrase someone more charming than myself, what word in "any"  
is ambiguous?-)

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

On 15-Jan-2007, at 23:06, evan.raskob [lists] wrote:

> is signal data a "message"? oh not we're back to this discussion 

For folks tuning in late: at one technical level, it is. This is not 

apparent to users, but if you program external objects in C you see 

> is signal data a "message"?  oh not we're back to this discussion  
> again ;)

For folks tuning in late: at one technical level, it is. This is not  
apparent to users, but if you program external objects in C you see  
this is part of the MSP magic.

> i'm guessing that this is why this feature is not documented, AFAIK.

correct... Its not ment for newbies, would create too much traffic on 

It's actually an expectable and reliable side effect of the way MSP 

objects communicate. Thats also why you can send signals through a route 

evan.raskob [lists] wrote:
> i'm guessing  that this is why this feature is not documented, AFAIK.
> it appears  to be use-at-your-own-risk.

correct... Its not ment for newbies, would create too much traffic on 
the list... ;-)
It's actually an expectable and reliable side effect of the way MSP 
objects communicate. Thats also why you can send signals through a route 
object without any problems...

signal outlet (*~) connected to nonsignal inlet (out~)