thanks everyone for your replies. ndi and yams work indeed. much appreciated. however i am still kinda intrigued about the sidecar option because it actually semi-works.
here are two screenshots for the same file with the macbook and ipad connected via sidecar but different screens assigned as "secondary". when the ipad is assigned as the primary screen or "display 1", everything works smoothly, I can use my ipad as my main display and control the scene while the macbook screen is used as the second display.
case one : workswhen ipad is display 1 and macbook is display 2
however, when the ipad is assigned as the second display, the ipad screen turns white instead of displaying the stage it's assigned with.
case 2- not workingwhen macbook is display 1 and ipad is display2
sorry if this was already clear, but I wanted to make sure that I was able to explain the problem. i'm risking repeating myself because it seems to be a minor problem that might actually be a bug that could be solved with a tiny little patch?
I have used mac since 91 when I got a mac LC, that is 30 uninterrupted years of use now so its hard to let go. I have some PC's now as well for visual applications. There is no way around it anymore. But I hang on to my trashcan and macbook for every day use. Big sur almost tipped me over the point with all the ios vibes. I only upgraded because the recently released Octane X renderer demands it and maybe it would wake up the eternally slumbering AMD firepro's in the trashcan. (Its not bad, but its a 2013 gpu, so it is what it is)
For studio work, I am trying out Parsec. It is a free screen sharing solution targeted at the game community, who are notoriously latency intolerant. It took me 2 min to install and now I have the power of my GPU workhorse running in a window on my mac.
So this is how I will deal with it for now. I can stay on my trashcan and have all my GPU intensive stuff crunch away on the PC without leaving the couch. And a bit of windows drudgery actually kind of balances out the noveltyfication of big sur.
So I think its time to swap out the trashcan for a M1(X) mcMini with Parsec. And maybe after that kick the apple habit completely. At the moment I am trying to figure out which miracle is more likely: apple to be more pro and less iphone again, or windows to reinvent themselves with a soul? What do you think?
@paulpsound When you say you 'share' the mac do you mean that you're using the screen share function in Zoom or are you 'Spotlighting' the participant with the Virtual Webcam as their camera? If you're using the screen share function then I'm not sure what the virtual webcam is being used for. If you're spotlighting a virtual webcam then I'd suggest having a background permanently running on a lower layer that is always there and bring your slides in on top so there is always a something being sent to the virtual webcam, you could do this in QLab.
I had a quick go at trying to re-create the problem and I could regularly make it happen when switching between my real webcam and the virtual webcam in zoom using the 'select a camera' option. Is this what you're doing in the show?
Often I would get a flash of the OBS background before QLab's slide loaded, but there is other unwanted behaviour as well following this pattern:
> Select camera in zoom
> Play slide in QLab - displays correctly on the VWC monitor window
> Select VWC in zoom = flash of OBS background followed by the slide
> Select camera in zoom
> Wait a few seconds
> Select next slide in Qlab - displays correctly on the VWC monitor
> Select VWC in zoom = flash of previous slide followed by new slide (sometimes with a bonus OBS background flash as well)
Basically, I was often getting a 'flash' of the previous frame that zoom brought in, wether that was a slide or the OBS background.
I got exactly the same results using Isadora so I suspect that the problem is with Zoom as you suggest. The Syphon Virtual Webcam monitor shows the stage/surface correctly as does Syphon Simple Client app. I don't know if zoom somehow caches the previous frames and displays those while it's sorting itself out when you change inputs?
Wherever the problem the is, the obvious work-around seems to be - don't change between camera and VWC in Zoom. Why not set your camera up as 'Camera' cue in Qlab that is routed to the same surface as your slides, all you would then need to do is run through your Cue stack with slides and cameras popping up as needed, you wouldn't need to change anything in Zoom and the 'surface' being sent via syphon would be consistent. Or, even better, do the same thing in Isadora ;-)
(as a slight aside, I love QLab, it's a great tool for certain things, simple and effective. It's been the go-to thing for sound for years and I like how it's simple enough for a church hall, powerful enough for the west end. However, I also think that it is terrible at handling video and I avoid using it for video whenever possible. Even the most simple playback can be stuttery or with frames being dropped, and anything more complex is a real strain. QLab remains an important part of the workflow in the majority of shows I work on, but I run the video in Isadora and communicate via OSC as needed).
Very nice tracking and particle work. I have to say I did not see anything in your video that could not be done with Isadora native particle generators. If you want more sophisticated repel and attract parameters look at the 3D Model Particles module. It has very capable options for the style of particle systems that you are designing and are particularly effective when responding to tracking data. The tool set has been enhanced for this purpose about 18 months ago.
I got an M1 Mac mini and tried isadora on it with Rosetta 2. Izzy opened right up and snappily even. But so far the movie players only play audio. I am sure you are well aware of this but I just wanted you to have the Info.
Isadora 3 is not yet compatible with Big Sur because Apple just loves making life difficult for us developers. :-(
However, we have a beta that _is_ compatible and working well with Big Sur, and that will likely solve the problem.
If you want to sign up for the beta test program you we can let you try it.
Regardless, you can expect a the Big Sur compatible version to arrive soon into the new year.
@bonemap Thanks a lot Russell for your detailed answer.
The CalDigit TB3 Mini Dock might introduced a glitch in the GPU management, so an OS clean install would tell if the official USB-C > HDMI apple adapter finally works (solo). Otherwise the issue seems to come from the GPU or the motherboard...
@DillTheKraut, Russell succeeded to send video through OWC Dock and passive adapter, so an active mini-DP adapter is not always necessary. Other video technicians told me that the official USB-C TB3 > mini-DP TB2 apple adapter works fine with all their TB2 video adapters.
I think you should be able to find a 'FFGL Tile' plugin that may replace the MultiVid actor, depending on your exact usage. Try the 'FFGL Tile' actor in the oficial FFGL bundle first: https://troikatronix.com/plugi...
First of all, thanks very much to everyone who answered, that's what I love about this forum.
Special thanks to @Woland for your long and specific answer.
I've been doing some testing on these things, I post what I found in case somebody else finds it useful:
- The error in 2.6.1 was indeed caused by my 3D models, but not by the file itself, rather than the path. For some reason, if I put the 3D files in my desktop, Isadora has no trouble, but whenever the files are inside any folder, the error window pops up.
- The mouse watcher error only happens with an imported 2.6.1 patch. The mouse watcher works as expected in Izzy 3 if you make a new patch, but it doesn't if you open an old file. Maybe if I was able to save it (updating it in the process) it would behave correctly afterwards, but I have no way of knowing this... yet.
- As for the Blur taking up a lot of CPU usage, I found out that a missing FreeFrame plugin could be the actual problem. After I installed the FFMotionBlur (which was in the 32-bit plugins folder but not in the 64-bit one) the scene runs in Izzy 3 more or less the same way than in Izzy 2.
Thanks again everybody. I think I will be updating to Isadora 3 very soon, since it's clearer now than the problems were more closely related to using Izzy 2 in Mojave and I really want to try some of the new features (like Blind Mode and such). Cheers.
The software has been updated in 2016 and relied on QuickTime support from Apple to grab the necassary information / texture's. Since Apple has ditched support for QuickTime it means that the software wont work on newer versions of macOS. Like the Github issue explains you have to rebuilt the software against a newer version of OpenFrameWorks.
Even though you say you are running Isadora v3, this error. would indicate otherwise.
Instead, it seems that you are attempting to run Isadora v2 on Catalina, which is not possible because it is a Isadora v2 is 32 bit app and Catalina will only run 64 bit apps. (macOS Mojave and older ran both 32 and 64 bit apps.)
This error is described on this page from Apple where it says "When you attempt to open a 32-bit app, you will see an alert that the app needs to be updated to work with this version of macOS, or that the app is not optimized for your Mac and needs to be updated." It shows the same dialog you attached above.