Closed Trinitou closed 1 year ago
I'm somewhat surprised that someone uses that mode, along with framecrop option it is labeled as "DO NOT USE" in the configure.ac. -- I was going to remove those.
Do you have a use-case for this? Some media-art exhibition?
Do you have a use-case for this? Some media-art exhibition?
The project I'm doing is an script for Bitwig Studio. It allows the users to save a video path + frame rate together with a project and uses OSC to automatically send those + the current frame to XJAadeo to get easy video playback sync. One of the users asked me to support the loop option as he wants to play back relatively short video loop while composing/doing generative music.
I could calculate the loop manually in the Bitwig script but therefore the user would need to enter the number of frames as well for each project. So there would be a workaround but not very comfortable for the users.
If XJadeo would have bidirectional OSC support so I could ask for the frame rate+number of frames of the currently loaded video via OSC, that would be optimal and mich more flexible. In that case I could live without the loop feature very well. ;)
Why not use MTC (MIDI Timecode) with Bitwig? I sat down with a Bitwig dev and made that work 5 or 6 years ago. I expect it's a lot more robust and more reliably than OSC.
As for the issue at hand, the code reads find. I may just merge it, but standard builds of xjadeo will not have this option enabled, so it's not directly useful.
Why not use MTC (MIDI Timecode) with Bitwig? I sat down with a Bitwig dev and made that work 5 or 6 years ago. I expect it's a lot more robust and more reliably than OSC.
At least on Windows using MIDI would mean that the user has to set up a virtual MIDI device to send MTC from Bitwig to XJadeo (using loopmidi + pmdefaults, for example). But with OSC, the controller script sets up OSC automatically and then we just need XJadeo to be started with the correct OSC port... so no extra layer in between which is great. Also for transferring the video path etc., we'd need OSC nevertheless. Concerning reliability I found that sending the 20-60 short OSC messages/second for current frame is not so much of an issue.
As for the issue at hand, the code reads find. I may just merge it, but standard builds of xjadeo will not have this option enabled, so it's not directly useful.
This makes me wonder a bit as I downloaded it from the official download page not long ago and OSC+loop option work fine (besides this issue). Or are you talking about the future that the loop option will get cut?
Or are you talking about the future that the loop option will get cut?
No plans to remove it for now, but they are already deprecated. Perhaps it is still useful for someone, but I have not used or tested them since at least a decade.
It is a compile time option and dates back to 2009/10 when xjadeo was used for various multimedia art installations around the world. There are also compile-time options to support pan/crop of the video to displaying it in a 4 wall cave. These days there are better options, particularly with high-res (4K, 8K) media.
For standard video monitoring those options just introduce overhead (and potential bugs).
Rebased and merged as v0.8.12-4 d460ece
Note: I fixed this blindly (without building/testing)! Maybe you would want to confirm the fix first before putting it into the next version.