@erik
the resolution of movies recorded in Isadora is set by the Record Stage Settings menu in the Output dropdown.

@dusx said:

I just did a quick test on Mac Sonoma. My camera is native 1280x720.I added a Video In Watcher, connected to a Get Video Size actor in my patch so I could see the video size live from the patch input.With native Resolution, I get 1280x720 in the Get Video Size actor, and when I switch to Quarter HD, I get 640x360 in the Get Video Size actor.Maybe I am miss understanding the issue, what do you mean by 'capture'? I see, your looking at the Capture Camera to Movie feature. Using this I do see, that it is grabbing the native camera resolution. I don't have a Isadora version 2 installed that I can compare against right now, but it is possible this setting was used at some time. Unfortunately I don't have a workaround currently. I can enter a feature request to add the resolution to the Capture Camera to Movie actor, since this would provide the greatest flexibility.NOTE: 'Capture Control' is used to start and stop the live capture system, and is not expected to record video. 

 Dear dusx,

Thank you for your reply. You have understood the problem correctly: the resolution of the video coming from a video source with "Video In Watcher" is correct with that defined in "Live Capture Settings". It is when recording the video with "Capture Camera To Movie" that the video returns to its native format. With versions 2.6, video recording respected the resolution defined in "Live Capture Settings". The disappearance of this function seriously handicaps us. Thank you for your attention.

@erik

I just did a quick test on Mac Sonoma. My camera is native 1280x720.

I added a Video In Watcher, connected to a Get Video Size actor in my patch so I could see the video size live from the patch input.

With native Resolution, I get 1280x720 in the Get Video Size actor, and when I switch to Quarter HD, I get 640x360 in the Get Video Size actor.

Maybe I am miss understanding the issue, what do you mean by 'capture'? 

I see, your looking at the Capture Camera to Movie feature. Using this I do see, that it is grabbing the native camera resolution. I don't have a Isadora version 2 installed that I can compare against right now, but it is possible this setting was used at some time. Unfortunately I don't have a workaround currently. I can enter a feature request to add the resolution to the Capture Camera to Movie actor, since this would provide the greatest flexibility.

NOTE: 'Capture Control' is used to start and stop the live capture system, and is not expected to record video. 

Hi, I haven't found anything on the forum about my problem:
Since version 3, including version 4, video captures from different webcams are in native resolution and don't respect the resolution specified in Live Capture Settings :

I had no problems until version 2.6, which performed this perfectly.
Capturing in native resolution slows down the frame rate (FPS) of our old patches, which perfectly ran 8 simultaneous videos captured in 640x360 px resolution with a few basic effects filters.

I tried using the "Capture Control" actor, but it's worse: no video is recorded.

Does anyone know anything about this problem and how to resolve it?
Thanks

Erik

We've been working on Isadora for 20 years, on Mac OS Intel, and this problem has been identified on all our workstations: from Ventura to Sonoma.

@dusx

I have verified that the inputs to the "TCP Send Data" are indeed all numeric and have not mutated to text.

I tried the format you suggested (I had not know of the BL format options you had suggested).  Now, the output is all zero regardless of the parameter value.

Hy everyone,

I´m working on a set of generative GLSL shader and I have a problem with the default value of an ISADORA_VEC4_COLOR_PARAM.

Example:

// ISADORA_VEC4_COLOR_PARAM(inside_color, isc, 0xA6D9FFFF, "The color used to fill the inside of the shape.");
uniform vec4 inside_color;

I would expect a light blue color with fully opaque.

But I got:

If I use a vec3 without an alpha channel the color is correct, test_inside_color in the image:

Is this an issue ?

Thanks

Malte

Hey everyone,

Just letting you know that a date is set for DanceHack 2026. We will be gathering at UCBerkeley, California, USA Feb 20-22 for several days of workshops, hacking, collaborating and performing. Dancers, choreographers, technologists, izzy enthusiasts etc of all skill ranges are welcome. This annual event is an amazing opportunity to gather with like minded folks to rapidly prototype dance and technology projects. 

Much more information to come soon!

Follow the website here: dancehack.org

if you want to add you name to an email list send a note to: info@kinetecharts.org

Hope to see you there!

Sheldon

@garygalbraith

First make sure the TCP Send Data actors inputs are not of the type 'text'. (incase they were mutated at some point and the type remains)

Then try: 

P1:1BL P2:1BL P3:1BL

Its possible that 0 as a null byte is internally representing the end of a string, so this raw binary approach may get around the issue if the receiver can handle binary. Def worth a quick test.

@woland

Yes, as I shared in the original post that I have tried the other formats:

P1:1 P2:1 P3:1

P1:1X P2:1X P3:1X

and 

P1 P2 P3

All of the above send the ASCII representation of the values and not the value itself, e.g. P1 is sent as 31 and not 1, P2 is sent as 30 and not 0, and P3 is sent as 32 and not 2.

If I use the format P1:C P2:C P3:C then P1 and P3 is sent correctly and P2 is not sent at all. 

I still can't get the actual value of zero (0) sent.

@garygalbraith

Have you tried these formats?

Here's the full table: