I've just added a wave generator and a color maker HSBA which does the trick! Thank you!
Glad to hear you got what you wanted. You need a program that understands the 3DS model format to open the star. I use Cheetah3D because it is simple and easy for someone who doesn't spend a lot of time working with 3D programs. (Blender, for example, is free but massively complex and I don't really dig the user interface.)
It is a really powerful feature. One thing to be aware of is that turning On the User actor, triggers the INIT function of all contained actors. This is actually very useful, but can be confusing if you are not aware. I suggest using the User Actor on/off within the user actor as a way of seeing the INIT occur (note. you can copy this actor to the main scene patch, and force the re-INIT of all actors as well... super helpful)
Thank you for your answer. I was already on your Github page but I don't have the knowhow to deal with the files. My question was first for the Troikatronix team if there is a hope to get such a player in the next release.
We already wrote 4 years ago in this forum about the GStreamer actor but after that I never heard from you:
I was curious about the idea, if there is MiniDP to DP adapters, shouldn't it work the other way around as well?! So here is just some Adapter fun 🤪; If you already own a USB-C to DP adapter, you could go with this DP to miniDP adapter (No garantie that this realy works 😜).
I have had better experiences using the Blackmagic design codecs (included with their video capture software - free).
However. At 5 mins you will likely hit the Avi containers max filesize... This will truncate your video.
I would use OBS to record a Spout feed from your stage. This would record realtime, so you patch needs to run smoothly in real-time. The nice thing about this approach is it off loads see work from Isadora, so you have more cpu space to use.
This was resolved via the ticket system. In the current release of Isadora, if you have some special characters in the file name, eg / \ | ? * ", then the capture actors won't work correctly. This has been fixed in an internal beta and thus this won't be a problem once we have a new public release.
I'll come out of the woodwork and state that in this specific case @peuclid is referring to a new feature that Liminal is adding to ZoomOSC that allows for the sending of full frames of information about every user in a Zoom call so that various stats about that user can be leveraged simultaneously for the sake of reconstructing user profiles within the integration platform (Isadora in this case). We are sending these successive OSC packets under the same address because our next update will be moving the software to a more "pure" implementation of OSC standard practices. @DusX has a great solution for "analog" input where dropping a few samples here or there would not create a noticeable difference, but because these packets describe user profiles, any loss would be reflected as a gap of all statistics for a given Zoom participant, which is an issue for online performances. The other software solutions we integrate with do not seem to face these challenges; maybe they log the OSC packets in a different way.
I'm going to meet in the middle here, adding a parameter to the new user interface of ZoomOSC to set the output sending rate such that, when used with Isadora (and when leveraging the General Service Task feature as needed to find a happy medium) the programs will communicate successfully. We love Isadora and want to make sure it can fully utilize our new features.
I have a lot of respect for what Mark is doing to make OSC accessible to the end user in Isadora, and I think I can make some specific feature requests to TT that could ideally retain the intuition of the Isadora OSC workflow but add more compliance with the OSC standards (sanitization of args and addresses, how packets are stored and constructed, etc.).