OSC-CALL: convert to string and back to parse multiple input formats

[Leon-Focker]

I addressed an issue a fellow student encountered when working with Csound and SC. Csound sends messages as a single string, e.g., ("/osc-sc something (+ 1 1)"), unlike Max or Pure Data, which send messages like ("/osc-sc" "something" "(+" 1 "1").

To solve this, I implemented parsing that converts the single string message into a list, making both message formats consistent with the latter approach. This solution seems minimally invasive (as it doesn't change other code or add a keyword etc.). An alternative approach could be adding a keyword to osc-call to avoid the unnecessary parsing of "standard" messages (but adding difficulty for the user). What do you think?

[mdedwards]

Hello Leon, thanks for this. I don’t see your name in any part of the code, but maybe I’m looking in the wrong place. Any kind of character-by-character string processing comes with overhead of course, and there’s already enough overhead with OSC messages, so rather than any kind of string processing for every system, I would advise only doing this when necessary, i.e. by passing a CSound keyword argument to OSC–call. Or at the very least you could test that it’s necessary by seeing if you’ve got the kind of data you would expect. All the best, Michael.

[Leon-Focker]

Understood! I added a :input-as-one-string argument to osc-call, along with a short documenation. If left nil, everything works exactly as before. When set to T, both message types are supported, with the implicit overhead. Works well on my system. Best, Leon

[mdedwards]

Would :one-string perhaps suffice, so we don’t have to type/remember so much? Also, do you mean it works still with Max and PD?

[mdedwards]

PS though to be honest, what do you have against :csound instead of one-string — might make it more obvious to some what/when they have to pass, and even if some other systems arise needing the same treatment, :csound is still fine as it’s more :csound-style

[Leon-Focker]

I agree that they keyword could be shorter, but :one-string would be too vague, in my opinion. And I wasn't sure wheter it was really a csound problem or generally an input-problem, that's why I wanted to avoid that label. But if you think it's fine I have nothing against it.

Also, do you mean it works still with Max and PD?

Yes, the "original" message style works both, when the keyword is T or NIL. Maybe the keyword could reflect that, something like :permissive-parsing ?

[mdedwards]

I agree that they keyword could be shorter, but :one-string would be too vague, in my opinion. And I wasn't sure wheter it was really a csound problem or generally an input-problem, that's why I wanted to avoid that label. But if you think it's fine I have nothing against it.

Then lets use :csound

Also, do you mean it works still with Max and PD?

Yes, the "original" message style works both, when the keyword is T or NIL. Maybe the keyword could reflect that, something like :permissive-parsing ?

Great but for all uses up to now (for which projects/patches exist) I don’t want to have to (remember to) change anything, rather just for the csound case you specify :csound t (default is nil). :permissive-parsing sounds like a partner-swapping party from the 60s: not sure that helps [our projects]

[Leon-Focker]

Alright, let's go with :csound then

sounds like a partner-swapping party from the 60s: not sure that helps [our projects]

Haha, we won't know for sure unless we try 😝

[Leon-Focker]

Keyword is now named :csound, see 21815fe