[PD-dev] info classes

[Jonathan Wilkes]

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