Stephen Powell

Just a general query, and possibly building up to a request to be included in the next update, is the list of related [send] & [receive] objects that pop up when double clicking upon one of them. The [forward] object, when renamed, does not seem to have the function of popping up the menu with related objects, neither is it included in the pop up list from any other related objects. Similarly, [send~] and [receive~] do not have this functionality, and I personally would find it very useful if they and [forward] did.

Does anyone else feel the same on this have any suggestions?

related-objects-with-the-forward-send-and-receive-objects

+1 (particularly the part about making send~ and receive~ consistent, should've been that way from the start, but i worry it'll never change because people have complained about this before... it really does suck.)

________________________________
*Never fear, Noob4Life was never here!*


I was wondering if anyone else was bothered, I didn't find any other entries... I wouldn't have thought it would be a difficult feature to implement, I'm no programming genius but if the [send] and [receive] objects had a piece of code in there that allows each object to list it's related objects, it should be easy to shift to [send~], [receive~] and [forward].

Since send and receive are very different concepts from send~ and receive~ (the former merely being a replacement for a patch chord, the latter an audio bus to which signals can be added and from where they can be tapped) I imagine that the way the application sees them might differ as well. This could be an explanation for why the double click action does not exist with the signal version. As a feature it would be very welcome of course. But you can use send and receive for signals as well.

I didn't know that send and receive could be used for audio signals! Does the behaviour of them / the signals themselves have any functional differences with the msp versions?

This all being said, it's far more the action for the forward object that I would find more useful. I shall hope for it in future releases.

@tsuki: the MSP objects will introduce, if needed, a delay of 1 vector to avoid feedback loops.

I think there is another case where using the Max s/r pair won't work for audio (I don't remember precisely - it was related to the use of #1 and/or poly~ - but I'm quite sure there was some discussion about this on the forum 2/3 years ago, maybe involving dz himself).

I think there is another case where using the Max s/r pair won't work for audio (I don't remember precisely - it was related to the use of #1 and/or poly~ -  but I'm quite sure there was some discussion about this on the forum 2/3 years ago, maybe involving dz himself).

Indeed send/receive do not accept audio signals when receive is within a patcher loaded by a poly~ object.

By the way I totally agree that it's strange not to see forward objets in those popping lists.

Cheers guys. My use of the msp s/r's is primarily within poly~ (for my current project anyway), and the feedback protection sounds like something that is useful to have in place.

Related objects with the [forward], [send~] and [receive~] Objects