$Adam

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

 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:

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:

how-to-create-mixed-inlets-i-e-accepting-both-signals-and-data-in-a-subpatch

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

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

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.

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.

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.


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.

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.


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.

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.

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

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~

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.

I guess this feature is what Stephen J. Gould might call a "spandrel":
http://en.wikipedia.org/wiki/Spandrel_(biology)

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.


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