Like [send~] and [receive~]?

a little bit, but without the send and receive part ;)

Do you mean something like this?

holy shit balls with taco flavoured cat droppings. i never knew, but never thought it would work since they are max objects.

muchos thankos to you-os

…which goes to show that you can do some surprising things with mixing and matching Max and MSP objects. MSP patch cords are just normal Max patch cords passing a special kind of Max message. You can do most normal Max stuff with them.

The classic example is in subpatches: inlet and outlet objects are standard Max objects. You can connect signals, and they basically work. There are some anomalies, though (patch cords don't always go stripey when you might expect). Using plain-vanilla send/receive objects with MSP signals is another trick that's pretty well-known.

Caveat: mixing Max and MSP objects can have some unexpected results (depending on what you expect). But they often do work just fine.

thank you for your insight and words of wonder. this just makes me feel like i need to start from the beginning ;)

Yeah , it works, but it's unsupported. At some point in the future we may change the way Max works behind the scenes and this sort of thing will stop working. If "some point in the future" isn't on your radar, go for it.

-A

arrrgh, cock beans. please dont do that. or if you do. could be be replaced by something that is supported?

l

also [prepend signal] doesn't support feedback loops. same goes for [send/receive signal] as far as i know.

see here https://cycling74.com/forums/prepend-signal and here https://cycling74.com/forums/feature-request-multiple-signals-on-one-signal-cable

@Lewis: could you give us an example of what you're trying to do with prepend and route? I suspect there may be another way of approaching what you're trying to do that may be more idiomatic MSP.

The point I was trying to make is that you shouldn't assume Max objects won't process MSP signals… but (and it's a very big but) it's important to understand how the two worlds interact. (Kthozoid's warnings are part of that 'understanding').

And, if you're doing something that is explicitly "not supported" to take into account that Cycling '74 may break what you're doing in the future. Cycling '74 has been very good about not breaking existing supported (ie documented, "official") behavior. But unsupported stuff can go.

@Andrew: I read (present tense, in the sense of 'understand') your comment about my example patch possibly breaking in the future. Would you be able to say a word about why, though? The prepend/route thing is basically only using the fact that MSP objects communicate with the Max world (and each) other by using a very few special reserved messages. It would seem that changing that would mean a gigantic change in the whole interaction between Max and MSP, as well as breaking the inlet/outlet and plain-vanilla send/receive communication. When I wrote the patch, I thought what I was trying was harmless. Or, at worst, 'mostly harmless'.

to further illustrate the point Peter was making about the MSP-ableness of Max objects

Hello, This is magic ! Thanks.

ooooh, youre just spoiling me now. utterly brilliant

@Peter

Yeah, this sort of patching can exist because currently the signal compiler works by sending max signal messages around a patcher. However it's not something which was designed as a feature to be used in programming max patchers.It's something which people have figured out and are taking advantage of. It breaks in Max 6 with send and receive across patcher hierarchies and it may get broken in other ways down the line.

We do recognise that people like to patch this way. The example of an abstraction which can receive both messages and audio in the same inlet is really compelling. That's a separate issue from the way the signal compiler works.

-A

there is indeed an issue when using [prepend foo] with signals ... connections of this type are gone when they change ... which happens with gate, switch, forward, or with scripting.

in some of my "multicore" abstractions (such as a gate for up to 10 signals which are merged into one connection) i am using an additional send as notifer to the [dac~] in the mother patch, which makes it restart the audio by "0, 1", so whenever you switch the gate from outputs 1 (destination channels 1-10) to output 2 (destinations 11-20), the symbolic connection is found again because of the restart.

for bigger systems it might even be worth to put the whole multicore DSP into a [poly~], because restarting the DSP is not exactly the safest thing.

-110

"also [prepend signal] doesn't support feedback loops. same goes for [send/receive signal] as far as i know."

for the send/receive situation try implementing 2 (instead of the usual 1) vectors delay in the loop . ;)

and for the [prepend foo] situation you can just make a custom abstraction which takes the connection and breaks it up into multiple signals inside in order to be able to insert the vector delay. this of course only works when the number of signals in the "foo" connection is known.

-110

a variation on the theme, using funnel and route.