On 9 Oct 2009, at 16:03, IOhannes m zmölnig wrote:

Jamie Bullock wrote:

...

Hi all,

Has anyone implemented this with externals, or a Pd dynamic
patching hack?

s~/r~ are one-to-many settable on the receive side. throw~/catch~ are many-to-one settable on the send side.

What about a sendbus~/receivebus~ many-to-many settable on both
sides?

for buses i usually use a [catchsend~] abstraction, that looks like:

[catch~ $1] | [send $1]

this has to be created once for every bus you use. you could use a singleton approach to automatically create it in your [sendbus~]/[receivebus~] abstractions.

I just had a little play around with this, and it works fine for a
bus, but I guess I'm looking for something that behaves *exactly* like
patching with patch chords, which isn't quite as simple as a bus
architecture.

For example, the above solution works for 1-n, n-1 and n-n, but
doesn't provide exclusive 1-1. I.e. if I have an existing bus with 1- n, I can't connect output 1 of n to input 2 of n without the signal
going to all of the other outputs on the bus as well.

To solve my problem I could just forget s~/r~/throw~/catch~ and make
connections, through scripting with 'connect' messages, but then I
can't easily script 'disconnect'.

Alternatively I could use dyn~, which does everything I need, but
relies on a bunch of non-public headers and APis which could change at
any time.

Any other thoughts?

Jamie

2009/10/12 zmoelnig@iem.at:

Quoting "Jamie Bullock" jamie@postlude.co.uk:

...

but then I can't easily script 'disconnect'.

why not?

Yo, I had a similar complete unawareness of the [disconnect( message long ago when I was designing a bunch of dynamic audio routing stuff that caused me to architect things far less elegantly than necessary : ).

I tried to think of why this is so, and I think it's because it doesn't really get covered in the "pd-msg" tutorial that remains, I believe, the primary documentation on the matter (though it is listed in the reference 0.all_msg.pd so I can't excuse myself too strongly).

I'm thinking I'll add a 7.disconnect.pd entry covering it to make sure it is burned in early?

That also made me notice that the 3.Networking/ OSC tutorials all suggest using OSCx, perhaps explaining the recurring inquiries about the usage of OSCx on the list. Anyone mind if I switch them out in there to use Mr. Peach's stuff?

Best Luke

fgasdr IOhannes

---

This message was sent using IMP, the Internet Messaging Program.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list