Work on channel-info to replace track-info

[robbert-vdh]

Not quite sure what plugins would do with it, but would it also make sense to add another field with flags for the track/device chain state? So soloed, muted, etc.

[abique]

Not quite sure what plugins would do with it, but would it also make sense to add another field with flags for the track/device chain state? So soloed, muted, etc.

Yes, solo, muted, record can be useful. But if the processing depends on that, then you need to make it available on the audio-thread too.

[robbert-vdh]

Those things could also be added to clap_transport_flags.

[Bremmers]

Plugins might want to know they're in the master section. A compressor or EQ can then default to settings suitable for mastering, for example.

[robbert-vdh]

Good idea. That could perhaps also be part of that bit field. And would it also make sense to move the return track fields there?

[Bremmers]

Perhaps the return track field should be renamed to "prefer wet-only". That's the only purpose for it I think?

There can be situations where wet-only is preferred, but there isn't really a 'return channel'.

[abique]

It seems there are two possible approaches:

1. Describe the environment, which implies what the plugin should do
   • send channel -> wet 100%
   • master track -> master preset on init
   • group track -> bus processing on init
2. Tell the plugin what to do directly
   • wet 100%
   • for_master_processing
   • for_bus_processing

Maybe 2. is a better call for consistent behavior.

[abique]

Also I think that describing the environment is maybe too much work for this extension:

• can be inside a device
• device can have master section and return channel
• device can have muted/solo pads
• device chain can be inside a device, or a track
• track can be inside track group, ...

So describing correctly the whole document / path will be a tough job, and either we do it well or we don't do it.

[abique]

I'm quite happy with this extension now.