Cabbage Logo
Back to Cabbage Site

No channel name with imported widgets?

#1

Is it acceptable form to import a group of widgets without a channel name, implying a prefix of “”?

For example, instead of:
WidgetGroup bounds(0,0,380, 350), channel("test"), namespace("MyNamespace")
It would be:
WidgetGroup bounds(0,0,380, 350), namespace("MyNamespace")

And if so, how realistic would a csound request for opcode to support string inputs with a default of “”? This would save countless “wrapper” UDOs without a string input that pass on blank strings to the real UDOs that have an “optional” string.

Hope that makes sense… :slight_smile:

#2

By the way, this already works ok with the current OSX beta, it’s more of a question of how bad of an idea is it to do this. Assuming all widgets contained in the import are internally named, is this something that can be considered ok, or should it still be avoided?

I’m using this to create a few imported widgets that can be used unnamed in a “global” manner, but could still be named to have unique instances if needed/wanted.

#3

If all the channel names are managed internally then I guess it’s Ok? But you’ll really have to push it as hard as you can to find issues. As for asking the Csound devs to support empty strings, I’m not sure they will go for that. Seems that something like:

k1 chnget ""

should result in an error?

#4

Challenge accepted!

Sorry, what I meant was supporting strings as input type for UDOs with a default value. Similar to how an i-rate or k-rate variable can have a default value if no input is provided, this would allow a string variable at xin that defaults to “” if nothing was provided.

This would prevent the need for something like:

opcode,MyUDO,0,S
  SString xin
  ...
endop
opcode,MyUDO,0,0
  MyUDO ""
  ...
endop
#5

I was worried you’d say that! As a proof of concept, I think importing custom plants works nicely. But in terms of implementation, I might have to take another look. It’s all a little messy under the hood.

Ah yes, I don’t see why not. Then again, it’s up to the Csound devs.

#6

Just checking back in with this.

So far, imported widgets without a channel name seem to work “ok”. I haven’t tested with widgets contained inside the import that are also unnamed, but I expect that will cause issues (as it should).

The only issue I’ve encountered so far is that when the imported widgets are inside an image container (part of the import), the image loses some of it’s settings. In particular, I’m losing the color settings… but it could easily be related to those settings being expanded macros at the very start of the line.

Hopefully that makes sense. More testing to come, hopefully sooner rather than later!