manysounds

Can we have a syntax update where we don't have to type out "send~" and "receive~" so we can use "s~" and "r~" like the entire rest of Max? :)

Also, unlike in Gen~ where they'd just be automagically averaged together, it seems we can't have multiple [send~ foo] to the same [receive~ foo] without the compiler barfing. The reverse works just fine, i.e. having multiple [receive~ foo] for a single [send~ foo]. 

Complex multistage phaser patch is messy!

Can we have a syntax update where we don't have to type out "send~" and "receive~" so we can use  "s~" and "r~" like the entire rest of Max? :)
Also, unlike in Gen~ where they'd just be automagically averaged together, it seems we can't have multiple [send~ foo] to the same [receive~ foo] without the compiler barfing. The reverse works just fine, i.e. having multiple [receive~ foo] for a single [send~ foo]. 
Complex multistage phaser patch is messy!

Can we have a syntax update where we don't have to type out "send~" and "receive~" so we can use  "s~" and "r~" like the entire rest of ... 

r~-and-send~

Multiple [send~] to a [receive~] is working, signals are added. See for instance first tab in the [receive~] help file.

Simple patch that is only [in~ 1] to [send~ foo] and [in~ 2] to a separate [send~ foo] with a [receive~ foo] to [out~ 1] fails to compile.

Screenshot 2022-11-19 at 7.41.49 AM.png

It's not working here. v8.5.1
Simple patch that is only [in~ 1] to [send~ foo] and [in~ 2] to a separate [send~ foo] with a [receive~ foo] to [out~ 1] fails to compile.
Codegen Error undefined
Duplicate signal source 'foo' detected.


(^oh, it's specific to RNBO, maybe it's a bug... that doesn't seem right - you could try the 'submit a ticket' link at the top-right on this page: 

(^oh, it's specific to RNBO, maybe it's a bug... that doesn't seem right - you could try the 'submit a ticket' link at the top-right on this page: https://support.cycling74.com/hc/en-us)

Truly want the shortcuts [s~] and [r~] too!

Done.
Boggling this wasn't caught pre-release!
Truly want the shortcuts [s~] and [r~] too!

Make your own objectmappings.txt file and include the lines

I put mine in the "init" folder of a custom package

Make your own objectmappings.txt file and include the lines
max objectfile s~ send~;
max objectfile r~ receive~;

I put mine in the "init" folder of a custom package


Holland, the OP's question is actually different, about the RNBO version of send/receive.

About the OP's question, this is indeed the current behavior in rnbo: different send~ must have different names. Given that two patch cords in rbno~ can be connected to a single object (the signals are summed), I would not be surprised if several send~s can point to a single receive~ in a future version, with automatic summing.

Holland, the OP's question is actually different, about the RNBO version of send/receive.
About the OP's question, this is indeed the current behavior in rnbo: different send~ must have different names. Given that two patch cords in rbno~ can be connected to a single object (the signals are summed), I would not be surprised if several send~s can point to a single receive~ in a future version, with automatic summing.

s~/r~ is now officially in both rnbo and max/msp:

https://cycling74.com/forums/max-8-5-2-rnbo-1-0-2-released

(i think it was thanks to this thread 🙌 ...makes me wonder what else we can get away with requesting: someone submit a support ticket for making the calendar run patches in the future :D)

s~/r~ is now officially in both rnbo and max/msp:
https://cycling74.com/forums/max-8-5-2-rnbo-1-0-2-released 
(i think it was thanks to this thread 🙌 ...makes me wonder what else we can get away with requesting: someone submit a support ticket for making the calendar run patches in the future :D)


Well we already have an M1 compatible version of Max so how about running patches on my iPad? HOW ABOUT THAT SUGGESTION?

Yes it is! 
Well we already have an M1 compatible version of Max so how about running patches on my iPad? HOW ABOUT THAT SUGGESTION?
/heh

Can we compile to AUv3 plugins? That would be the first step...

It turns out the “issue” with AUv3 plugins is they‘ll only appear on channels compatible with the plug-in’s configuration. Drove me crazy until I realized my stereo I/o plugins would only appear on stereo channels.

So, if you make a mono-input stereo output channel plugin it will work on a mono channel. A stereo input AUv3 will only appear (in Logic) on a stereo channel, or a mono channel that has a mono-to-stereo plugin already inserted. To be clear: some other programs ignore this and just split a mono input to both input channels.

The draw back here is you have to compile multiple versions, with different input and output counts. I supppppose that in the future there might be some kind of static-named [param] that could be an auto-report flag thing for making a plugin that was compatible mono or stereo, but that’s just a figment of my imagination.

The way to avoid this is to use code export and JUCE it yourself.

More fitting for my uses, I’d like to be able to flag inputs as “side-chain input (l/r)” some way but I’ll take DSP prototyping without a major hassle for starters.

@TJ 
Yes we can.
It turns out the “issue” with AUv3 plugins is they‘ll only appear on channels compatible with the plug-in’s configuration. Drove me crazy until I realized my stereo I/o plugins would only appear on stereo channels.
So, if you make a mono-input stereo output channel plugin it will work on a mono channel. A stereo input AUv3 will only appear (in Logic) on a stereo channel, or a mono channel that has a mono-to-stereo plugin already inserted. To be clear: some other programs ignore this and just split a mono input to both input channels.
The draw back here is you have to compile multiple versions, with different input and output counts. I supppppose that in the future there might be some kind of static-named [param] that could be an auto-report flag thing for making a plugin that was compatible mono or stereo, but that’s just a figment of my imagination.
The way to avoid this is to use code export and JUCE it yourself.
More fitting for my uses, I’d like to be able to flag inputs as “side-chain input (l/r)” some way but I’ll take DSP prototyping without a major hassle for starters.

r~ and send~