Pd multichannel improvements

[Spacechild1]

Continuation of https://github.com/grame-cncm/faust/pull/1034.

Tries to address the issues raised in https://github.com/grame-cncm/faust/pull/1034#issuecomment-2225892623.

First, make the first inlet a pure message inlet, so users can not accidentally connect it to a signal.

As a second step, add the MESSAGE_INLET macro to control the behavior of the first inlet at compile time.

If 0, the first inlet is a signal inlet and also takes messages, which is more idiomatic, but not backwards compatible.

If 1, keep the old behavior (= default).

[Spacechild1]

I still can't test, so I hope I didn't break anything :) @sletz @alainbonardi Please test all four combinations:

1. MESSAGE_INLET=1 without -m
2. MESSAGE_INLET=1 with -m
3. MESSAGE_INLET=0 without -m
4. MESSAGE_INLET=0 with -m

If this works, you could add an option to the faust2puredata script which would enable the new behavior (by passing -D MESSAGE_INLET=<0|1> to the compiler). Note that it can't be enabled by default because it wouldn't be backwards compatible. In particular, the new behavior isn't compatible with the existing faust2pd program - which generates the UI - so the latter would need to be updated as well.

[sletz]

Thanks. So pd-multichannel branch updated with a new -msi (message and signal inlet) option in faust2puredata to get the new behaviour. @alainbonardi can you test?

[sletz]

Like here: https://github.com/grame-cncm/faust/commit/ef150b97fa6ba3bac74a36e1956dd708e63b85c5 ?

[alainbonardi]

Thank you very much Christof and Stéphane. I tested the four options: with/without -msi compilation option and with/without -m object parameter, everything works perfectly. But the problem of compatibility I mentioned in my first post was not for the inlets but for the outlets. Before our changes, faust2puredata generated an object whose first outlet was not signal (maybe dump results?): signals started on the second outlet. See this screenshot of a Pd patch comparing previous compilation (abc_2d_decoder1_4~ on the right) and new compilation (decoder1~ on the left). With the previous compilation, the 4 signals went out through outlets 2 to 5. Now, the signals go out through outlets 1 to 4... This creates a problem of backwards compatibility.

[Spacechild1]

I tested the four options: with/without -msi compilation option and with/without -m object parameter, everything works perfectly.

Thanks a lot for testing!

But the problem of compatibility I mentioned in my first post was not for the inlets but for the outlets

Ah, I totally misread your comment...

signals started on the second outlet.

Ouch, thanks for catching that! Indeed, I accidentally changed the order. In Pd externals the signal outlets typically come before the message outlets, so I just did it automatically...

I will restore the old order for the "legacy" behavior, but keep the new order for the "new" behavior. I will update the script accordingly. -msi should probably be called something like -new. (In the future, we might use the new behavior by default, but allow users to get the legacy behavior, e.g. with -legacy.) Will make a PR later that day.

[alainbonardi]

Thanks a lot Christof! Why not call -msi something like -mlsi with l for left. Maybe -new is not explicite enough, and imagine if within a few months, something newer arises...