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

Jul 30, 2013 at 4:38am

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

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

#257585
Jul 30, 2013 at 4:59am

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

– Pasted Max Patch, click to expand. –

</code>

#257587
Jul 30, 2013 at 5:05am

Works indeed. Thanks!

#257588
Jul 30, 2013 at 7:02am

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.

#257594
Jul 30, 2013 at 7:55am

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

#257597
Jul 30, 2013 at 8:03am

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.

#257598
Jul 30, 2013 at 8:50am

demux abstraction:
<code>

– Pasted Max Patch, click to expand. –

</code>

mux abstr.

<code>

– Pasted Max Patch, click to expand. –

</code>

cheers

#257605
Jul 30, 2013 at 1:28pm

I’ll add this here,

<code>

– Pasted Max Patch, click to expand. –

</code>

#257625
Jul 30, 2013 at 2:52pm

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.

#257630
Jul 31, 2013 at 3:35am

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.

#257656
Jul 31, 2013 at 3:41am

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

#257657
Jul 31, 2013 at 3:54am

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~

#257658
Jul 31, 2013 at 1:25pm

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.

#257720

You must be logged in to reply to this topic.