@andy-delmaine You can have a look at creating custom actions for google home (https://developers.google.com/... ) Most likely you can get it to send something to NodeRed (with nodeJS). this way you can avoid a lot of actual coding but it will still be some finicky work. I did not watch it but this seems to be about how to get it going. Node red has an optional OSC Node https://www.npmjs.com/package/...

@juriaan said: why aren't you using Artnet  We did have a discussion about using Artnet, but as it turns out  we are sending the rgb values of the first and last led of each strand to the nodeMCU (9 led strands x 2). The code on the nodeMCU then produces an interpolation across the rest of the leds in each strand. So there is an efficiency with only providing parameters for 18 leds (they are linked to audio frequency analysis). Each strand is 9 led long and they have been wired to produce 9 x strands each 900mm long that will be sewn into a dancers layered tulle costume. When we tested the OSC multi transmit starting with 54 values everything was working fine except for the missing values. We tried sending less in increments and it appeared that 49 was our maximum. We have another set of wearable controllers that send accelerometer data back to Isadora also using OSC. Best wishes Bonemap

@fred said: in addition to then add interface components, (which I feel look really dated and I don't like to give to clients).  There are a number of underlying concerns in your pitch. And you raise some of the niggling structural issues that regularly get comments by Isadora users. There was a robust discussion by the 2.6 beta testers about accessing OSC addresses more efficiently in Isadora, particularly from within the Isadora work area. As a result the OSC Multi Listner was implemented with a switch to display OSC pathnames within the body of the node. So this was a step towards a more convenient approach to working with a large volume of OSC connectivity points.  Taking the in-patch direction a quantum leap further and making each node inherently and readily capable of addressing outgoing/incoming OSC/midi/TCP/UDP/serial/Net Broadcaster pathnames at any parameter variable, is certainly a game changer. It would represent a serious innovation in what the software represents and how it will interface within the ecology of applications typically used in a media and performance production.  I believe it would require the addition of a combined in/out management panel that allowed sequential access and editable lists of external/internal connectivity points with a ‘go to node’ function that highlights and brings into focus the associated actor. The connectivity panel would need to be a floating panel (not a dropdown from the Isadora frame) so that it can be always accessible and viewable beside the patch bay as connectivity points are being programmed in an actor. In addition, an actor with an existing connection could be analogously coloured to indicate that the connection exists and coloured again if the connection is viable/active.Presently, there is no continuity in the way each type of connectivity point is dealt with in Isadora. It appears that this is due to the ad hoc development of each connectivity feature. Currently Discrete control panels appear in many different places and forms. And some of these only coalesce in a monitor window. However, colocating the management of all node connectivity points would add productivity and nibbleness to the process, particularly when setting up and running a production in-situation. I hear @Fred ‘s comments directed at the visual style of the Isadora control panel elements. Best wishes Bonemap

The lights you posted use the ifttt protocol, that is how they can work with Alexa etc. It is just http and I guess you can use Wireshark to spy on tj messages. Otherwise there are some nodes for node red for ifttt that may help, there are also osc nodes for node red that would let you control it from Isadora. https://flows.nodered.org/node...

@deflostI used a (now discontinued) Nyrius Wireless HDMI live feed transmitter and receiver. The key for me was that the transmitter was small. In this photo, you can see the transmitter sticking straight up to the side of the camera (with the tape that says "DEMO" on it). We used a 90-degree HDMI connector to allow us to have it pointing up, rather than out to the side, so we could secure it to the camera. At the back of the camera, (with the tape that says "A" on it), is a portable battery bank, as one would use for mobile devices. This acted as the wireless power-supply for the wireless HDMI transmitter.Note: Sometimes cell phones can interfere with the signal, so we had to make sure that the audience turned all of theirs to airplane mode or, preferably, completely off.Optimizing for Coverage: I was at the edge of the rectangular performance space and the live feed operator sometimes moved all the way to the far end. We were having some signal issues, so I moved the wireless HDMI receiver to the middle of the room, in the grid, and used an HDMI-over-Cat6 extender in order to put it that far away from myself without needing a 60' HDMI cable. No more issues after that, as the camera was on average always closer to the receiver then it had been.Best wishes,Woland

@kathmandale That is an exciting idea! It would be a lot easier to explain to less technologically understanding designers as well, to show them that it is merely an intelligent fixture like any other. I have not had much, if any, experience with Artnet. I agree that OSC and Midi are both a bit clunky.At our theatre, the LD is often the Projection designer as well, and is not always understanding of my words when I talk about the technical side of projections.I look forward to looking at the actor you made and I am going to look into seeing if I can do something similar myself before I look at yours.

Thanks, TouchOSC Editor is nice and easy.

like this? ( i used a mouse watcher instead of OSC Listener) 

@julio_parente  Unfortunately the files were not uploaded to our server - the logs show an error attempting to connect to our server. Hopefully they are still in the folder where the CrashRpt system puts them, which is here: C:\Users/YOUR_USER_NAME\AppData\Local\CrashRpt\UnsentCrashReports which according to the logs above are at C:\Users\Play\AppData\Local\CrashRpt\UnsentCrashReports\Isadora_2.5.2\ The names of the files I need are: c5aa950c-bce1-4e1c-a03c-afcdb4d6589e.zipf56c99de-794b-4117-8427-69393b972168.zipf3350635-9f37-4f52-a082-21f1c130d130.zipfc9f5507-be95-4949-aea9-a259f8b3cd29.zip9b70597d-12af-4734-8e1c-351186d015fc.zip If you get me the right files I can work on the problem. Best Wishes,Mark