Some questions:
1) input/output format:
[attribute( | [canvasinfo]
|
Currently the output is "list foo bar bee". I considered outputting "attribute foo bar bee" to make it a little easier to route output when getting multiple attributes:
[attribute1, attribute2, attribute3( | [canvasinfo] | [route attribute3 attribute2 attribute1] | | |
[pack 0 0 0]
But there is a cost: you would have to do a [route attribute] or [$1( or [list split 1] any time you want to get just a single attribute. Furthermore, you can just do a [t a a] to forward "attribute" to the right inlet of [list prepend]---[route attribute3 attribute2 attribute1] if you need to get multiple attributes in sequence.
Additionally, I'm outputting "list foo bar bee" and not "foo bar bee" so that there's no chance of outputting a badly formed message. But for convenience I'm taking input [pack]-style, meaning that
both "list attribute 2" and "attribute 2" get the attribute and number distributed among the inlets.
Anyone see a problem with this type of interface?
2) system audio and MIDI devices What exactly would be useful here? Here's a sketch: * the active audio api. Should this be "A_FLOAT A_SYMBOL" where the float is the api# and the symbol is its description, or "A_FLOAT (atom) (atom) etc..." where the api description is broken into atoms according to pd's whitespace parsing rules? * available audio apis. same syntax as above * available audio devs. same syntax as above * audio params. these should just be for the currently selected device, no? And should these be split up and accessible by their names? ("channels", "samplerate", etc.) * midi stuff. same as above?
Any other audio-related stuff? I've already got DSP status.
-Jonathan