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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
