Vincent Goudard

works for me — the simpler the better :)

I think the same as what you said in your comment, the main reason being that the clipping/typing is taken care of in the ø.parameter. So if you feed a...

Just for the record (as @avilleret also reminded in gitter), the deferlow is just there to emulate a heavy process (e.g. loading plugins and stuff) that is deferred. So removing...

Yes, I was suggesting the same, just updating the doc. Besides, a remote can be bound to multiple parameters with different attributes, so I don't see a clear way of...

Since this thread is referenced in the "release-critical" just leaving a note here to mention #579 where I made a proposal on units. If this is too much of a...

One more thought on this : there is a number of dimensions that do not have dimensions (ratios like angles, concentrations, artihmetic or geometric gains, etc.) while they do have...

@avilleret Good point. Meanwhile, I think it would be worth preventing wrong syntaxes to create weird namespace (like "_A"

Well, the list of `band.{1..n}` addresses is being generated by the bandcount parameter, so all the channels would get a corresponding "band" submodel address. This way we ensure consistency between...

AFAIC, with @evanmtp example, I get this as a namespace, which matches what I would expect (using v1.1.0a4 980a883) : ``` print: namespace ossia_max_device:/myModel print: namespace ossia_max_device:/myModel/audio print: namespace ossia_max_device:/myModel/audio/gain...

I still have the duplicate node issue with v1.2.0 built 3476fe7 . ``` print: namespace ossia_max_device:/myModel print: namespace ossia_max_device:/myModel/audio print: namespace ossia_max_device:/myModel/audio/gain.1 print: namespace ossia_max_device:/myModel/audio/gain print: namespace ossia_max_device:/myModel/audio/gain/interpolation ```