Troubleshooting

Preset array of integer changes to floats on project reload

Started by Mr Bit on .

Sign in or create an account to join the conversation.

24 posts

Topic starter
Greetings,

I'm trying to use an array of 256 integers in an expression for preset storing but when the project is reloaded my stored array contains floats.

Is there any way to declare/fix data type so that this conversion does not take place?

The numbers are 32bit, when the float conversion happens the number is truncated so I cannot floor to get a result.

I think using 16 bit numbers will solve my problem but will require some reworking of my project so is a last resort.

I'm getting a feeling of deja vu from when I owned the original Lemur all those years ago. The extra horse power from the ipad and stabilized scripting is a great improvement but its a shame the data handling limits and no preset system are still a major pita.

That said it has forced me to learn some good techniques to work around these limitations which I will share as soon as this last niggle has been solved.
Subject: Re: Preset array of integer changes to floats on project rel
Hi
Had a bit of a look and there may be some oddness going on, but also some ways around it all ....

I don't think there is a way to force type - an array can be anything, defining as ints does not force it to remain as such . . .
Forcing what gets stored to it by only sending it ints is the way to go

Using the floor() function at the right spots should keep things how you need it . .
Maybe send a simplified version of the project so we can see your logic ...

MM
Subject: Re: Preset array of integer changes to floats on project rel
Thanks for your replies a simple test is to make a single pad with script storing to global expression test, then save your project and reload.

test = {536870915,47457457};

On project reload test will be

{536870880.000,47457456.000}

I'm not sure how floor will help with this as I fear data type is not stored and default on recall is float also the extra .000 is busting a limit.

storeTest.jzml
Subject: Re: Preset array of integer changes to floats on project rel
Mr Bit wrote:Greetings,

I'm trying to use an array of 256 integers in an expression for preset storing but when the project is reloaded my stored array contains floats.

Is there any way to declare/fix data type so that this conversion does not take place?

The numbers are 32bit, when the float conversion happens the number is truncated so I cannot floor to get a result.

I think using 16 bit numbers will solve my problem but will require some reworking of my project so is a last resort.

I'm getting a feeling of deja vu from when I owned the original Lemur all those years ago. The extra horse power from the ipad and stabilized scripting is a great improvement but its a shame the data handling limits and no preset system are still a major pita.

That said it has forced me to learn some good techniques to work around these limitations which I will share as soon as this last niggle has been solved.
out of morbid curiosity, what is the largest number you can use that doesn't get truncated? I see references to 32 bit numerical precision in the manual, but I didn't see a max value mentioned anywhere. I know it is at least 8,355,711 since that is the largest RGB color value...

BTW - I've had arrays I declared end up mixed integer and float when I looked in the .jzml file. I also see switch X values stored as 1.000000 when it really can only be 0 or 1.
Subject: Re: Preset array of integer changes to floats on project rel
oldgearguy wrote:
Mr Bit wrote:Greetings,

I'm trying to use an array of 256 integers in an expression for preset storing but when the project is reloaded my stored array contains floats.

Is there any way to declare/fix data type so that this conversion does not take place?

The numbers are 32bit, when the float conversion happens the number is truncated so I cannot floor to get a result.

I think using 16 bit numbers will solve my problem but will require some reworking of my project so is a last resort.

I'm getting a feeling of deja vu from when I owned the original Lemur all those years ago. The extra horse power from the ipad and stabilized scripting is a great improvement but its a shame the data handling limits and no preset system are still a major pita.

That said it has forced me to learn some good techniques to work around these limitations which I will share as soon as this last niggle has been solved.
out of morbid curiosity, what is the largest number you can use that doesn't get truncated? I see references to 32 bit numerical precision in the manual, but I didn't see a max value mentioned anywhere. I know it is at least 8,355,711 since that is the largest RGB color value...

BTW - I've had arrays I declared end up mixed integer and float when I looked in the .jzml file. I also see switch X values stored as 1.000000 when it really can only be 0 or 1.
It seems to work up to 24bit.If you imagine 32 switches representing our 32 bits with switch 1 and 24 on this is where its breaks,the number generated with switch 1 and 23 is stored and recalled properly(aside from being converted to a float)

Yes I've seen the mixed INT and float thing too!
Subject: Re: Preset array of integer changes to floats on project rel
Hi
floor() will convert the floating point number to the next lower int . . .
There is no 'data type not stored' or 'default recall as float' . . .

There may be a bug or two that is affecting what you are seeing . . .
Try using an onLoad script at project level with the same code . . .

So - use floor() in your scripts to set values as ints, or use floor() in the Monitor to see it as an int

Pretty sure its signed 32 bit ints so range is −2,147,483,648 to 2,147,483,647
Does go beyond this but numbers get folded/flipped
Subject: Re: Preset array of integer changes to floats on project rel
Hi,

Is there a solution to the OP problem? I am suffering the same issue. Using MrBit's example project...

test = {floor(0x02ffffff),floor(47457457)};

When executed, the monitor correctly displays {50331647, 47457457 }
However after a project save and reload we get this from the monitor;

{50331648.000, 47457456.000}

If the values are dynamically created and stored with the project rather than hard coded, can someone explain how using a floor will solve this problem? The value is being truncated at some point, either on the save project or the reload. Using onLoad doesn't help as the value is already corrupt, sure I can floor the value but that just gives me an integer containing the wrong value. At the point of project save we can clearly see the values are integers so should be stored as such.

I cant see how 'Macciza's suggestion of using floor's addresses this issue.

In effect this limits the practical max size of an integer to 24 bits. The problem is particularly nasty as it all works fine until you reload your project.

Macciza:"Pretty sure its signed 32 bit ints so range is −2,147,483,648 to 2,147,483,647, Does go beyond this but numbers get folded/flipped"

So yes internally during script execution this is the case, but practically one cant use this full range as the data is lost on a project save/load.

Any solutions to this fault?
Subject: Re: Preset array of integer changes to floats on project rel
Are you using the latest versions?
I believe the issue is fixed, I can no longer reproduce it, it works fine either way Editor and App v 5.0.3 . . .
I can't recall now whether I saw the changing values before or just the float/int variance

My previous solution had been to write the value to an empty expr with an onLoad script
The use of floor() in any script/expression using that value addresses the errant float issue
It is akin to doing implicit casts to ensure that you never get a float instead of an int
Subject: Re: Preset array of integer changes to floats on project rel
Thanks for the reply. I have tried the latest version 5.0.3 app and editor. Alas it's still broken.

I'm interested in your technique of using an empty expression. Could you please modify MrBit's simple example project to demonstrate how to achieve it.

All that is needed is for the stored values to still be the same value after a project reload.

So to be clear;
Load "storeTest.jzml"
Allow the init script to run (i.e. set to OnFrame) that should set the monitor to be {536870915,47457457 } which is the values I want.
Set the init script back to OnExpression
Save the project
Quit the Lemur
Reload the project
Monitor now displays {536870880.000, 47457456.000}

obviously I can perform a floor on the monitor values at load. But that still gives me the wrong integer value, i.e.
{536870880, 47457456} != {536870915,47457457 }

Which is not what I stored. This seems pretty fundamental to me.

Cheers for help.
Subject: Re: Preset array of integer changes to floats on project rel
Ok
It is still a bit weird - earlier example file still acts weird

But I have a project built from scratch saving your numbers fine . . .??
Can also generate a rand()*0x7fffffff number stored to a var and have it recall??

What devices are you on? Have you sent a report to support ?
I think I may have already raise fit or a related issue.
Really not sure whats going on here . . .
Subject: Re: Preset array of integer changes to floats on project rel
threeLeggedLemur wrote: So to be clear;
Load "storeTest.jzml"
Allow the init script to run (i.e. set to OnFrame) that should set the monitor to be {536870915,47457457 } which is the values I want.
Set the init script back to OnExpression
Save the project
Quit the Lemur
Reload the project
Monitor now displays {536870880.000, 47457456.000}
One thing to check to help see where it is breaking -- After you set the init script back to OnExpression and save, open the .jzml file and see if the numbers are still OK there.

The reason I say that is because the version of storeTest.jzml that is attached in an earlier message already has the numbers truncated.

The .jzml files are basically XML files, so anything editor can open them. Doing a step, hitting save, then checking the .jzml may help determine if the problem is conversion on save or on reload, which may help the Liine guys to track down the issue.
Subject: Re: Preset array of integer changes to floats on project rel
Hi Guys,

Thanks oldgearguy. The plot thickens.

I've checked the file contents before saving the project and the file contains the correct values. So it must be the file loading that is causing the corruption.

In the original storeTest.jzml that MrBit posted. If you open the file in a text editor you can clearly see that the numbers are indeed correct and not truncated. However when the lemur loads the file the values get corrupted from that point on.

MrBit's original file has this;

<VARIABLE name="test=" value="536870915,47457457" send="1" osc_target="0" osc_trigger="1" osc_message="/test" midi_target="-1" midi_trigger="1" midi_message="0x90,0x90,0,0" midi_scale="0,16383" kbmouse_target="-1" kbmouse_trigger="1" kbmouse_message="0,0,0" kbmouse_scale="0,1,0,1"/>

After loading into the lemur and doing a save.

It's now corrupt and contains this;

<VARIABLE name="test=" value="536870880.000000,47457456.000000" send="1" osc_target="0" osc_trigger="1" osc_message="/test" midi_target="-1" midi_trigger="1" midi_message="0x90,0x90,0,0" midi_scale="0,16383" kbmouse_target="-1" kbmouse_trigger="1" kbmouse_message="0,0,0" kbmouse_scale="0,1,0,1"/>

@ Macciza, "But I have a project built from scratch saving your numbers fine . . .??
Can also generate a rand()*0x7fffffff number stored to a var and have it recall??"

Could you please supply your project which you have working? I would like to see how you achieved it as I'm not getting anywhere.

I have not yet reported the bug to Liine Support.

Cheers
Subject: Re: Preset array of integer changes to floats on project rel
Hey Macciza,

Any word on your working example project?

It's very frustrating to hear someone has a working project and wont seem to share.
It implies it is not a bug in the Lemur but rather a problem with my project. It doesn't seem worth contacting Liine if there is something I am doing wrong.

Thanks
Subject: Re: Preset array of integer changes to floats on project rel
Hi Macciza,

Thanks for the reply and project. I've had a look through it and noticed your setvar function is exectued on load.

That in effect just overwrites the corrupted values with the known example constants and hides the problem. I can't do this as the values are dynamically created by the user.

If you set your setvar function to execute OnExpression. Then save your project then reload. The values in var are corrupt.

I've attached your modified project project to illustrate the problem.

Thanks again for the help.

CHANGINGFLOATS.jzml
Subject: Re: Preset array of integer changes to floats on project rel
Yeah ok
Though I don't think having the script set execute on an empty expression is a particularly good example
Again I could get it to work with a Pad executing it , for a while then things go weird again
Same thing when setting var to zero rather then leaving unassigned
As I think I said before I think this is part of an issue that Liine are looking at for next release
I think it may be some sort of errant memory leak mucking things up
This is something that Liine will need to follow up on

Without knowing what you are wanting to do in all this apart from store and retrieve some large numbers not sure what else I can offer
I have not run any test on storing and retrieval of smaller numbers so not sure if altering your data approach will offer any hope
What are the numbers being used for anyway?

CHANGINGFLOATS 2.jzml
Subject: Re: Preset array of integer changes to floats on project rel
Hi,

I've been experimenting with the new canvas stuff. Thought I'd have a play with writing my own bitmap handling routines with a transparency mask.

I can fudge the issue by only using 24 bits of the available 32 but it's not very elegant and shouldn't be necessary. To be honest I was so surprised that such a fundamental problem could exist I just assumed I was doing something wrong.

I think I will dump the project until Liine fix the bugs as I cant keep wasting time fighting it.

Thanks again for trying to help.