ERROR : path '/dsp/bargraph' is already used

[magnetophon]

As discussed in https://github.com/grame-cncm/faust/issues/406:

The compiler now refuses to compile code that cause several identical UI path (like/foo/bar/ui_item) to be produced, since identical paths cannot be distinguished when controlled with OSC for instance.

This makes sense for input elements, but I don't understand why it should be the case for outputs, like bargraphs.

This fails:

process = MyMeter,MyMeter;
MyMeter             = _<:(_, (min(0.250):max(0):(hbargraph("[1][unit:ms]release[tooltip: release]", 0, 0.250)))):attach;

This works:

process = MyMeter(1),MyMeter(2);
MyMeter(i)             = _<:(_, (min(0.250):max(0):(hbargraph("[1][unit:ms]release %i[tooltip: release]", 0, 0.250)))):attach;

Is this intended behavior? Would it be possible/desirable to make Faust automatically add an index to any output UI element that needs it? If not, does that mean that any bargraph needs a number passed to it in the dsp code and this number needs to be exposed in any function using a bargraph, just in case that function might be used in a parallel construction later on?

Oddly enough, omitting a name altogether also works!

process = MyMeter,MyMeter;
MyMeter             = _<:(_, (min(0.250):max(0):(hbargraph("[1][unit:ms][tooltip: release]", 0, 0.250)))):attach;

Is that intentional?

[sletz]

• output items like bargraph may be connected to an UI displayer that need to distinguish the different paths. Say in a different way a Faust program may send its path like outputs to something else
• in general, we try to avoid doing some "automatic choice" for the user
• but in the last case (without a explicit name) we did it by computing a name based on the address of the bargraph (you can check that by looking at the buildUserInterface in the C++ generated code), which cause also some issues (like addresses changing at each recompilation of the program...)
• maybe we should then remove this "computing a name based on the address of the bargraph" rule when no name is given and be even more restrictive ? but then it will break even more code...

[magnetophon]

I understand that in general, you'd want to avoid doing some "automatic choice" for the user. On the other side, I find the current behavior very unhandy.

As mentioned in another issue, I think the great strength of Faust is it's ability to abstract away all the details and just let me focus on the dsp.

One of the core premises, as far as I'm concerned, is that if f(x) works, then f(x),f(x) also works.

Faust makes it easy to build deeply nested structures.

The new need to pass a number into any function that has a bargraph anywhere deep down it's guts is a severe breakage of the above user experience, IMHO. If I don't pass that number, I lose the ability to have more then one of that function.

Would it not be an acceptable compromise to have automatic numbering plus a warning during compilation?

At least I would ask to put such breaking changes behind a flag, and only make it the default after releasing a new major version (Faust 3.0), if ever.

[sletz]

We'll have to think again yes.

[magnetophon]

Thanks! :)

[magnetophon]

At least I would ask to put such breaking changes behind a flag, and only make it the default after releasing a new major version (Faust 3.0), if ever.

Any news on this?

[josmithiii]

How about a new escape code? Instead of %i, the code %p could mean "path to this widget", which could be autogenerated in some known way that could be ideally figured out, such as sequential integers starting from 0 appending the usual OSC path.

Cheers, Julius

On Tue, Aug 4, 2020 at 3:46 AM Bart Brouns [email protected] wrote:

At least I would ask to put such breaking changes behind a flag, and only make it the default after releasing a new major version (Faust 3.0), if ever.

Any news on this?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/grame-cncm/faust/issues/407#issuecomment-668523663, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQZKFISY4SXKDTMWBFWOVTR67RHVANCNFSM4K7EY3HQ .

-- Julius O. Smith III [email protected] Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/

[magnetophon]

Sounds great to me!