bendin with no argument is broken

[giuliomoro]

If no argument (or 0) is given, then one gets as at the left outlet the same as the right outlet minus 1. This is because

[route $1]
|      |
|      [$1(
|      |
|      [spigot]
|      |
[outlet]

should actually be

[route $1]
|      |
|      [$2(
|      |
|      [spigot]
|      |
[outlet]

I think. With this fix it seems to work the way I expect it to. But do I expect it right?

I think also pgmin and touchin have the same issue (didn't test).

[giuliomoro]

i.e.:

diff --git a/hvcc/interpreters/pd2hv/libs/pd/bendin.pd b/hvcc/interpreters/pd2hv/libs/pd/bendin.pd
index 006fac1..5056542 100644
--- a/hvcc/interpreters/pd2hv/libs/pd/bendin.pd
+++ b/hvcc/interpreters/pd2hv/libs/pd/bendin.pd
@@ -10,17 +10,17 @@
 #X obj 124 191 i \$1;
 #X msg 31 147 \$2 \$1;
 #X obj 91 235 spigot;
-#X msg 91 208 \$1;
 #X obj 148 108 + 1;
-#X connect 1 1 12 0;
+#X msg 91 208 \$2;
+#X connect 1 1 11 0;
 #X connect 3 0 1 0;
 #X connect 3 0 9 0;
 #X connect 5 0 8 0;
 #X connect 6 0 10 1;
 #X connect 7 0 4 0;
-#X connect 7 1 11 0;
+#X connect 7 1 12 0;
 #X connect 8 0 6 0;
 #X connect 9 0 7 0;
 #X connect 10 0 4 0;
-#X connect 11 0 10 0;
-#X connect 12 0 0 0;
+#X connect 11 0 0 0;
+#X connect 12 0 10 0;

(though editing the file in Pd as above makes the patch unnecessarily long, so here's the one edited with a text editor):

diff --git a/hvcc/interpreters/pd2hv/libs/pd/bendin.pd b/hvcc/interpreters/pd2hv/libs/pd/bendin.pd
index 006fac1..f22331a 100644
--- a/hvcc/interpreters/pd2hv/libs/pd/bendin.pd
+++ b/hvcc/interpreters/pd2hv/libs/pd/bendin.pd
@@ -10,7 +10,7 @@
 #X obj 124 191 i \$1;
 #X msg 31 147 \$2 \$1;
 #X obj 91 235 spigot;
-#X msg 91 208 \$1;
+#X msg 91 208 \$2;
 #X obj 148 108 + 1;
 #X connect 1 1 12 0;
 #X connect 3 0 1 0;

[dromer]

What do you mean with "one gets as at the left outlet the same as the right outlet minus 1" ?

The right outlet gives the channel/port number, this does not relate to the left outlet in any way afaict.

I do not see the behavior you describe and have tested it extensively in the DPF wrapper. See https://github.com/Wasted-Audio/hvcc/tree/develop/examples/dpf

So I'm not sure what to look out for in trying to reproduce what you are claiming.

Do note that we assume the wrapper uses 0-base for the midi channel, in the heavy object we [+ 1] to get to the 1-based channel numbering in pd (and then [- 1] before going out again).

[giuliomoro]

This is what I mean:

where [bendinbad] is what you currently have on develop and [bendingood] has the patch above (i.e.: replaced $1 with $2 in the message at the right outlet of the [route]).

Note how [bendinbad] behaves badly when it has no argument (i.e.: [$1] is 0)

[giuliomoro]

Btw there are some more issues:

• the channel outlet is off by 1 with respect the creation argument. In Pd, you have [bendin 1] and this always gives you [1( at the right oulet. In heavy, this gives you [2( when the message is on the selected channel
• the channel number outlet sends a value even if the message is coming in on a different channel. In Pd, when a message is coming on a different channel from the creation argument, no outlet is fired.
• because of the fan-out out of the [inlet], there is no guarantee that the channel outlet will send its message before the value outlet does. Make it explicit with a [t] (although fixing the above points would probably require a major rework of this section anyhow)

[dromer]

It doesn't make any sense to load these abstractions straight in Pd, their purpose is inside of heavy and not otherwise.

As I explained earlier we +/- the channel number so that we get regular Pd behaviour while keeping the generator/wrapper 0-based, however I do see now that with creation argument this may go wrong. We need some better example patches in order to test this behaviour.

My suggestion would be to add this to the unit tests first and then try to fix the abstractions.

[dromer]

Of course adding to the unit tests means we need to extend them to include specific tests for midi.

This will require a new wrapper and likely a way to read midi files for testing. Then compare outputs to known outputs from Pd, for each of the midi i/o objects.

[dromer]

Ok, I did a bit of experimenting, and bare with me as I'm also still trying to think of what is the best behavior here. This is the monstrosity I came up with now.

This seems to give the most consistent behavior:

• Output all value and channel when no channel/port or 0 is set
• When set only output value for that channel/port
• Never go below channel/port 1

What do you think?

For the right outlet on matching channel/port setting I opted for just outputing that channel. In the real world this outlet doesn't exist so you would normally ignore using it of course.

PS: I still need to test this in an actual heavy compiled plugin and compare output/behavior between it and pd.

[giuliomoro]

In the real world this outlet doesn't exist so you would normally ignore using it of course.

what do you mean by that?

[dromer]

If you put [bendin 1] in your patch there is no right outlet. So after translating in heavy this output is disconnected.

Only on None/0 is there an outlet for channel/port number in pd.

Did a bit of tweaking and expanding the test-case. See top row:

bendingood2 is the most proper behavior I think. but as said it would be nice to have proper midi test-cases, but this will require a custom test-wrapper that reads in midi files or something.

[dromer]

@giuliomoro have you tried yet with my suggested fix? ^

We still don't have tests for midi (need to find a simple way to load in midi files into a wrapper), which would be helpful to confirm desired behavior like this.