[SOLVED] OSC multi listener losing first values

[peuclid]

I'm a noob with izzy, so please forgive me if this is really obvious or dumb.

I have a little app that calculates cropping of zoom boxes and sendsan OSC message to izzy on port 1234 that looks kinda like (in the case of 3 boxes)

/izzy/cropValues/003 1.354, 50.312, 5.416, 51.083, 50.312, 1.354, 5.416, 51.083, 25.833, 25.833, 49.916,6.583

that list of numbers are crops for left, right, top, and bottom for each of the three boxes.

I link those numbers into three croppers for their left, right, top, bottom boxes and it should crop those images. The strange thing is that this works for the second, and third boxes, but the first one doesn't get any values. The first four values fill in properly in the OSC Multi Listener, but for some reason, the first Crop actor gets it's four values all set to 50 and not the values connected. Even if I change those values to 0, when OSC gets the new values, it sets them to 50 every time. I'm guessing 50 because it's the midpoint between MIN and MAX, but I don't see why.

When I test the output of those four values with input for another actor (like Set Global Value), it sets the values properly.

Screen shot of simple example attached 

Any ideas? Having a blast learning Isadora, but getting down to the wire on setting up a Zoom performance.

[DusX]

@peuclid

Not sure, generally there are only 2 factors that might go wrong with passing values.
The data type might be mutated incorrectly (the green dot indicates the input/output can be mutated).
Or the scaling values (shown when you click on the name of an input or output has values that don't work.

What I would suggest here is to: 

1. delete the Crop that doesn't work, 
2. select and duplicate a Crop that is working (ctrl+D)
3. disconnect the 'Set Global Values actor (just because those are mutable inputs) 
4. and reconnect the new Crop actor.

I would expect things will work.

If you want to post the broken file, I will dig in and let you know the cause of the issue.

[peuclid]

@dusx

I did those steps of deleting and creating a new Crop from scratch and it had the same affect.

I also tried copying a working Crop actor and it also did the same thing.

I only added the Global Vals actor to demonstrate that the numbers are really there and getting passed to other actors, but Crop didn't seem to take them. Normally I don't have that Global Values there.

Anyway, I'm attaching a simplified version that demonstrates the issue. In this version I sent the first two to one Crop and the second two to another one, each made independently and it shows the 50 shows up when the first four channels go to Crops, but the after 4, the numbers passed on properly.

My OSC changed slightly since my same report, now each packet contains 6 numbers instead of four, but the same problem persists. The first two numbers are now the percentage of the size of the width and height of the boxes so I can calculate the zoom level in izzy.

Hope this helps.

Crop-OSC-bug.izz

[peuclid]

@dusx

Just for grins, I threw in a "Pass Value" actor between the OSC listener and the input value, and that workaround seems to work. I added a Calculator and added the number to zero and that worked too. So something very strange about those first four values going from OSC Multi Listener output to some types of inputs in other actors, but not all of them.

Not urgent since there's a workaround, but good to know.

[Fred]

@peuclid I have had some strange things go on with the multi-listener, particularly with the type parameter. Can you try add a new multi listener, don't connect it to anything send some data so that it picks up a type and then connect it (make sure you don't change the type parameter of the multi-listener).

Fred

[peuclid]

@fred

Yes! that was it.

It wasn't so much the type but the MIN and MAX were set differently. I changed Limit Min to be "MIN" and Limit Max to be "MAX" on each of the fields and now they are working properly. Strange one, but thanks for figuring it out.

[DusX]

@peuclid said:

MIN and MAX were set differently

 Yes, looking at your attached patch, I can see the output Min/Max for the first few values are not the default MIN/MAX values.
Checking the scaling settings is often the best place to start debugging any issue with values not being what you expect.

[peuclid]

@dusx

I'm just starting to get the hang of this. This is a great pointer. I'll keep checking values like that as I go.

Thanks for the help!

[DusX]

@peuclid said:

I'll keep checking values like that as I go

 We are looking into ways of making these settings more apparent without having to dig in. 
Ease of use is always top of mind.