a "i wish this existed for the greater good of patching signals" object

May 15, 2012 at 11:27am

a "i wish this existed for the greater good of patching signals" object

hello again,

this is more just needing to spooge out my ideas for an object, whether possible is another matter. but feel i need to share with the developers/public and the like to see if this could be done.

i use signals quite a lot, also things like normal data passing and handling. but the one problem with signal data is that it can get very BIIIIG, even with bpatchers and well thought out patches.
the 2 things that have a leg over the msp of max are [prepend] and [route], these 2 have made patching more elegant and looks good, rather than tons of inputs and outputs on abstractions and [patchers], theyre great, we all love them.

my one sole request that i could have and not ask for any other new externals forever would be a [prepend~] and [route~]. so things like HUGE bpatcher inputs and outputs could be a thing of the past.
think that you could just name your signal with a [prepend~] connect into your bpatcher, then you could [route~] that signal to where it needs to go.
the implications to your patches would free up so much landscape and you can see clearly what is plugged to what. patches would look slicker and should work quicker.

anyhow… phew. thats my spooging finished with. i just need to mop up now.

lewis edwards
——
smokingbunny.co.uk

#63603
May 15, 2012 at 12:25pm

Like [send~] and [receive~]?

#229250
May 15, 2012 at 12:26pm

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

#229251
May 15, 2012 at 1:24pm

Do you mean something like this?

– Pasted Max Patch, click to expand. –
#229252
May 15, 2012 at 1:33pm

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

#229253
May 15, 2012 at 1:58pm

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

#229254
May 15, 2012 at 1:59pm

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

#229255
May 15, 2012 at 2:22pm

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

#229256
May 15, 2012 at 2:27pm

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

l

#229257
May 16, 2012 at 6:54am

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

see here
http://cycling74.com/forums/topic.php?id=32474
and here

http://cycling74.com/forums/topic.php?id=7577

#229258
May 16, 2012 at 3:48pm

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

#229259
May 16, 2012 at 4:32pm

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

– Pasted Max Patch, click to expand. –
#229260
May 16, 2012 at 6:03pm

Hello,
This is magic ! Thanks.

#229261
May 16, 2012 at 7:09pm

ooooh, youre just spoiling me now. utterly brilliant

#229262
May 17, 2012 at 3:23am

@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

#229263
May 17, 2012 at 11:00am

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

#229264
May 17, 2012 at 11:18am

“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

#229265
Jun 16, 2012 at 10:17am

a variation on the theme, using funnel and route.

– Pasted Max Patch, click to expand. –
#229266

You must be logged in to reply to this topic.