Forums > MaxMSP

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


January 12, 2007 | 3:53 pm

January 12, 2007 | 9:46 pm

January 15, 2007 | 12:00 pm

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


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

January 15, 2007 | 4:28 pm

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

January 15, 2007 | 6:17 pm

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.

cheers
evan

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

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

January 15, 2007 | 7:25 pm

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.

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

January 15, 2007 | 10:06 pm

January 16, 2007 | 9:35 am

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

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

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

January 16, 2007 | 11:45 am

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…

Stefan


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

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

Forums > MaxMSP