Forum rss-feed

Forum

Software: Command line tools guide

Most Recent

written by: niksilver

Jim, thanks for that comprehensive reply. Actually I have watched the DevCon video (with plenty of rewinding to repeat), which is how I got as far as I did. I'm going to copy and paste some of your comments above into the wiki page because they're very helpful.

However, I'm still a little confused over what kinds of names are what. Not the data, just the different kinds of names. Although I admit it is somewhat academic.

Anyway, if you're interested in such a discussion, here goes...

To illustrate, I do these commands and get the following results (some text elided, angle brackets converted to square brackets just to allow displaying in this post):

$ ./bcat.exe '[rig6]' | head -1

. {cname:rig,cordinal:6,protocols:rigouter,plugin:rig,rig:rig6,ordinal:1,name:clarinet rig}
$ ./bcat.exe '[pico_manager1/1]' | head -1
. {cname:keyboard pico,cordinal:1,protocols:is_subsys,plugin:pico_manager}
$ ./brpc.exe '[interpreter1]' identify clarinet rig
'[main:rig6]' clarinet rig 1
$ ./brpc.exe '[interpreter1]' identify rig
# No output produced
$ ./brpc.exe '[interpreter1]' identify keyboard pico
'[main:pico_manager1/1]' keyboard pico 1
$ ./brpc.exe '[interpreter1]' identify pico keyboard
'[main:pico_manager1/1]' keyboard pico 1
$ ./brpc.exe '[interpreter1]' identify rig clarinet
'[main:rig6]' clarinet rig 1


I believe the name in angle brackets is called a "canonical name". So perhaps (in the first command) "rig6" is the canonical name. But the output has something called cname, which I assume to mean "canonical name", and this is "rig", not "rig6". Instead there is a cordinal (canonical ordinal?) which is "6". So is the canonical name "rig" or "rig6"? And what do "cname" and "cordinal" mean?

The output of the first command also shows me that its "name" is "clarinet rig", which I guess is what we call its "proper name".

Now let's look at the second command. Here I'm putting "pico_manager1/1" in angle brackets. Is that the canonical name? The output suggests the cname is "keyboard pico", which is either one name with a space, or two alternative names. But either way, it's nothing like what I put in angle brackets. However, the plugin seems to be called pico_manager. So maybe the canonical name is based on the plugin name after all. In that case I don't know what "cname" means.

And then there's the extra "/1" which isn't used when we looked at rig6. I don't know why "/1" is important here, or where it comes from, and yet nothing like it is used for rig6.

Moving on...

When I do the "identify clarinet rig" command I presume the agent responds because its "name" (as seen from the first command) is "clarinet rig".

When I do the "identify rig" command I get no output. So it ignores the fact that its cname is "rig".

When I do "identify keyboard pico" and "identify pico keyboard" the pico manager agent responds both times. This is despite the fact that it doesn't have a "name", so I guess it's recognising its "cname" as a fallback. I'm puzzled as to why it calls itself "keyboard pico 1" when the phrase "keyboard pico" doesn't appear in its data (only "pico keyboard" does).

Also, it seems a bit clever/weird that it responds to both "keyboard pico" and "pico keyboard". But then (finally command) rig6 also responds to "rig clarinet" as well as "clarinet rig".

As for cellos mixed up with clarinets... well, I tried the experiment again and got the same results. Reproduced here in full. Start up EigenD 2.0.62 without the Pico plugged in, then issue the following command and get the following results:

$ ./brpc.exe '[interpreter1]' dump clarinet rig 1 | grep cello

log:using portbase 55555
cello rig controller control output -> console mixer 1 volume
cello rig controller control output -> console mixer 1 pan
cello rig controller control output -> console mixer 1 send
cello rig 1 right audio -> console mixer 1 right audio input
cello rig 1 left audio -> console mixer 1 left audio input
cello rig controller control output -> console mixer 1 send
cello rig controller control output -> console mixer 1 send


Plugging the pico in and repeating the command gives the same results.

A similar thing happens when I swap cello and clarinet, too:

$ ./brpc.exe '[interpreter1]' dump cello rig 1 | grep clarinet

log:using portbase 55555
clarinet rig controller control output -> console mixer 1 send
clarinet rig controller control output -> console mixer 1 send
clarinet rig controller control output -> console mixer 1 volume
clarinet rig controller control output -> console mixer 1 pan
clarinet rig 1 audio -> console mixer 1 left audio input
clarinet rig 1 audio -> console mixer 1 right audio input
clarinet rig controller control output -> console mixer 1 send


Curiouser and curiouser...

written by: niksilver

Thu, 30 Aug 2012 23:03:39 +0100 BST

I've noted down a few useful commands for exploring EigenD. However, I'd appreciate it if someone more knowledgeable could give it the once-over for terminology:

Command line tools guide

I'm not entirely sure I'm using the terms "address", "canonical name" and "proper name" correctly. For example consider this command and its output:

$ ./brpc.exe '[interpreter1]' identify pico keyboard 1

log:using portbase 55555
'[main:pico_manager1/1]' keyboard pico 1


(Square brackets replaced by angle brackets.)

I couldn't honestly tell you what I'm typing when I type "pico keyboard 1", nor what I'm seeing when I see the output "keyboard pico 1", which is a different word order. Nor could I pick apart the phrase "pico_manager1/1" which clearly consists of several parts: pico_manager, 1 before the slash, 1 after the slash.

I'm also rather puzzled why this command:

./brpc.exe '[interpreter1]' dump clarinet rig 1 | grep cello


gives several lines of output in Pico setup 1 -- cello references in clarinet connections?!


written by: jim

Fri, 31 Aug 2012 14:55:22 +0100 BST

To understand much of what you might see using these commands you might have to look at the source code. Also, if you sit through EigenD internals videos Here you'll get an insight into the output.

In essence though, EigenD agents are more or less independent things. Subprograms rather than plugins. And they can be manipulated using network messages. This is how Workbench, Browser, and Commander communicate. We don't leverage this protocol much at the moment, apart from Workbench. It's multicast UDP based, and at the moment we restrict it to the local machine because the amount of data transmitted can make a real network drop in its tracks. Multicast UDP is effectively useless over WIFI and we're toying with the idea of switching it to a unicast or even TCP based protocol. In the long term future, we'll be able to use it to allow multiple EigenDs on different systems to be tightly integrated, but it's likely to evolve a lot before then.

An agent has an address, and a tree of state variables. The address is set when the agent is first created, and never changes, even if you rename the agent. The bit before the #, in angle brackets is the agent address, and anything after the '#' is the state variable with in the agent.

The state variable hold everything about the agent. All its ports, verbs, descriptive data, and setup are represented here. When a setup is saved, its the state variables which are saved.

In the actual address part, there is a workspace and the agent name. The /1 you are seeing in the keyboard agent is part of the agent name. Keyboard agents are not created directly by EigenD, they are created by the keyboard manager, which names them by suffixing its own name.

The workspace name is used by the rig system. In the future, it will allow us to treat rigs as distinct units which can be loaded and saved and cloned independently.

Things like ports, and verbs, and names are represented in the state tree idiomatically. Most interesting are the .255 variables, which contain a dictionary of metadata about an atom. This includes the name and ordinal, and much more. All connections, talker actions, everything, are in here somewhere.

Also interesting are the 'fast' data streams. if you use 'bcat -idD' you'll see additional data, including the current values of any fast performance data. Try it on the keyboard while holding some keys down.

All agents can have rpc calls. This is how verbs are implemented underneath. The metadata of an agent describes the verbs, and rpc is used to invoke them. There are additional rpcs for diagnostic purposes. 'dump' and 'identify' are two such.

I don't see anything about the cello when I dump clarinet rig 1!

jim


written by: niksilver

Fri, 31 Aug 2012 22:56:02 +0100 BST

Jim, thanks for that comprehensive reply. Actually I have watched the DevCon video (with plenty of rewinding to repeat), which is how I got as far as I did. I'm going to copy and paste some of your comments above into the wiki page because they're very helpful.

However, I'm still a little confused over what kinds of names are what. Not the data, just the different kinds of names. Although I admit it is somewhat academic.

Anyway, if you're interested in such a discussion, here goes...

To illustrate, I do these commands and get the following results (some text elided, angle brackets converted to square brackets just to allow displaying in this post):

$ ./bcat.exe '[rig6]' | head -1

. {cname:rig,cordinal:6,protocols:rigouter,plugin:rig,rig:rig6,ordinal:1,name:clarinet rig}
$ ./bcat.exe '[pico_manager1/1]' | head -1
. {cname:keyboard pico,cordinal:1,protocols:is_subsys,plugin:pico_manager}
$ ./brpc.exe '[interpreter1]' identify clarinet rig
'[main:rig6]' clarinet rig 1
$ ./brpc.exe '[interpreter1]' identify rig
# No output produced
$ ./brpc.exe '[interpreter1]' identify keyboard pico
'[main:pico_manager1/1]' keyboard pico 1
$ ./brpc.exe '[interpreter1]' identify pico keyboard
'[main:pico_manager1/1]' keyboard pico 1
$ ./brpc.exe '[interpreter1]' identify rig clarinet
'[main:rig6]' clarinet rig 1


I believe the name in angle brackets is called a "canonical name". So perhaps (in the first command) "rig6" is the canonical name. But the output has something called cname, which I assume to mean "canonical name", and this is "rig", not "rig6". Instead there is a cordinal (canonical ordinal?) which is "6". So is the canonical name "rig" or "rig6"? And what do "cname" and "cordinal" mean?

The output of the first command also shows me that its "name" is "clarinet rig", which I guess is what we call its "proper name".

Now let's look at the second command. Here I'm putting "pico_manager1/1" in angle brackets. Is that the canonical name? The output suggests the cname is "keyboard pico", which is either one name with a space, or two alternative names. But either way, it's nothing like what I put in angle brackets. However, the plugin seems to be called pico_manager. So maybe the canonical name is based on the plugin name after all. In that case I don't know what "cname" means.

And then there's the extra "/1" which isn't used when we looked at rig6. I don't know why "/1" is important here, or where it comes from, and yet nothing like it is used for rig6.

Moving on...

When I do the "identify clarinet rig" command I presume the agent responds because its "name" (as seen from the first command) is "clarinet rig".

When I do the "identify rig" command I get no output. So it ignores the fact that its cname is "rig".

When I do "identify keyboard pico" and "identify pico keyboard" the pico manager agent responds both times. This is despite the fact that it doesn't have a "name", so I guess it's recognising its "cname" as a fallback. I'm puzzled as to why it calls itself "keyboard pico 1" when the phrase "keyboard pico" doesn't appear in its data (only "pico keyboard" does).

Also, it seems a bit clever/weird that it responds to both "keyboard pico" and "pico keyboard". But then (finally command) rig6 also responds to "rig clarinet" as well as "clarinet rig".

As for cellos mixed up with clarinets... well, I tried the experiment again and got the same results. Reproduced here in full. Start up EigenD 2.0.62 without the Pico plugged in, then issue the following command and get the following results:

$ ./brpc.exe '[interpreter1]' dump clarinet rig 1 | grep cello

log:using portbase 55555
cello rig controller control output -> console mixer 1 volume
cello rig controller control output -> console mixer 1 pan
cello rig controller control output -> console mixer 1 send
cello rig 1 right audio -> console mixer 1 right audio input
cello rig 1 left audio -> console mixer 1 left audio input
cello rig controller control output -> console mixer 1 send
cello rig controller control output -> console mixer 1 send


Plugging the pico in and repeating the command gives the same results.

A similar thing happens when I swap cello and clarinet, too:

$ ./brpc.exe '[interpreter1]' dump cello rig 1 | grep clarinet

log:using portbase 55555
clarinet rig controller control output -> console mixer 1 send
clarinet rig controller control output -> console mixer 1 send
clarinet rig controller control output -> console mixer 1 volume
clarinet rig controller control output -> console mixer 1 pan
clarinet rig 1 audio -> console mixer 1 left audio input
clarinet rig 1 audio -> console mixer 1 right audio input
clarinet rig controller control output -> console mixer 1 send


Curiouser and curiouser...



Please log in to join the discussions