Modify outlets post-object construction

[mourendxu]

Hi,

I was wondering if it's possible to change the number of outlets of an object after it has been initialized? If so, how would I go about doing that?

Thank you.

[x37v]

@mourendxu
I have a project that uses min-api and I create my outlets in the constructor..
std::make_unique<c74::min::outlet<>>(this, name) and I store the result in a std::vector to maintain its lifetime.
Maybe this is helpful?

[mourendxu]

@x37v
Hi Alex, thank you for your reply. That's exactly what I am doing now.

What I am asking is can I change the number of outlets AFTER the constructor has been called?

Another way to look at it, can I create an mc like signal operator that will output undetermined(at object initialization time) number of channels?

Thank you!

[x37v]

@mourendxu

min is built on top of the max-sdk which indicates specifically that you shouldn't create inlets or outlets after your initialization routine: https://cycling74.com/sdk/max-sdk-8.0.3/html/chapter_inout.html

Ideally your creation arguments would describe all that you need to specify your i/o. If that isn't possible, could you specify a maximum for inlets and outlets in your creation arguments, create those, and then utilize as needed after?

[mourendxu]

Hi Alex, thank you for the reply. Yes that's what I thought. No worries. It's understandable due to preemptive buffer allocations.

I will work around it.
Thanks.

[eliottparis]

It was possible to handle dynamic IO with the max-api using the dsp_resize method for inlets and outlet_delete/outlet_append for outlets after the object creation, which can be particularly useful for UI objects. I'm wondering if this is possible with the min-api as well.

[superbigio]

I can think of only one very specific scenario where changing the number of inlet/outlets after object's instantiation may be useful. For the vast majority of cases, it's just a sign of flawed design.
Having said that, in max-api dynamic inlets/outlets are still possible.
Could you describe a little bit your specific user case?

[mourendxu]

thank you for the replies. So, I am creating a set of modules to transfer data from another application. In the other application, they do allow for dynamic # of channels.

The way I see it, it should be best handled with mc, since there isn't a need to physically attach connections. A single cable carrying x number of channels.

It's interesting to know that you can do that with dsp_resize. I will take a look there. Thanks.

[superbigio]

As I said, more often than not dynamic inlets/oulets are not really necessary.
From your answer I am assuming the data you are talking about is at the audio rate.
So, yes, in your specific case a single mc connection carrying N number of channels should be all that's needed.
If you were to transfer control data, you could easily use a single connection and use lists instead.

[mourendxu]

Yah, if it was just control data running on the Scheduler thread, the data is so sparse, there is no point in generating multiple outlets. A single outlet w a route/routepass would solve the problem.

Is there an MC project that I can take a look at? I mainly just want to see the standard practice for changing output channels post-constructor.

Thank you.

[superbigio]

You may want to ask C74/Ableton to share some code snippets that showcase the technique.
For example the [live.gain~] and [plot~] objects implement dynamic inlets/outlets under the hood.

[x37v]

Yah, if it was just control data running on the Scheduler thread, the data is so sparse, there is no point in generating multiple outlets. A single outlet w a route/routepass would solve the problem.

Is there an MC project that I can take a look at? I mainly just want to see the standard practice for changing output channels post-constructor.

Thank you.

If you're just trying to do MC directly.. check the SDK docs: https://cycling74.com/sdk/max-sdk-8.2.0/chapter_mc.html
There is also a min-devkit example that does MC, it is pretty minimal but maybe that is useful for you.