Forums > MaxMSP

How to create mixed inlets (i.e. accepting both signals and data) in a subpatch?

July 30, 2013 | 4:38 am

Hi,

I’d like to have a subpatch with an inlet that accepts both signals and data. The reason is that the patch has too many inlets, so I’d like to minimize them by grouping incoming information. However, I can’t figure out how to separate the incoming signal from the non-signal data arriving on the same inlet (the task is pretty straightforward in C, so I assume there must be an object that would do this separation).

Currently, I use a combination of [route signal] and [prepend signal] which, although works as expected, prints a warning in the Max window each time I turn the DSP on or off, making this solution unsuitable for production purposes:

Main patch:

– Pasted Max Patch, click to expand. –

[subpatch]:

– Pasted Max Patch, click to expand. –

Is there any better solution?

Thanks,
Ádám


July 30, 2013 | 4:59 am

Try [trigger signal] instead of [prepend signal]. Works for me.
<code>

– Pasted Max Patch, click to expand. –

</code>


July 30, 2013 | 5:05 am

Works indeed. Thanks!


July 30, 2013 | 7:02 am

I think you though about this thing when coming up with [prepend]

<code>

– Pasted Max Patch, click to expand. –

</code>

We know that this is or at least was considered a bug by cycling so I’m not sure if I would want to rely on what’s going on in christphers patch. Or should I? I’d really love this feature. What do you think, is this something different?

Are there any official statements about this?

Once more "mulitcores" or audio signal busses carriing multiple signals and or max messages would be a great feature! Hope this is coming sometime.


July 30, 2013 | 7:55 am

@woyteg, this is simpler:

<code>

– Pasted Max Patch, click to expand. –

</code>

It isn’t a bug, so much as an unanticipated use of the messaging that builds the signal chain. I wouldn’t expect any support from Cycling for this use case, but the underlying mechanism is deeply integrated into MSP, and is unlikely to change soon.


July 30, 2013 | 8:03 am

thanks, already building a multiplexing abstraction :)
.. I wouldn’t consider it a bug too, as far as I remember it was called a bug, and that was the only oficial thing that was said about it. Also that it *could* be changed. But maybe I dreamed all that, I don’t know.


July 30, 2013 | 8:50 am

demux abstraction:
<code>

– Pasted Max Patch, click to expand. –

</code>

mux abstr.

<code>

– Pasted Max Patch, click to expand. –

</code>

cheers


July 30, 2013 | 1:28 pm

I’ll add this here,

<code>

– Pasted Max Patch, click to expand. –

</code>


July 30, 2013 | 2:52 pm

Is there any kind of overhead added with these methods like with send~/receive~?

I’d personally sooner avoid it as it’s so tidy I’d do everything that way, and if it became deprecated that would be a maintenance nightmare.


July 31, 2013 | 3:35 am

i have been using these methods constantly and everywhere in max for the last ten years, so i am dreading the day cycling74 discontinue the ability to do it. (also for no-tilde s/r’s for zero-ish delay feedback loops, although this one not important anymore as we have gen~). but inputs/outputs mixing is essential. in max6 i have been using routepass, which makes it even simpler. we have been told definitely by cycling74 that these methods will likely no longer be supported at some point in the future. maybe mzed is more confidently aware of just when this will be? if it is dropped for jamoma style multichannel audio cables i will be happy. rough with smooth as they say. e.g. max6 saw major poly~ s/r~ etc features unceremoniously dropped, because of multicore improvements and so on. and begin~, mute~, pass~ anyone? still looking for better replacement than poly~ here.


July 31, 2013 | 3:41 am

(OT : what was dropped with poly~ s~/r~ again ?)


July 31, 2013 | 3:54 am

used to be able to send and receive signals with s and r (as well as send~ and receive~); now you can’t. don’t know what is being referred to about the poly~


July 31, 2013 | 1:25 pm

I guess this feature is what Stephen J. Gould might call a "spandrel":

http://en.wikipedia.org/wiki/Spandrel_(biology)

maybe mzed is more confidently aware of just when this will be?

I have no special knowledge about this. I’m just observing that MSP has worked this way from the beginning, and it would take a major re-engineering effort to make it work otherwise.

One thing to remember, these audio connections are only formed when the signal chain is (re)built. They don’t work well with scripting or patching while audio is on.


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