Well, it's been quite the hectic week here, culminating with a new build for the team at the end of a 16 hour day of mashing on code. The work of the previous week wasn't so much taken by adding new features, but instead 1) ensuring that the new features mentioned here previously are crash free, and 2) improving and modifying behaviors of the cue number features based on discussions we're having among the team, and 3) fixing a few old, outstanding bugs. That said, there are a few new actors as listed below.
In terms of the older bugs, one showed up if you dragged some scenes, and then chose "Undo" and then "Redo," the scenes would end up in the wrong place. (Doh!) No one, users or team or me, ever noticed this before; it has to be years old. But there was some other stuff with dragging scenes, and just managing this took a couple of days.
Another longstanding issue were some hard limitations in OSC: only 200 available packets could be in memory at one time, and there was a 1000 byte limit to the amount of data each packet could hold. Our dear friend @DusX, who likes to pull copious amounts of data from the internet, managed to break these limits. But mainly these kind of hard limitations are never nice for people who like to do weird things (e.g,. most of you) so we've added a feature to allow you to customize this in the Isadora Preferences:
Now you can set the number of packets that can be in memory at the same moment, the default size of an input buffer, and the absolute biggest buffer that will ever be allocated. The latter property reflects a new feature: previously, the amount of data that each packet could hold was fixed – the "Default Data Size" in the above window. But now, you can allow larger packets to be accepted if they arrive, with the "Maximum Data Size" being the biggest that would ever be allowed. (It's good not to have an infinite limit on this, because a packet with bad formatting might look like it was 4GB long or whatever... that would lead to a crash simply because the memory chunk would be too big.) I reckon that 256K is a pretty healthy maximum size for an OSC packet.
There is a GPU version of the Dots actor that replaces the old one. (The old CPU version is now called "Classic Dots.") New features include the ability to crossfade between a specified dot color and the source color, the ability to specify the maximum dot size, and the fact that the CPU dot version is now anti-aliased. (Thus the removal of the troublesome 'scale' input which really was a workaround for the fact that the dots weren't anti-aliased when drawn by our dear, but now ancient, QuickTime.)
Likewise, there is a GPU version of the Lines actor that replaces the old one. (Old, CPU version = "Classic Lines".) The new features include a new 'end cap' input that allows flat, square, or round endcaps, a background color input, and a 'classic' input that will cause this actor to replicate the behavior of the old CPU based Lines actor that used QuickDraw for drawing. (We might remove this input since the old, classic CPU version still exists.)
Finally, I also created a brand new actor called OSC Multi Listener. This allows you to capture a contiguous range of OSC inputs. You tell the actor the first channel and the number of channels to copy, and the matching outputs will appear, labeled with the corresponding channel numbers to make it clear which channel is which.
In relation to this, I made a kind of nifty OSC Recorder user actor to which @DusX is making some improvements to ensure timing accuracy. We'll get that out to you as soon as we can.
That's it for now folks. Hope you all have a nice weekend approaching.
I agree with @keftaparty and the playback sequencer or a cue index. I've done a few shows where I've needed to control Isadora via Midi show control from a lighting desk. I've had to create a Background scene that would be active throughout the show to act as a cue index. The Midi show control listener would receive the cue number then compare that to the index and then using the Jump By Name actor that another user created (I can't remember who offhand - sorry about that) Isadora would fire the corresponding cue in any order as per the lighting cues. In this instance the timing of the cues was written in the background scene (in the JumpByName actor). It would be great to have a cue list that auto-populates and will allow you to update the timing in either the cue list or in the scene editor. (If the infrastructure that currently exists for the go trigger timing could update to a cue list and be changed in either location that would be grand).
Nice, I think there is a really lack of a good high quality GPU decoded codec, HAP is Ok, but has serious limitations for quality. If this actually gets to be a standard it will be great. In the meantime here is another runner that is not going thhrough the Kronos group, but is making some good progress https://www.daniel2.com/
I would offer this guidance: the best way to appreciate someone's post is to enhance it:
Submit an improvement or enhancement to the original idea, User Actor, or technique. You can say "Thanks! This is so awesome... and here's a couple of refinements I made to make it even more useful." (I might point out my recent response to @jhoepffner 's "displace" GLSL source code as an example. I thanked him, made some notes to ensure users knew this wasn't a replacement for Isadora's Displace actor, and then posted an new version of Jacque's original code which made it work more like the Displace actor.)If you have a "use case" that differs from the one proposed in the original post, explain how you would take advantage of the tool or technique in your specific situation.If the tool or technique is missing something you feel is important, then say so. "It would be so great if this User Actor could also ..." That allows the original poster or others in the community to implement your "feature request."
Basically, if you add more information/knowledge/ways of using what the original poster offered, you'll not only be able to thank the person who posted first, but improve the usefulness of the entire thread.
Thanks for fleshing out this idea further, it was one of the things I really liked about @Michel 's post above, but forgot to mention in my comment. I wholly agree with this idea, and think asking people to do this via a pinned post (if pinned posts are still a thing?) would be a great solution.
Thanks for the info! I'm in need of an upgrade, and deciding between the Blade and a MacBook too. I'm grateful for all the insight, and it's good to hear from people who are moving away from MacOS, and who are pretty pleased with the Blade.
The most attractive thing to me about eGPUs is getting more outputs - more powerful cards will see a bigger reduction in performance over TB3. The Blade, for example, is difficult to upgrade with an eGPU because faster cards than the built-in 1060 want more bandwidth than TB3. It's still possible though, and at least offers the extra outputs & quieter fans.