Following from this discussion, I’ve started working on a system for saving generic data whenever a plugin is saved as part of a DAW session. We declare as JSON widget:
<Cabbage>
json channel("jsonData")
form ...
</Cabbage>
That channel’s data will be written to the plugin state memory whenever a session is saved. To make it easy to write and write to that string I’ve started writing a few utility opcodes. Here is an example of how they work.
instr WriteJSON
//overwrite existing data
iRes writeJSONToChannel 0, "jsonData", "{ \"happy\": true, \"pi\": 3.141}"
if iRes == -1 then
prints "Couldn't write JSON data"
endif
endin
instr UpdateJSON
//updated existing data
iRes writeJSONToChannel 1, "jsonData", {{
{
"happy": true, "pi": 1.141, "test": 12
}
}}
if iRes == -1 then
prints "Couldn't write JSON data"
endif
endin
instr ShowJSON
prints chnget:S("jsonData")
endin
instr GetJSONFloatValue
kVal getJSONFloatValue "jsonData", "pi"
printk2 kVal
endin
I just wonder if the opcodes names are a little long? Note these opcodes will only be accessible in Cabbage. They’ll be baked into the code-base. I will add string, and array getters too. I’m just putting it out there now so we can decide on opcodes names and other use case I may have overlooked. I prefer to use of camelCase naming because a) it differs from the majority of Csound opcodes, which helps make it clear that these don’t belong to Csound, and b) I find them easier to read
Let me know what you think. .