Responses to Isadora v2.1
-
Dear Armando,
I can write you personally about the "perfect storm" of things that came together on that particular day – it was more than Izzy and v2.1.But with regard to the Point List, all I can say is "Oops." I have a handful of plugins that are for my private artwork, and normally they are all automatically deleted when I build the installer. The Point List actor relates to one of those private plugins. It should have been deleted too. (There was another one noticed by @Nick above.)I'll ensure it is deleted from the build and re--upload the installer.Best Wishes,Mark -
I tried to comment on the "Version 2.1 is available" announcement, but seems like comments aren't working there? Anyway, my suggestion going forward is to completely rewrite the manual section on Serial In data parsing. Although it is quite thorough, it is possibly the most confusing bit of manual reading I have ever done. I am having a REALLY hard time figuring this out. Thanks in advance, Mark. Otherwise I love v.2.1.
John -
I agree with the comment on serial manual… I now begin to be able to use it for Arduino reception and command but a rewrite would be very helpful.
But serial communication is not easy too… -
Dear @jtoenjes + @jhoepffner,
Yes, well, the problem with serial communications is that there is no standard at all. To be able to handle nearly anything, the interface is necessarily complex. That's really the first problem.Take a look at [this serial protocol document](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAAahUKEwjs8P-nuvnIAhXMOz4KHXhTC-o&url=https%3A%2F%2Fwww.basecamelectronics.com%2Ffiles%2FSimpleBGC_2_4_Serial_Protocol_Specification.pdf&usg=AFQjCNH2bLDfYxH6PQFCFzj8ectmU_ibzQ) I found on the web. The parsing system is designed to allow you to work with something as complex as what is specified here. But even reading the document, for someone who is not a programmer, is pretty difficult.Probably a set of clear examples for the most common situations – the primary one being receiving data from Arduino – would go a long way to solving this problem.You could help us by perhaps sharing some examples of data streams you had a difficult time figuring out how to parse. If you have that information handy, that would be most helpfulIn any case, @Primaldivine is working on a major update to the documentation now. I will see what we can do before v2.2 in late December.Best Wishes,Mark(@DusX, could you ensure this isssue is recorded on our feature request list? Thanks) -
Mark,
I prepare a workshop in Paris with example in Arduino, Live, Processing and Unity. I am writing a manual in French but I will translate it in English for the other half of the world… :-)– communication Isadora/Arduino though Serial, OSC and DMX– communication Isadora/Live through soundflower and midi– communication Isadora/processing through OSC and Syphon– communication Isadora/Unity though OSC and SyphonFrench version will be ready for november 15English first translation december 15, earlier if I found english speaking help…All the best, -
Yes, examples would be very helpful. Actually I was finally able to get what I wanted from the example that Jaques posted awhile ago in response to someone wanting to get input from 8 sensors into Isadora. So, some simple examples of common scenarios would go a long way to making things clear. Thanks!
-
comment deleted
-
In a few other threads there is some talk of eye and eyes++ getting a revamp and having built in conversion from GPU to CPU. This does make a user friendly option but IMHO it is a wasteful solution. Moving data from GPU to CPU and vice versa is slow and costly and should be avoided at all costs. If actors, well particularly eyes and eyes++ are not to be ported to proper GPU actors they need to be complimented with either mutable CPU/GPU actors or a set of CPU actors like crop for prepping the image (maybe the new eyes will have an ROI setting and rotate options for the incoming stream). If you take this thread for example,
http://troikatronix.com/troikatronixforum/discussion/2325/eye-is-cpu-only#latestand this from mark "Also, please note that the updated plugin will have no advantage over using the GPU to CPU Converter, because the video must be on the CPU to do the analysis; the updated plugin will simply do this for you" I dont quite get the logic- in this case you will force anyone using tracking to use a very costly process when in this case the old technology should do a better job.In this case a CPU based video in watcher and a CPU based crop will use less overhead as in the first case the video in watcher will be uploading the data to the GFX card, and then downloading it again after the crop for eyes and then likely users will use more GPU tools to generate images, possible re-uploading the video in watcher to do effects as overlays on the live feed- as we don't have access to the texture data that was originally uploaded we go through the whole process again and slow everything down.If eyes cannot get a GPU version (on windows this is easy using compute shaders to get results back from the GPU but OSX's ever lagging implementation of open GL means this is not as easy), then maybe it should have a built in CPU based actor -
Does it not make more sense to run eyes+ off a parallel branch just to get the detection vectors etc and the video on that branch terminates there, whilst also keeping all the video in GPU land simultaneously on the other branch...? Effectively working off a copy....? Or am I misunderstanding?
-
That is what I do. I use JunXion to track camera input and send data over to Isadora via MIDI or OSC.JunXion is pretty effecient and easy to set up. And has better tracking capabilities I think. -
I saw the Video delay is cpu only-is there something for gpu?
-
Not that I know of
-
Here is another post explaining how the video delay works: http://troikatronix.com/troikatronixforum/discussion/1021/livecamera-with-1.5minutes-delay-over-one-hour
Best Michel
-
I have posted this comment on several threads but on my MAC Open Recent crashes the program in 2.1 and the Global Keystone actor does not respond as expected (none of the Bottom parameters respond and the Top parameters are mostly reversed.
TLH: Pulls in TL horizontal and vertical towards centerTLV: Pulls in TR horizontal and vertical towards centerTRH: Pulls in BL horizontal and vertical towards centerTRV: Pulls in BR horizontal and vertical towards center -
Dear @Old_Dog
Please don't post the same issue several times. You will also get an answer if you post it once and if it is a new issue please create a new topic.
Thank you.
Best Michel
