thetechnobear I backed the bela mini experimenter kit, and did not get an sdcard.
no big deal for me, I've spare sdcards here, and not sure if this is an isolated shipping issue, but others might need to get an sdcard.
sorry about that, probably an isolated mistake. We did release a new image (V0.3.8) specifically for this release.
thetechnobear I got a board wtih 10 sockets on it... it seems to be some kind of grove to I2C board?
thetechnobear are all 10 grove connectors connected in series... its a bit unclear
Yup sorry, that's a "Trill Hub" we designed specifically for KS StarterKit backers, so that it is easy to connect multiple sensors at once to Bela without need for a breadboard. All the pins of each kind from all sockets and pads are connected together, so you'd use one grove-to-pins to go to Bela and the grove-to-grove cables to go from the hub to the Trill devices. We are working on a branded version to put on the shop.
thetechnobear a quick 'hats off' and thank you to the bela team...
thetechnobear this is not true at all ... these patches all appear to be for the Craft
good point. The rest of the patch is indeed
general (i.e.: it would work with any sensor type), however, it is up to the user to specify the sensor type that they connected. We put "craft" in there, as it's one of the most common ones. I guess we should add a warning to all the
general- examples so that the user changes the device type to he one they connected.
A bit of context as to why it's hard to make a "general" example without asking the user to specify the device type.
You will have by now realised that the API allows you to specify the device type instead of the address. This should make life easier for beginners, as they do not have to worry about figuring out the address for their device. However, this does not mean that we scan the whole bus looking for a sensor of that type: we just assume that the device has the factory-default address. (The user can specify an optional 3rd argument to
setup() with the address in case they have changed the address). In fact, we try to avoid scanning arbitrary addresses on the bus when not strictly necessary, as this could make other I2C devices malfunction, and also lead to misidentify some devices. In the
multiple-devices examples we do scan the bus for all possible Trill addresses in order to detect connected devices (with the static method
Trill::probe()), and there we added a warning about the possible "dangers" of running them.
thetechnobear Im not sure if 'general' is needed since the specific examples work absolutely fine
thetechnobear also the PD general example does not include the HEX
not sure what you mean there? It is definitely mentioned in the
Just another quick note, as I know you use several different hardware platforms: if you are running on another Linux board, you may want to check out the
trill-osc example in here, which acts as an OSC-to-Trill bridge. I have developed it and tested it, but it would be good to get feedback from someone using it in the wild.