I understand that message and object dollar args ($1 etc) are substituted with values from different types of sources: Object arg values are from their enclosing scope's creation arg values and message args are from their inlet values. What do I do if I want to create an object with a dynamic value from a message?

Specifically I want a small abstraction wrapping [ctlin] so I can choose during runtime which control (and/or its channel) it's getting CC values from. [ctlin] has no inlets, nor properties (so no receive symbol), only creation args. I thought that I could Put a [ctlinWrapper] subpatch in my patch (saved in the same folder or in the Path as ctlinWrapper.pd ). In the subpatch include [inlet]-[f] to accept a message sent in the enclosing patch connected to the subpatch inlet, that would be available in the subpatch as $1. Then I could include in the subpatch [ctlin $1] . But the $1 in [ctlin $1] doesn't seem to receive the value from the inlet, as [ctlin $1] doesn't output any value even when I work the MIDI control that generates the CC signal.

Is there a way to specify by message during runtime a creation arg of an object? Or otherwise specify during runtime rather than at creation the control that [ctlin] reports?

I do this by using [sroute]

http://www.pdpatchrepo.info/hurleur/ctlin-router.pd

quick vanilla attempt

http://www.pdpatchrepo.info/hurleur/ctlinn.pd

All you need is to pack [ctlin], reorder them, and [route].

(This is basically the same thing as Gromit's, but you don't need [sroute] for it. [route] now has a second inlet when you only give it one argument, just like [sel]).

http://www.pdpatchrepo.info/hurleur/ctlin2.pd

@Maelstorm said:

All you need is to pack [ctlin], reorder them, and [route].

(This is basically the same thing as Gromit's, but you don't need [sroute] for it. [route] now has a second inlet when you only give it one argument, just like [sel]).

Ah, nice to know
Cheers

@Maelstorm said:

All you need is to pack [ctlin], reorder them, and [route].

So you suggest I use [ctlin] (no creation args) to supply all CC messages, incoming to PD on any MIDI controls, into my patch, and filter them with [route] , to actually use the CC message from only the control I'm targeting. Is there any extra Pd resource overhead (CPU, latency - memory probably not so important) in doing it that way, compared to say hardcoding [ctlin 57 1] directly?

Thanks all for the tips. Including that demonstration of dynamic patch metaprogramming in ctlinn.pd .

Attached please find ccin.pd , which takes a float in its hot inlet specifying the MIDI control number, and an optional float in its right inlet specifying the MIDI channel (defaults to 1), and outputs the MIDI control's value from the CC message. Inside it wraps [ctlin] to filter for only the specified MIDI control/channel's value. So the complete channel/control#/value triplet can be gotten from the input messages and the output message, and packed into a list in the patch enclosing this patch if desired.

I do wonder how much extra resources this patch consumes in wrapping and filtering [ctlin], beyond what a hardcoded [ctlin 57 1] would consume. Mainly in MIDI latency, but also in CPU and possibly RAM, when considering running on constrained devices. Like if Pd could run right in a MIDI controller device, with one of these patches running on each of many controls.

http://www.pdpatchrepo.info/hurleur/ccin.pd

@Matthew said:

I do wonder how much extra resources this patch consumes in wrapping and filtering [ctlin], beyond what a hardcoded [ctlin 57 1] would consume. Mainly in MIDI latency, but also in CPU and possibly RAM, when considering running on constrained devices. Like if Pd could run right in a MIDI controller device, with one of these patches running on each of many controls.

The difference would be pretty negligible. These are all very simple objects. But if you really want to test the difference, use [timer] to see how much overhead is involved between receiving the MIDI message from [ctlin] and processing it afterward.

@Matthew said:

Attached please find ccin.pd , which takes a float in its hot inlet specifying the MIDI control number, and an optional float in its right inlet specifying the MIDI channel (defaults to 1), and outputs the MIDI control's value from the CC message.

Attached please find a revised ccin.pd which outputs the MIDI control's value from the CC message. It takes an argument specifying the MIDI control number and defaults to MIDI channel 1. An optional float in its left inlet overrides its MIDI control number filter; an optional float in its right inlet overrides its MIDI channel number filter.

http://www.pdpatchrepo.info/hurleur/ccin.pd