2

I have heard people describe dynamic patching as a bit of a hack or at risk of breaking in future releases of Pd. This is reasonable enough, but it seems to imply that there are alternatives when building abstractions.

Dynamic patching seems to be useful for both instantiating a variable number of objects and connecting up to a variable number (a number defined at creation time - I personally don't need it to change after the fact, at this stage) of inlets and outlets within an abstraction.

Now I understand that the [clone] object can solve the problem of creating objects. I can see too that looping through send and receive objects would solve much of the connection issues with careful planning but what I do not understand is how objects like [trigger], [route] and [select] can be adjusted or replaced in some way? I fail to see how you would avoid using dynamic patching to, for example, create a [trigger f f] when the creation arg to your abstraction is 2, and a [trigger f f f] when the creation arg is 3. Again, the same with [route] and [select] and similar objects.

EDIT: The original question was perceived as too vague. I later posed a follow-up question in the comments which should really be here instead. As it happens, the answer to the follow-up provided a good answer to the original question, in my opinion. So to summarise and hopefully clarify, I was after a few "tools" to use when building abstractions so that I could limit my use of dynamic patching, if possible. These tools turned out to be:

  • using send and receive instead of inlets and outlets (although [initbang] can be used for creating inlets and outlets at instantiation).
  • using [clone]
  • chaining trigger, route and select objects using send and receive - for example, using [t b b] - [t b b] instead of [t b b b]. This means that the number of arguments in these objects can be defined at creation time with the help of [clone] for example. This is discussed in the Pd mailing list.
  • using [initbang] as indicated in the answer below.

After having attempted to build a drum machine with presets and an arbitrary number of tracks with my limited knowledge of dynamic patching techniques, I realised that there must be many ways of avoiding the problems I had when doing this, which were several! Of course, some things have to be done with dynamic patching and that's fine. It's just about creating manageable code.

Max N
  • 1,134
  • 11
  • 23
sinewave440hz
  • 1,265
  • 9
  • 22
  • 1
    simply put: there's a nmber of things you can only do with dynamic patching. since most of your use cases seem to be centered around the question how you can dynamically alter a patch without dynamic patching, you will probably find little alternatives. however, your underlying problems could well be solved without dynamic patching (we don't know). – umläute Feb 17 '18 at 12:43
  • Actually, most of my use cases are focused on defining the patch at creation time. I'm currently not too bothered with having connections altered after that. I've been looking into this - remember my goal is to create abstractions that create a number of objects and connections based on their creation arguments. It seems to me now, after this research, that this could be solved using [clone] and wireless connections between the various cloned objects. I will spend some time on this and report back with an answer during the week! – sinewave440hz Feb 19 '18 at 07:19
  • Related follow-up question - Is there a way to define an abstraction that has an argument that defines how many outlets the abstraction exposes? Presumably it could dynamically patch itself, but that doesn't seem like a good idea. Is this a good case for building your own external? – sinewave440hz Feb 21 '18 at 11:06

1 Answers1

1

This is really an answer to "follow-up question" in the comment¹, rather than the original question (which I consider too broad to be answered),

Is there a way to define an abstraction that has an argument that defines how many outlets the abstraction exposes?

Sure, just use $1 for that.

E.g. [gates 10] could create 10 outlets...

Presumably it could dynamically patch itself, but that doesn't seem like a good idea.

well, if you want an abstraction to have a dynamic API (that is: a variable number of inlets/outlets), then there is no way around dynamic patching.

Is this a good case for building your own external?

depends on what you actually want the external to do.

the iemguts library (disclaimer: of which I am the author) has everything in place to allow you to dynamically patch what you need. Most important, there is [initbang], to create iolets before Pd tries to connect them (if you use [loadbang], the iolets will be created after Pd failed to connect to them). It also includes a [canvasargs] object which allows you to get all the arguments to the abstraction (e.g. which simplifies the task of having the number of outlets equal the number of arguments - like [trigger] or [pack])

if instead you want to wrap the entire functionality of your abstraction into an external, that's of course also possible (and pretty simple in the realm of C). Also keep in mind that other's might have already coded what you need.

¹ please don't abuse the comment field for follow-up questions. either update your original question (if the follow-up is a mere clarification of the original question) or post a new one.

umläute
  • 28,885
  • 9
  • 68
  • 122
  • Thank you. I have updated the question, you're quite right. There is probably much more to say on this subject, but I personally have the answers I need for now. – sinewave440hz Feb 26 '18 at 13:25
  • 1
    Worth to mention that now there is also the object [pdcontrol] as of Pd 0.50, which will give you a list of the arguments, a vanilla alternative to [canvasargs] in a way. – Max N May 03 '20 at 12:50